I guess it is probably blocking on beginning an attempt to drain the link credit as way to verify no messages before returning null. Setting the jms.receiveLocalOnly URI option true would stop it draining the link and so I guess let it return null instead of waiting for the failover process to complete.
I dont think I'd ever choose to throw from the consumer there, alternatively it could just return null repeatedly since thats what it does otherwise when there arent messages it can give. Robbie On Mon, 25 Feb 2019 at 10:16, VERMEULEN Olivier <[email protected]> wrote: > > Hello, > > We're using QPID JMS 0.39.0 with a set of reconnect options that makes the > client retry to connect for 2 hours in case of problem. > When doing a synchronous receive call with a smaller timeout (like 60 > seconds) we were expecting to receive a TimeOutException after 60 seconds but > we actually have to wait for the whole reconnect to end, so 2 hours. > Is that expected? We were expecting a behavior similar to the one we have > with the sendTimeout (defined at the level of the connection factory) where > the send fails but the reconnect continues behind the scene. > > Thanks, > Olivier > > ******************************* > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. If you are not the > intended recipient you are not authorized to distribute, copy or use this > e-mail or any attachment to it. Murex cannot guarantee that it is virus free > and accepts no responsibility for any loss or damage arising from its use. If > you have received this e-mail in error please notify immediately the sender > and delete the original email received, any attachments and all copies from > your system. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
