/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

AsyncExecutor requirement failed: count cannot be decreased #1856

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

Comments

Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
  3.3
2 participants
@hvesalai @nsitbon
@hvesalai
Copy link
Member

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() 
"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.
Loading status checks…
2bbc764

hirofumi added a commit to hirofumi/slick that referenced this issue May 25, 2018

@hirofumi
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.
Loading status checks…
2f7ee33

@hirofumi hirofumi referenced this issue May 25, 2018

Merged

Avoid extra .decreaseInUseCount() of issue #1856 #1914

@danbills danbills referenced this issue Jun 27, 2018

Open

java.lang.IllegalArgumentException: requirement failed: count cannot be decreased #3823

@nsitbon

This comment has been minimized.

Sign in to view
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

@hirofumi @abelbryo
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.
6efe7bd

hvesalai added a commit that referenced this issue Jan 29, 2019

@hvesalai
Merge pull request #1914 from hirofumi/topic/1856 
Avoid extra .decreaseInUseCount() of issue #1856
Verified
This commit was created on GitHub.com and signed with a verified signature using GitHub’s key.
GPG key ID: 4AEE18F83AFDEB23 Learn about signing commits
Loading status checks…
e809514

@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