CloseableChannel#dispose ignored
See original GitHub issueI am trying to shutdown a receiver RSocketFactory.receive()
through CloseableChannel#dispose
method but it seems not to be working. Here is a test that I expect to pass:
@Test
public void closeReceiver() throws InterruptedException {
int randomPort = ThreadLocalRandom.current().nextInt(10_000, 20_000);
AtomicInteger results = new AtomicInteger();
CountDownLatch errorLatch = new CountDownLatch(1);
CloseableChannel closeableChannel = RSocketFactory.receive()
.acceptor((setup, sendingSocket) -> {
return Mono.just(new AbstractRSocket() {
@Override
public Flux<Payload> requestStream(Payload payload) {
return Flux.interval(Duration.ofMillis(100))
.onBackpressureDrop()
.map(i -> DefaultPayload.create("Response-" +i));
}
});
})
.transport(TcpServerTransport.create(randomPort))
.start()
.block();
RSocket sender = RSocketFactory.connect()
.transport(TcpClientTransport.create(randomPort))
.start()
.block();
sender.requestStream(DefaultPayload.create("Request"))
.subscribe(new BaseSubscriber<Payload>() {
volatile Subscription subscription;
@Override
protected void hookOnSubscribe(Subscription subscription) {
this.subscription = subscription;
this.subscription.request(1);
closeableChannel.onClose()
.doFinally(signalType-> {
// request more, should produce an error as receiver no longer produce
subscription.request(Integer.MAX_VALUE);
})
.subscribe();
}
@Override
protected void hookOnNext(Payload value) {
if (results.compareAndSet(0, 1)) {
// expecting it to stop the server
closeableChannel.dispose();
} else {
results.getAndIncrement();
}
}
@Override
protected void hookOnError(Throwable throwable) {
if (throwable instanceof ClosedChannelException) {
errorLatch.countDown();
}
}
});
assertThat(errorLatch.await(1, TimeUnit.SECONDS))
.withFailMessage("ClosedChannelException is expected").isTrue();
assertThat(results.get()).isEqualTo(1);
}
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:11 (8 by maintainers)
Top Results From Across the Web
Rabbitmq Channel.Dispose vs channel = null - Stack Overflow
Ideally, Dispose should not throw exceptions. But if it does, you shouldn't just ignore them. Ask yourself: What caused the exception?
Read more >Should I call IConnection.Dispose or ... - Google Groups
Please use Close or Abort (the latter ignored some errors that may arise from the already closed socket and so on). MK.
Read more >Using and Disposing of WCF Clients - Passion for Coding
Dispose () unconditionally calls Close() . This will try to make a graceful shutdown of the communications channel with the server.
Read more >javax.security.sasl.SaslServer.dispose java code examples | Tabnine
private void disposeSasl() { if (saslServer != null) { try { saslServer.dispose(); } catch (SaslException ignored) { } finally { saslServer = null;...
Read more >13 Common RabbitMQ Mistakes and How to Avoid Them
Don't open and close connections or channels repeatedly. ... Try to keep the connection/channel count low. ... Don't ignore lazy queues.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi,
I am also having the same issue, in my test case I am trying to stop Rsocket server and reinitialize it to be able to see LoadbalancerMono client behaviour. However Rsocket server is never disposing
closeableChannel.dispose() rsocket.dispose()
But service is never going down even though I wait more than 2 seconds
Any estimate when this might be fixed ? Thanks
Starting from the 0.9.6 Reactor-Netty release (now used in RSocket RC7-SNAPSHOT) supports a built-in mechanism for graceful shutdown. For more information see https://github.com/reactor/reactor-netty/pull/1034.
It means that in case an RSocket user prefers to have a graceful shutdown enabled, it has to configure it on an appropriate Reactor-Netty based transport.