qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: [QPID JMS] receive with timeout and reconnect
Date Tue, 12 Mar 2019 14:04:08 GMT
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.HADI@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.gemmell@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.HADI@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.gemmell@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.VERMEULEN@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-unsubscribe@qpid.apache.org For
> > additional commands, e-mail: users-help@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-unsubscribe@qpid.apache.org For additional commands, e-mail:
users-help@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message