Is timeout possible for subscriber to exclusive queue?
I'm looking for a way to timeout a stuck or stopped, not terminated subscriber to an exclusive queue on a VMR.
What I've set on the session so far seems like not be sufficient:
JCSMPProperties.MESSAGE_CALLBACK_ON_REACTOR, true
MESSAGE_ACK_MODE, JCSMPProperties.SUPPORTED_MESSAGE_ACK_CLIENT
JCSMPProperties.SUB_ACK_WINDOW_SIZE, 1
JCSMPProperties.SUB_ACK_TIME, 500
JCSMPChannelProperties.setKeepAliveIntervalInMillis 1000
JCSMPChannelProperties.setKeepAliveLimit, 3
Please, is there a way to timeout an active subscriber so the next consumer to that exclusive queue would continue and take over active?
Comments
-
Hey Falk..! Only way for a message to be redelivered off a queue to someone else, and only way for another client to be made active, is for the currently active consumer to unbind from the queue or disconnect from the broker. There is no timeout.
You could engineer something "externally" to force a stuck client to disconnect. Would involve monitoring it somehow, or monitoring the queue to find out if a message has been sitting for too long. And then issuing a SEMP command to disconnect. Definitely not elegant. Much better if subscriber itself was self-regulating and disconnected when it got stuck.
BTW, careful with dispatch on reactor: since the onMessage callback runs on the same thread as reading from the socket and other timers, do not do anything in the callback to block that thread. Much safer to leave dispatch on reactor == false... I've done tests on latency and it makes almost no difference. However, if your callback is only inserting the message into a queue/pool for processing later by application threads, then nevermind..!
1 -
Hey @FalkLademann, I can't add much to @Aaron's answer here except one way to monitor application activity and connectivity is via liveness signals - send a periodic (say every 5s) "I'm alive" on a special liveness topic. A monitor app could then issue a SEMP command to disconnect this client if it misses say 3.
0 -
Thanks @TomF and @Aaron for the quick feedback, very much appreciated.
Indeed the solution as you both outline is exactly what I thought about, was hoping to avoid this workaround in case I would have overlooked something.
JCSMPProperties.MESSAGE_CALLBACK_ON_REACTOR is in there as the use case would favor low latency over throughput, not done measurements yet.0 -
@FalkLademann If you have latency requirements, have you tried the JavaRTO API? A Java interface with no garbage collection, so no need to wait for JVM warm up.
0
