You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by an...@uk.bnpparibas.com on 2010/06/22 16:18:42 UTC
Temporary queues and a WAN
As per the advice at
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
I am using temporary Qs for my replies. But I think there is a problem. I
am programming to an abstract interface of mine that I designed so that I
can switch between activeMQ-cpp and IBM MQSeries. When I switch to IBM I
get weird connectivity problems. I am told, by the IBM MQSeries admin that
temporary Qs are not expected to work over WANs. My client is in Paris
whilst the server is in London.
Because of various technical obstacles that I wont go into here, I am only
able to run with ActiveMQ locally. ActiveMQ is fine there and so is
IBM-MQSeries. I am not able to see if ActiveMQ would still work in the WAN
situation. But IBM does not seem to like it. What advice/recommendations
do people have please?
Regards,
Andrew Marlow
___________________________________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited.
Please refer to http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-845C5H for additional disclosures.
Re: Temporary queues and a WAN
Posted by an...@uk.bnpparibas.com.
Thanks for those clarifying comments. The answer is "yes, I can afford to
lose a reply.". There comes a point where the client will give up and then
it does not matter if the server completes the work or not. The work done
by the server is idempotent. So it does not matter if it is asked to do it
again during a reconnect.
Regards,
Andrew Marlow
Internet
gary.tully@gmail.com
22/06/2010 17:40
Please respond to
users@activemq.apache.org
To
users@activemq.apache.org
cc
Subject
Re: Temporary queues and a WAN
The choice of tempQ vs replyQ comes down to the need for a durable reply
which can help with idempotency. In the case of a tempq and your rcvd
table
(the failover transport has just such a table internally btw), on the
resend
there will be no indication of a potential previous reply as the tempQ
will
have been destroyed and been recreated.
With a replyQ, it is possible to determine if a reply already exists
because
any reply will have been persisted. So it comes down to the question: can
you loose a reply?
If you can't loose a reply and you need scalability, using a pool of reply
queues and some discriminator to choose a q may be a suitable pattern.
On 22 June 2010 16:43, <an...@uk.bnpparibas.com> wrote:
> I am aware of the fact that when using temp Qs the data goes away when
the
> connection is lost. I cope with this with some extra logic on the client
> side. It remembers each request via a table. Entries are removed from
this
> table when replies are rcvd. When the connection is lost a reconnect is
> done and the table is then used to resend any requests for which the
reply
> was pending.
>
> I am still puzzled as to what the received wisdom is regarding the use
of
> temporary queues. Are they of no practical use? I get around the problem
> of lost connections as per the above. And I do this because I thought
that
> temporary Qs are to be preferred to a reply Q for scalability reasons. I
> am not so sure now.... I note that a reply Q is a very common way of
doing
> client-server request-response despite the advice from the ActiveMQ web
> page. Hmmmm.
>
> Regards,
>
> Andrew Marlow
>
>
>
>
> Internet
> ivan.pechorin@gmail.com
> 22/06/2010 16:23
> Please respond to
> users@activemq.apache.org
>
>
> To
> users@activemq.apache.org
> cc
>
> Subject
> Re: Temporary queues and a WAN
>
>
>
>
>
>
> 2010/6/22 <an...@uk.bnpparibas.com>:
> > As per the advice at
> >
>
>
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
>
> > I am using temporary Qs for my replies.
> > ...
> >
> > Because of various technical obstacles that I wont go into here, I am
> only
> > able to run with ActiveMQ locally. ActiveMQ is fine there and so is
> > IBM-MQSeries. I am not able to see if ActiveMQ would still work in the
> WAN
> > situation. But IBM does not seem to like it. What
advice/recommendations
> > do people have please?
>
> As far as I understand, temporary queues in ActiveMQ are directly
> linked to client connection.
> If client connection to broker is interrupted, all the temporary
> queues created within this connection are lost.
> If there were any requests in the middle of processing, replies to
> these requests are lost (because ReplyTo destination specified in
> these requests is no longer valid).
> The same problem remains in case if client uses failover transport.
> That's why we don't use temporary queues for ReplyTo.
>
> ActiveMQ gurus, please correct me, if I am wrong.
> Actually, I didn't perform enough testing to be 100% sure of the
> statements above.
>
>
> ___________________________________________________________
> This e-mail may contain confidential and/or privileged information. If
you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is prohibited.
>
> Please refer to
>
http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-845C5H
for additional disclosures.
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
___________________________________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited.
Please refer to http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-845C5H for additional disclosures.
Re: Temporary queues and a WAN
Posted by Gary Tully <ga...@gmail.com>.
The choice of tempQ vs replyQ comes down to the need for a durable reply
which can help with idempotency. In the case of a tempq and your rcvd table
(the failover transport has just such a table internally btw), on the resend
there will be no indication of a potential previous reply as the tempQ will
have been destroyed and been recreated.
With a replyQ, it is possible to determine if a reply already exists because
any reply will have been persisted. So it comes down to the question: can
you loose a reply?
If you can't loose a reply and you need scalability, using a pool of reply
queues and some discriminator to choose a q may be a suitable pattern.
On 22 June 2010 16:43, <an...@uk.bnpparibas.com> wrote:
> I am aware of the fact that when using temp Qs the data goes away when the
> connection is lost. I cope with this with some extra logic on the client
> side. It remembers each request via a table. Entries are removed from this
> table when replies are rcvd. When the connection is lost a reconnect is
> done and the table is then used to resend any requests for which the reply
> was pending.
>
> I am still puzzled as to what the received wisdom is regarding the use of
> temporary queues. Are they of no practical use? I get around the problem
> of lost connections as per the above. And I do this because I thought that
> temporary Qs are to be preferred to a reply Q for scalability reasons. I
> am not so sure now.... I note that a reply Q is a very common way of doing
> client-server request-response despite the advice from the ActiveMQ web
> page. Hmmmm.
>
> Regards,
>
> Andrew Marlow
>
>
>
>
> Internet
> ivan.pechorin@gmail.com
> 22/06/2010 16:23
> Please respond to
> users@activemq.apache.org
>
>
> To
> users@activemq.apache.org
> cc
>
> Subject
> Re: Temporary queues and a WAN
>
>
>
>
>
>
> 2010/6/22 <an...@uk.bnpparibas.com>:
> > As per the advice at
> >
>
> http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
>
> > I am using temporary Qs for my replies.
> > ...
> >
> > Because of various technical obstacles that I wont go into here, I am
> only
> > able to run with ActiveMQ locally. ActiveMQ is fine there and so is
> > IBM-MQSeries. I am not able to see if ActiveMQ would still work in the
> WAN
> > situation. But IBM does not seem to like it. What advice/recommendations
> > do people have please?
>
> As far as I understand, temporary queues in ActiveMQ are directly
> linked to client connection.
> If client connection to broker is interrupted, all the temporary
> queues created within this connection are lost.
> If there were any requests in the middle of processing, replies to
> these requests are lost (because ReplyTo destination specified in
> these requests is no longer valid).
> The same problem remains in case if client uses failover transport.
> That's why we don't use temporary queues for ReplyTo.
>
> ActiveMQ gurus, please correct me, if I am wrong.
> Actually, I didn't perform enough testing to be 100% sure of the
> statements above.
>
>
> ___________________________________________________________
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is prohibited.
>
> Please refer to
> http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-845C5H for additional disclosures.
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
Re: Temporary queues and a WAN
Posted by an...@uk.bnpparibas.com.
I am aware of the fact that when using temp Qs the data goes away when the
connection is lost. I cope with this with some extra logic on the client
side. It remembers each request via a table. Entries are removed from this
table when replies are rcvd. When the connection is lost a reconnect is
done and the table is then used to resend any requests for which the reply
was pending.
I am still puzzled as to what the received wisdom is regarding the use of
temporary queues. Are they of no practical use? I get around the problem
of lost connections as per the above. And I do this because I thought that
temporary Qs are to be preferred to a reply Q for scalability reasons. I
am not so sure now.... I note that a reply Q is a very common way of doing
client-server request-response despite the advice from the ActiveMQ web
page. Hmmmm.
Regards,
Andrew Marlow
Internet
ivan.pechorin@gmail.com
22/06/2010 16:23
Please respond to
users@activemq.apache.org
To
users@activemq.apache.org
cc
Subject
Re: Temporary queues and a WAN
2010/6/22 <an...@uk.bnpparibas.com>:
> As per the advice at
>
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
> I am using temporary Qs for my replies.
> ...
>
> Because of various technical obstacles that I wont go into here, I am
only
> able to run with ActiveMQ locally. ActiveMQ is fine there and so is
> IBM-MQSeries. I am not able to see if ActiveMQ would still work in the
WAN
> situation. But IBM does not seem to like it. What advice/recommendations
> do people have please?
As far as I understand, temporary queues in ActiveMQ are directly
linked to client connection.
If client connection to broker is interrupted, all the temporary
queues created within this connection are lost.
If there were any requests in the middle of processing, replies to
these requests are lost (because ReplyTo destination specified in
these requests is no longer valid).
The same problem remains in case if client uses failover transport.
That's why we don't use temporary queues for ReplyTo.
ActiveMQ gurus, please correct me, if I am wrong.
Actually, I didn't perform enough testing to be 100% sure of the
statements above.
___________________________________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited.
Please refer to http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-845C5H for additional disclosures.
Re: Temporary queues and a WAN
Posted by Ivan Pechorin <iv...@gmail.com>.
2010/6/22 <an...@uk.bnpparibas.com>:
> As per the advice at
> http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
> I am using temporary Qs for my replies.
> ...
>
> Because of various technical obstacles that I wont go into here, I am only
> able to run with ActiveMQ locally. ActiveMQ is fine there and so is
> IBM-MQSeries. I am not able to see if ActiveMQ would still work in the WAN
> situation. But IBM does not seem to like it. What advice/recommendations
> do people have please?
As far as I understand, temporary queues in ActiveMQ are directly
linked to client connection.
If client connection to broker is interrupted, all the temporary
queues created within this connection are lost.
If there were any requests in the middle of processing, replies to
these requests are lost (because ReplyTo destination specified in
these requests is no longer valid).
The same problem remains in case if client uses failover transport.
That's why we don't use temporary queues for ReplyTo.
ActiveMQ gurus, please correct me, if I am wrong.
Actually, I didn't perform enough testing to be 100% sure of the
statements above.