[QPID JMS] receive with timeout and reconnect

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[QPID JMS] receive with timeout and reconnect

VERMEULEN Olivier
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.
Reply | Threaded
Open this post in threaded view
|

Re: [QPID JMS] receive with timeout and reconnect

Robbie Gemmell
Administrator
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
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [QPID JMS] receive with timeout and reconnect

HADI Ali
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 <[hidden email]>
Sent: mardi 26 février 2019 17:27
To: [hidden email]
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 <[hidden email]> 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: [hidden email] For additional commands, e-mail: [hidden email]

*******************************
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [QPID JMS] receive with timeout and reconnect

Robbie Gemmell
Administrator
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 <[hidden email]> 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 <[hidden email]>
> Sent: mardi 26 février 2019 17:27
> To: [hidden email]
> 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 <[hidden email]> 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: [hidden email] For additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [QPID JMS] receive with timeout and reconnect

HADI Ali
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 <[hidden email]>
Sent: lundi 11 mars 2019 15:51
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
> Sent: mardi 26 février 2019 17:27
> To: [hidden email]
> 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 <[hidden email]> 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: [hidden email] For
> additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email] For additional commands, e-mail: [hidden email]

*******************************
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [QPID JMS] receive with timeout and reconnect

Robbie Gemmell
Administrator
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 <[hidden email]> 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 <[hidden email]>
> Sent: lundi 11 mars 2019 15:51
> To: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: mardi 26 février 2019 17:27
> > To: [hidden email]
> > 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 <[hidden email]> 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
> > *******************************
> > 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: [hidden email] For additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [QPID JMS] receive with timeout and reconnect

HADI Ali
In our C++ API we chose to return an exception if the server doesn’t respond because the client needs to differentiate between receiving with no message available and server not responding (or down) because he will react differently.
Anyway, the most important thing for us is to respect the timeout limit set by the client on the receive operation, independently of the reconnect parameters.
Whether it will return an exception or a NULL message is an acceptable solution for us.

Regards,
Ali

-----Original Message-----
From: Robbie Gemmell <[hidden email]>
Sent: mardi 12 mars 2019 15:04
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
> Sent: lundi 11 mars 2019 15:51
> To: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: mardi 26 février 2019 17:27
> > To: [hidden email]
> > 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 <[hidden email]> 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
> > *******************************
> > 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: [hidden email] For
> additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email] For
> additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]

*******************************
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [QPID JMS] receive with timeout and reconnect

HADI Ali
Hello,

Any updates on this issue? Do you think it is feasible to return a NULL message at the end of the timeout?
If yes, should we create a Jira ticket corresponding to this issue?

Regards,
Ali

-----Original Message-----
From: HADI Ali
Sent: mercredi 13 mars 2019 11:54
To: [hidden email]
Subject: RE: [QPID JMS] receive with timeout and reconnect

In our C++ API we chose to return an exception if the server doesn’t respond because the client needs to differentiate between receiving with no message available and server not responding (or down) because he will react differently.
Anyway, the most important thing for us is to respect the timeout limit set by the client on the receive operation, independently of the reconnect parameters.
Whether it will return an exception or a NULL message is an acceptable solution for us.

Regards,
Ali

-----Original Message-----
From: Robbie Gemmell <[hidden email]>
Sent: mardi 12 mars 2019 15:04
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
> Sent: lundi 11 mars 2019 15:51
> To: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: mardi 26 février 2019 17:27
> > To: [hidden email]
> > 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 <[hidden email]> 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
> > *******************************
> > 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: [hidden email] For
> additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email] For
> additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]

*******************************
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [QPID JMS] receive with timeout and reconnect

VERMEULEN Olivier
In reply to this post by Robbie Gemmell
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 <[hidden email]>
Sent: mardi 12 mars 2019 15:04
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
> Sent: lundi 11 mars 2019 15:51
> To: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: mardi 26 février 2019 17:27
> > To: [hidden email]
> > 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 <[hidden email]> 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
> > *******************************
> > 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: [hidden email] For
> additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email] For
> additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]

*******************************
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [QPID JMS] receive with timeout and reconnect

Robbie Gemmell
Administrator
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
<[hidden email]> 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 <[hidden email]>
> Sent: mardi 12 mars 2019 15:04
> To: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: lundi 11 mars 2019 15:51
> > To: [hidden email]
> > 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 <[hidden email]> 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 <[hidden email]>
> > > Sent: mardi 26 février 2019 17:27
> > > To: [hidden email]
> > > 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 <[hidden email]> 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: [hidden email] For
> > > additional commands, e-mail: [hidden email]
> > >
> > > *******************************
> > > 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
> > *******************************
> > 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [QPID JMS] receive with timeout and reconnect

VERMEULEN Olivier
Hello Robbie,

I completely agree that we should not tie our code to a specific JMS provider.

"such that there is obviously no message available in the time it is doing that"
I didn't get your point here. If my receiver enters a reconnect loop there might still be available messages pending in the broker.

In the end I guess it's mainly a question of feedback at the level of our JMS client.
Even if we reconnect for hours we want our client to be notified quickly that something is going wrong...

Olivier

-----Original Message-----
From: Robbie Gemmell <[hidden email]>
Sent: lundi 1 avril 2019 14:13
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
> Sent: mardi 12 mars 2019 15:04
> To: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: lundi 11 mars 2019 15:51
> > To: [hidden email]
> > 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 <[hidden email]> 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 <[hidden email]>
> > > Sent: mardi 26 février 2019 17:27
> > > To: [hidden email]
> > > 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 <[hidden email]> 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: [hidden email] For
> > > additional commands, e-mail: [hidden email]
> > >
> > > *******************************
> > > 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
> > *******************************
> > 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] For
> additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email] For additional commands, e-mail: [hidden email]

*******************************
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [QPID JMS] receive with timeout and reconnect

HADI Ali
In reply to this post by Robbie Gemmell
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 <[hidden email]>
Sent: lundi 1 avril 2019 14:13
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
> Sent: mardi 12 mars 2019 15:04
> To: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: lundi 11 mars 2019 15:51
> > To: [hidden email]
> > 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 <[hidden email]> 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 <[hidden email]>
> > > Sent: mardi 26 février 2019 17:27
> > > To: [hidden email]
> > > 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 <[hidden email]> 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: [hidden email] For
> > > additional commands, e-mail: [hidden email]
> > >
> > > *******************************
> > > 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
> > *******************************
> > 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: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] For
> additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email] For additional commands, e-mail: [hidden email]

*******************************
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [QPID JMS] receive with timeout and reconnect

Robbie Gemmell
Administrator
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 <[hidden email]> 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 <[hidden email]>
> Sent: lundi 1 avril 2019 14:13
> To: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: mardi 12 mars 2019 15:04
> > To: [hidden email]
> > 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 <[hidden email]> 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 <[hidden email]>
> > > Sent: lundi 11 mars 2019 15:51
> > > To: [hidden email]
> > > 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 <[hidden email]> 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 <[hidden email]>
> > > > Sent: mardi 26 février 2019 17:27
> > > > To: [hidden email]
> > > > 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 <[hidden email]> 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: [hidden email] For
> > > > additional commands, e-mail: [hidden email]
> > > >
> > > > *******************************
> > > > 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: [hidden email] For
> > > additional commands, e-mail: [hidden email]
> > >
> > > *******************************
> > > 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: [hidden email] For
> > > additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email] For
> > additional commands, e-mail: [hidden email]
> >
> > *******************************
> > 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: [hidden email] For additional commands, e-mail: [hidden email]
>
> *******************************
> 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: [hidden email]
For additional commands, e-mail: [hidden email]