Skip to content

/ slick

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

Jump to bottom

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
bug
Milestone
3.3

Comments

@hvesalai
Copy link
Member

@hvesalai hvesalai commented Mar 2, 2018 •
edited

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
@hirofumi
fix slick#1856: avoid unnecessary .decreaseInUseCount()
Loading status checks…
2bbc764 
"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
@hirofumi
Avoid extra .decreaseInUseCount() of issue slick#1856
Loading status checks…
2f7ee33 
"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.
@hirofumi hirofumi mentioned this issue May 25, 2018
Merged
@danbills danbills mentioned this issue Jun 27, 2018
Open
@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
@hirofumi @abelbryo
Avoid extra .decreaseInUseCount() of issue slick#1856
6efe7bd 
"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
@hvesalai
Merge pull request #1914 from hirofumi/topic/1856
Verified
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: 4AEE18F83AFDEB23 Learn about vigilant mode.
Loading status checks…
e809514 
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
Merged
0 of 22 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
3.3
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
@hvesalai @nsitbon