JobManager intermittently sets running=false? (multiple job managers) about android-priority-jobqueue HOT 8 CLOSED

Logically, if the jobManager isnt running, and stop was never called, then it must not have been started correctly. But looking at the constructor. running=true is set very early.
I cant work it out.

from android-priority-jobqueue.

Is there an underlying problem with starting a lot of JobManagers, do you think?

from android-priority-jobqueue.

Make sure you always call jobManager.start() this will guarantee that the particular jobmanager is running.

from android-priority-jobqueue.

Hi. Is this a known issue?
I saw a stack overflow 'issue' that said something about making lots of JobManagers with persistant queues - maybe hitting up the underlying sqlite layer with multiple jobmanagers at creation time causes some kind of failure? Im just guessing: What Ive done to try to avoid this is:

1. reduced the number of job managers being created by using groupIds.
2. made sure Im using different jobmanager ids.
3. as only 1 of the JobManagers actually needs persistant jobs, I passed in a custom JobQueue factory that returned non-persistant queues for both types of queue

As of doing that I havent seen the problem again, but obviously with these sorts of itermittant values, thats no guarentee. Ill update this thread if it happens again.

from android-priority-jobqueue.

BTW, Ive also hit problems with very big jobs - first of all the android cursor explodes at 1 or 2MB, and then getting around that issue with a custom persistent queue then explodes the deserializaiton.

So I gave up and stored the large part of the job in a file.

from android-priority-jobqueue.

@stefoid Are you providing an ID to your jobs ? Or at least you should if they are decoupled (otherwise use 1 job manager). Also, there are no internal calls to stop so i'm not sure how it is happening either. Do you have a test app that i can look at ? (btw, sorry about the late reply, i just came back from a long vacation)

from android-priority-jobqueue.

Hi. Our problem seems to have gone. What we were doing was creating lots of JobManagers for various duties, most of which did not need persistent Jobs, so we didnt create them with an Id.

What we are doing now is passing the same non-persistent job queue to both createPersistentJobQueue as well as nonPersistent, so we dont involve slqite when we dont need to.

And we have consolidated a lot of JobManagers and are using group ids instead.

What I believe was happening (didnt see/capture it happening as it was intermittent) was getting and invisibly swallowing some exception or other during JobManager creation while JobManager was trying to setup to Sqlite. Thats the only thing that makes sense - so every now and then we got back a JobManager that wasnt actually running.

A suggestion might be to more easily configure a non-persistent JobManager if you dont require that functionality, and make construction exceptions more visible in some way.

from android-priority-jobqueue.

To create a non-persistent job queue, you can provide a queue factory in the job configuration and just provide implementation of a queue that does nothing and always returns empty result. Glad issue is resolved, please re-submit if you can reproduce it.

from android-priority-jobqueue.