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

Comments

Projects
None yet
2 participants
@hvesalai
Copy link
Member

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

fix slick#1856: avoid unnecessary .decreaseInUseCount()
"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

Avoid extra .decreaseInUseCount() of issue slick#1856
"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

This comment has been minimized.

Copy link

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

Avoid extra .decreaseInUseCount() of issue slick#1856
"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

Merge pull request #1914 from hirofumi/topic/1856
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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment