The send can be configured to timeout because it already started processing an existing message by that point, there is some outstanding sendable message actively not being handled, whereas in this case the receiver it has no message and will get no message because the connection isnt currently connected but also hasnt 'failed', per your explicit reconnect config. What you suggest below would likely still cause an exception from the consumer (and if consistent with the actual drain timeout, applicable while actually connected to a server and started doing a drain, that would then need to kill the consumer). Per earlier discussion I dont think that is a good idea as it cant really be handled specifically without tying the application to provider implementation classes which is inadvisable, and avoiding doing that just gets you back to about the same overall place. Doing something different that returns null repeatedly might be possible, abeit more complex. As noted originally thats actually already possible in the general case with some config, just not in the 0 prefetch case you would like which is what balloons the complexity.
Robbie On Fri, 26 Apr 2019 at 09:52, HADI Ali <ali.h...@murex.com> wrote: > > Hello Robbie, > > To make a parallel with all other actions, a timeout (sendTimeout or > requestTimeout) is always added at the level of the FailoverRequest so that > the action won't necessarily wait the end of the retry to fail, hence an > exception can be thrown. In our case this makes a big difference since our > retry can take up to 2 hours and the user may want to be notified that there > is an error server side while trying to reconnect. > However we agree that the receive action is much more complex. When the user > is not specifying a timeout, the actual behavior makes perfect sense since > the user doesn’t want to continue unless he gets a message. However when > specifying a timeout and after this timeout is reached, we can consider being > in the same configuration as the others actions. Maybe we can expose the > drainTimeout and add in the FailoverRequest for the pull action the sum of > the actual receiveTimeout + drainTimeout. Indeed the drainTimeout represents > how long we want to wait after the receiveTimeout before considering the > server as not responding. > > Regards, > Ali > > -----Original Message----- > From: Robbie Gemmell <robbie.gemm...@gmail.com> > Sent: lundi 1 avril 2019 14:13 > To: users@qpid.apache.org > Subject: Re: [QPID JMS] receive with timeout and reconnect > > I wouldn't consider it an internal error that you have expressly configured > the client to sit reconnecting and it is currently doing so, such that there > is obviously no message available in the time it is doing that but also no > final connection failure since you have configured it not to fail the > connection without hours of retry. As result I would not choose to throw an > exception from receive() in that scenario. Theres also not much you can > reasonably do with an exception there either except try the consumer again > regardless, or close the consumer immediately and then do something like try > creating a new one (which is going to run into the reconnections again), or > perhaps cleaning up entirely and creating a new connection (which your > reconnect config suggests you dont want to do) getting largely back to square > one. Since exceptions would be impl-only in this case, using > provider-specific exception handling to discern detail and adjust behaviour > would be tying your code non portably to that JMS provider impl, not > something I'd recommend. > > Robbie > > On Wed, 27 Mar 2019 at 14:56, VERMEULEN Olivier <olivier.vermeu...@murex.com> > wrote: > > > > Hello Robbie, > > > > The behavior we expect from the receive with timeout actually comes from > > our understanding of the JMS documentation (that may be wrong). > > > > " This call blocks until a message arrives, the timeout expires, or this > > message consumer is closed. " > > That's why we are expecting the receive to return (with a null value or an > > exception, that's the second question) after the receive timeout and not > > after the whole reconnect process which is set to 2 hours in our case. > > > > Now regarding what should be returned/thrown, the doc says: > > " Throws: JMSException - if the JMS provider fails to receive the next > > message due to some internal error." > > Isn't it the case here, we actually failed to receive the next message, no? > > > > Thanks, > > Olivier > > > > -----Original Message----- > > From: Robbie Gemmell <robbie.gemm...@gmail.com> > > Sent: mardi 12 mars 2019 15:04 > > To: users@qpid.apache.org > > Subject: Re: [QPID JMS] receive with timeout and reconnect > > > > I wouldn't use an exception if the server was known to be down and the > > client has been explicitly configured to keep reconnecting. If the > > reconnections are ultimately exhausted, then an exception is appropriate. > > > > If the connection is considered live and the server doesnt respond, then an > > exception is also reasonable. The JMS client does that and closes the > > consumer entirely, since if a drain attempt doesnt complete (with messages > > or without) you then cant reason about future attempts properly. > > > > Robbie > > > > On Mon, 11 Mar 2019 at 16:33, HADI Ali <ali.h...@murex.com> wrote: > > > > > > Hello, > > > > > > We agree that the send and receive operations are different because in > > > the case of the receive we can reach the timeout even if the sender is > > > responding correctly ( no message available ). > > > > > > We already faced this issue in the implementation of the receive function > > > in our synchronous C++ API and we solved it by separating the two > > > different receive cases : > > > - Receiving with no message available : The drain call will not hang > > > meaning the server is responding and no messages are available so we can > > > return NULL to the receiver. > > > - Receiving while the server is hanging : The drain call will hang > > > because the server is not responding meaning we should return an > > > exception ( same as the send timeout ). > > > > > > What do you think of this approach? > > > > > > Regards, > > > Ali > > > > > > -----Original Message----- > > > From: Robbie Gemmell <robbie.gemm...@gmail.com> > > > Sent: lundi 11 mars 2019 15:51 > > > To: users@qpid.apache.org > > > Subject: Re: [QPID JMS] receive with timeout and reconnect > > > > > > 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 <ali.h...@murex.com> 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 <robbie.gemm...@gmail.com> > > > > Sent: mardi 26 février 2019 17:27 > > > > To: users@qpid.apache.org > > > > 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 > > > > <olivier.vermeu...@murex.com> 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: users-unsubscr...@qpid.apache.org For > > > > additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > ******************************* > > > > 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: users-unsubscr...@qpid.apache.org For > > > additional commands, e-mail: users-h...@qpid.apache.org > > > > > > ******************************* > > > 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: users-unsubscr...@qpid.apache.org For > > > additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For > > additional commands, e-mail: users-h...@qpid.apache.org > > > > ******************************* > > 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: users-unsubscr...@qpid.apache.org For additional > commands, e-mail: users-h...@qpid.apache.org > > ******************************* > 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: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
