Too many SQL variables exception

[tapasya]

I really don't have a scenario in which this is happening, but this is causing the app to crash intermittently.

Fatal Exception: android.database.sqlite.SQLiteException: too many SQL variables (code 1): , while compiling: SELECT * FROM (SELECT deadline FROM job_holder WHERE ( (deadline != 9223372036854775807 AND deadline <= ?) OR network_type <= ?) AND _id NOT IN(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) AND running_session_id != ? ORDER BY 1 ASC LIMIT 1) UNION SELECT * FROM (SELECT delay_until_ns FROM job_holder WHERE ( (deadline != 9223372036854775807 AND deadline <= ?) OR network_type <= ?) AND _id NOT IN(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) AND running_session_id != ? ORDER BY 1 ASC LIMIT 1) ORDER BY 1 ASC LIMIT 1
at android.database.sqlite.SQLiteConnection.nativePrepareStatement(SQLiteConnection.java)
at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:889)
at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:500)
at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:588)
at android.database.sqlite.SQLiteProgram.(SQLiteProgram.java)
at android.database.sqlite.SQLiteStatement.(SQLiteStatement.java)
at android.database.sqlite.SQLiteDatabase.compileStatement(SQLiteDatabase.java:1033)
at com.birbit.android.jobqueue.persistentQueue.sqlite.Where.nextJobDelayUntil(Where.java:74)
at com.birbit.android.jobqueue.persistentQueue.sqlite.SqliteJobQueue.getNextJobDelayUntilNs(SqliteJobQueue.java:322)
at com.birbit.android.jobqueue.cachedQueue.CachedJobQueue.getNextJobDelayUntilNs(CachedJobQueue.java:88)
at com.birbit.android.jobqueue.JobManagerThread.getNextWakeUpNs(JobManagerThread.java:599)
at com.birbit.android.jobqueue.JobManagerThread$1.onIdle(JobManagerThread.java:260)
at com.birbit.android.jobqueue.messaging.PriorityMessageQueue.next(PriorityMessageQueue.java:89)
at com.birbit.android.jobqueue.messaging.PriorityMessageQueue.consume(PriorityMessageQueue.java:36)
at com.birbit.android.jobqueue.JobManagerThread.run(JobManagerThread.java:220)
at java.lang.Thread.run(Thread.java:818)

PS @yigit Hey, I didn't get time to revert the code to reproduce the #202 . will do it over weekend

[tapasya]

It is due to the fact that, I schedule and cancel lot of jobs and when building the query for scheduling of next job delay pending cancelations are taken into consideration. I think the size of the private Set<String> pendingCancelations = new HashSet<>(); is becoming huge and when compiling this query the exception is thrown.

the size of pending cancellation is 511 when this happened.

[tapasya]

please refer to the repo https://github.com/tapasya/hellojobqueue.

[yigit]

Wow, 500 jobs pending cancellation? That number looks outrageous, is that a real case?
This is fixable but:

• will be a significant change
• May require changing how cancellation works or changing the internal JobQueue API.

[tapasya]

Yeah .. this happened in a real time scenario. I capture session based analytics in our app. One specific requirement is to capture the event only when it has not occurred in the a particular time. So I was cancelling the old job scheduled and queuing up new job. whenever the app usage is high and this particular flow is triggered frequently, this exception is thrown.

For now, as a workaround I used the configuration to set queue factory in which I have sub class of SQLiteJobQueue to catch the exceptions. I was wondering if there is any clean up that I could to when I catch this exception to get rid of the pending cancellation ?

Also would it makes sense to have a catch block in the JobManagerThread's run (or some appropriate place) and have a configuration option available to the developer to cleanup and start the JobManager fresh instead of landing up in a crash?

[yigit]

Definitely no to a catch block. It will usually mean something is broken and ignoring it will just later create even more inconsistencies that are hard to debug.
Btw, creating 500 jobs that are persistent seems like a very significant load.
Instead, I'll consider changing the implementation of cancelling and mark jobs as cancelled instead of keeping a list of them.

[yigit]

this is fixed in beta2. Though I still think you should re-think your model/implementation to lower the number of jobs.