Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AsyncExecutor requirement failed: count cannot be decreased #1856

Closed
hvesalai opened this issue Mar 2, 2018 · 1 comment
Closed

AsyncExecutor requirement failed: count cannot be decreased #1856

hvesalai opened this issue Mar 2, 2018 · 1 comment
Labels
Milestone

Comments

@hvesalai
Copy link
Member

@hvesalai hvesalai commented Mar 2, 2018

When shutting down, this exception can sometimes be seen.

Exception in thread "AsyncExecutor.default-17" java.lang.IllegalArgumentException: requirement failed: count cannot be decreased
	at scala.Predef$.require(Predef.scala:224)
	at slick.util.ManagedArrayBlockingQueue$$anonfun$decreaseInUseCount$1.apply$mcV$sp(ManagedArrayBlockingQueue.scala:54)
	at slick.util.ManagedArrayBlockingQueue$$anonfun$decreaseInUseCount$1.apply(ManagedArrayBlockingQueue.scala:53)
	at slick.util.ManagedArrayBlockingQueue$$anonfun$decreaseInUseCount$1.apply(ManagedArrayBlockingQueue.scala:53)
	at slick.util.ManagedArrayBlockingQueue.locked(ManagedArrayBlockingQueue.scala:202)
	at slick.util.ManagedArrayBlockingQueue.decreaseInUseCount(ManagedArrayBlockingQueue.scala:53)
	at slick.util.AsyncExecutor$$anon$2$$anon$1.afterExecute(AsyncExecutor.scala:128)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
@hvesalai hvesalai added this to the Future fix release milestone Mar 2, 2018
@hvesalai hvesalai added the bug label Mar 7, 2018
hirofumi added a commit to hirofumi/slick that referenced this issue May 24, 2018
"count cannot be decreased" seems to happen as follows:

1. `ctx.delivered(demand)` in a `PrioritizedRunnable` of`.scheduleSynchronousStreaming` returns 0.
2. subscriber calls `ctx.request()`.
3. `ctx.request()` calls `.scheduleSynchronousStreaming` (via  `.restartStreaming`) and it creates a new `PrioritizedRunnable`.
4. The new `PrioritizedRunnable` calls `releaseSession` and sets its `connectionReleased` true.
5. `PrioritizedRunnable` of the step 1 also sets its `connectionReleased` true because `ctx.currentSession` is released by step 4.
6. `decreaseInUseCount` is called twice because of the two `PrioritizedRunnable` with `connectionReleased`.

The above can be demonstrated by inserting `Thread.sleep(100L)` immediately after `while ((state ne null) && realDemand > 0)`.

This commit fixes the problem by preventing `PrioritizedRunnable` from setting `connectionReleased` unless it actually releases the session.
hirofumi added a commit to hirofumi/slick that referenced this issue May 25, 2018
"count cannot be decreased" of issue slick#1856 seems to happen as follows:

1. `ctx.delivered(demand)` in a `PrioritizedRunnable` of
   `.scheduleSynchronousStreaming` returns 0.
2. A subscriber of `ctx` calls `ctx.request()`.
3. `ctx.request()` calls `.scheduleSynchronousStreaming` (via
   `.restartStreaming`) and it creates a new `PrioritizedRunnable`.
4. The new `PrioritizedRunnable` calls `releaseSession` and sets
   its `connectionReleased` true.
5. `PrioritizedRunnable` of the step 1 also sets its `connectionReleased`
   true because `ctx.currentSession` is released by step 4.
6. `decreaseInUseCount` is called twice because of the two
   `PrioritizedRunnable` with `connectionReleased`.

The above can be demonstrated by inserting `Thread.sleep(100L)` immediately
after `while ((state ne null) && realDemand > 0)`.

This commit resolves the problem by preventing `PrioritizedRunnable` from
setting `connectionReleased` unless it actually releases the session.
@nsitbon
Copy link

@nsitbon nsitbon commented Jan 18, 2019

I'm still having the same issue even with the latest version of slick (3.2.3) and number of connection = number of thread. This is really annoying because of I have another bug with my Sentry Logback appender which prevents me from dropping that kind of exception so my logs are full of this exceptions and it's really hard to see real exceptions among those.

abelbryo added a commit to abelbryo/slick that referenced this issue Jan 29, 2019
"count cannot be decreased" of issue slick#1856 seems to happen as follows:

1. `ctx.delivered(demand)` in a `PrioritizedRunnable` of
   `.scheduleSynchronousStreaming` returns 0.
2. A subscriber of `ctx` calls `ctx.request()`.
3. `ctx.request()` calls `.scheduleSynchronousStreaming` (via
   `.restartStreaming`) and it creates a new `PrioritizedRunnable`.
4. The new `PrioritizedRunnable` calls `releaseSession` and sets
   its `connectionReleased` true.
5. `PrioritizedRunnable` of the step 1 also sets its `connectionReleased`
   true because `ctx.currentSession` is released by step 4.
6. `decreaseInUseCount` is called twice because of the two
   `PrioritizedRunnable` with `connectionReleased`.

The above can be demonstrated by inserting `Thread.sleep(100L)` immediately
after `while ((state ne null) && realDemand > 0)`.

This commit resolves the problem by preventing `PrioritizedRunnable` from
setting `connectionReleased` unless it actually releases the session.
hvesalai added a commit that referenced this issue Jan 29, 2019
Avoid extra .decreaseInUseCount() of issue #1856
@hvesalai hvesalai modified the milestones: Future fix release, 3.3 Jan 29, 2019
@hvesalai hvesalai closed this Jan 29, 2019
@davidangb davidangb mentioned this issue Apr 23, 2019
0 of 22 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants