nats.java icon indicating copy to clipboard operation
nats.java copied to clipboard

Inbox dispatcher ends up closed while the connection is still open

Open humblemasood opened this issue 4 years ago • 3 comments
trafficstars

Hello. I use request-reply in my system and recently I started seeing an issue involving the inbox dispatcher. When the Connection.request call tries to create a return subscription, it runs into the error (see below for stack trace) where the dispatcher is closed. My assumption here is that the inbox dispatcher should never close (while the connection is open) or if it does then it should auto-recover. Does this sound right?

I was seeing this error while using old request style and since switching to new request style I dont see it anymore. I'm wondering what accounts for this change in behaviour?

Caught error while responding to gRPC stream: Dispatcher is closed. Handling with response: Status{code=FAILED_PRECONDITION, description=Dispatcher is closed, cause=java.lang.IllegalStateException: Dispatcher is closed
	at io.nats.client.impl.NatsDispatcher.subscribeImpl(NatsDispatcher.java:245)
	at io.nats.client.impl.NatsDispatcher.subscribeReturningSubscription(NatsDispatcher.java:202)
	at io.nats.client.impl.NatsConnection.request(NatsConnection.java:1072)
	at com.ea.poutine.dcs.sdk.nats.NatsPublisher$requestReply$2$2$deferredBrokerReply$1$1.invokeSuspend(NatsPublisher.kt:48)
	at com.ea.poutine.dcs.sdk.nats.NatsPublisher$requestReply$2$2$deferredBrokerReply$1$1.invoke(NatsPublisher.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturnIgnoreTimeout(Undispatched.kt:102)
	at kotlinx.coroutines.TimeoutKt.setupTimeout(Timeout.kt:148)
	at kotlinx.coroutines.TimeoutKt.withTimeout(Timeout.kt:44)
	at com.ea.poutine.dcs.sdk.nats.NatsPublisher$requestReply$2$2$deferredBrokerReply$1.invokeSuspend(NatsPublisher.kt:47)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)
}

Important Details Client version: 2.8.0

humblemasood avatar Jun 17 '21 15:06 humblemasood

@humblemasood Can you please try with the latest version (2.11.4 at this writing). I'm not suggesting that will fix the problem, I just want you to be on the latest code. What version of the server are you running against? If you can repeat it with the latest client, could you please post some code or more detail so I can try to reproduce this?

scottf avatar Jun 19 '21 15:06 scottf

I will try to reproduce it today and let you know how it goes. I use 2.1.7 for the server

humblemasood avatar Jun 22 '21 15:06 humblemasood

@scottf I haven't been able to reproduce the issue using the latest client

humblemasood avatar Jun 22 '21 22:06 humblemasood