-
Notifications
You must be signed in to change notification settings - Fork 654
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
fix #289 Register pool-releasing close listener only if acquired #290
Conversation
…tually acquired
only set the channel closeFuture to release to the pool once we've made sure that we acquired a Channel.
Codecov Report
@@ Coverage Diff @@
## master #290 +/- ##
============================================
+ Coverage 67.78% 68.46% +0.68%
- Complexity 1015 1026 +11
============================================
Files 73 73
Lines 4287 4291 +4
Branches 611 613 +2
============================================
+ Hits 2906 2938 +32
+ Misses 1011 989 -22
+ Partials 370 364 -6
Continue to review full report at Codecov.
|
please heavily challenge the relevance of this fix. adding a little background on the issue itself. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review indicates the close listener is being invoked as many times as it has been acquired. Looking into this
public void fixedPoolTwoAcquire() | ||
throws ExecutionException, InterruptedException, IOException { | ||
final ScheduledExecutorService service = Executors.newScheduledThreadPool(2); | ||
int echoServerPort = SocketUtils.findAvailableTcpPort(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, this is not entirely reliable and can cause problems on CI servers, if some other process grabs the socket. We've seen this happen once in a while, causing bogus CI build failures.
In my projects, where possible, we've changed tests to listen on port 0 (so the OS selects the port) and then query the test server for which port was actually selected.
Not critical but worth consideration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hard to do as the first part of the test checks what happens when the host is initially unreachable. crossing fingers for CI :(
* Fix `StompServerIntegrationTests` for disabling connection pool to workaround the regression in the Reactor-Netty-0.7.4 Related to reactor/reactor-netty#290
* Fix `StompServerIntegrationTests` for disabling connection pool to workaround the regression in the Reactor-Netty-0.7.4 Related to reactor/reactor-netty#290
Instead of setting up the close listener in the ChannelPoolHandler
channelCreated method, set it up in the PooledClientContextHandler.
This should prevent the listener to be invoked after a FixedChannelPool
has determined the channel was not healthy and has already decremented
its internal acquire counter (which would lead to a second decrement of
said counter and an assertion error).