Correct, its not possible for local-only operation while disabling prefetching, as thats necessarily requiring remote-only.
While the cases are related I'd also consider the two situations somwhat different, in that the sender already has a message to process while the receiver does not and may not for the entire time you have configured things to consider the connection not failed. As I said, I probably wouldnt throw in this case but it could perhaps return null over and over again, though doing so would be tricky as there are a bunch more mechanics in the receiver and disabling prefetch further complicates matters as youve partly seen. Robbie On Fri, 8 Mar 2019 at 14:02, HADI Ali <[email protected]> wrote: > > Hello, > > According to the documentation the jms.receiveLocalOnly URI option will make > the receive calls with a timeout will only check a consumers local message > buffer. This option will solve the receive with timeout issue only if we are > prefetching messages. > > In our case, our prefetch policy is set to zero. Can’t the receive with > timeout behave the same way the send timeout does? As a client of the JMS > API, I would expect the receive with timeout to exit in the worst case when > the timeout expires no matter what is happening in the background ( Reconnect > option triggered ). > > Regards, > Ali > > -----Original Message----- > From: Robbie Gemmell <[email protected]> > Sent: mardi 26 février 2019 17:27 > To: [email protected] > Subject: Re: [QPID JMS] receive with timeout and reconnect > > 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] > > ******************************* > 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]
