You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by blueshed <pe...@blueshed.co.uk> on 2006/08/22 10:56:59 UTC
Stomp Receipts
I have built an asynchronous stomp client that works well enough. I tried to
introduce a synchronous stomp client but came across a problem: reciepts are
sent out of order. When I send a SUBCRIBE I get a MESSAGE back before the
RECEIPT - the MESSAGE requires an ACK before I get any more messages. The
ACK too requests a RECEIPT and then two RECEIPTS come back. I would like my
Stomp Client to work with Twisted Python and it is single threaded. I would
like to work with messages in order with as little state as possible. Any
thoughts? Could message consumption on the server complete the consumption
before sending more messages?
--
View this message in context: http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5921824
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Stomp Receipts
Posted by James Strachan <ja...@gmail.com>.
On 8/22/06, blueshed <pe...@blueshed.co.uk> wrote:
>
> Because you're function waitForReceipt() cannot work if a message comes
> before a receipt if the subscription is activemq.prefetchSize=1 as the
> server will wait for an ack to the message before sending RECEIPT(SUBSCRIBE)
> and RECEIPT(ACK)! The server is waiting. RECEIPTs and ERRORs should be sent
> before MESSAGEs when the prefetch is 1 or not be part of the prefetch
> mechanism.
>
> Sorry to be confusing - it has been a long march for me to get to this
> point. Without this concept I cannot have a blocking send within a
> transaction where I handle both SEND and RECEIVE on the same thread.
> MESSAGE, ACK AND RECEIPT are all part of one message delivery as is
> SUBSCRIBE, RECEIPT before MESSAGE.
Am still a little confused here.
To create a single threaded blocking SEND, can't you send the message
then keep reading inbound commands until you find a RECEIPT for it -
putting any other inbound commands in a list to be processed after the
SEND is complete?
BTW are you trying to do request/response stuff here? If so I'd
recommend you create a subscription up front first before doing any
sending....
http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html
--
James
-------
http://radio.weblogs.com/0112098/
Re: Stomp Receipts
Posted by blueshed <pe...@blueshed.co.uk>.
Because you're function waitForReceipt() cannot work if a message comes
before a receipt if the subscription is activemq.prefetchSize=1 as the
server will wait for an ack to the message before sending RECEIPT(SUBSCRIBE)
and RECEIPT(ACK)! The server is waiting. RECEIPTs and ERRORs should be sent
before MESSAGEs when the prefetch is 1 or not be part of the prefetch
mechanism.
Sorry to be confusing - it has been a long march for me to get to this
point. Without this concept I cannot have a blocking send within a
transaction where I handle both SEND and RECEIVE on the same thread.
MESSAGE, ACK AND RECEIPT are all part of one message delivery as is
SUBSCRIBE, RECEIPT before MESSAGE.
Hiram Chirino wrote:
>
> On 8/22/06, blueshed <pe...@blueshed.co.uk> wrote:
>>
>> That would help. But surely the same mechanism could be used with single
>> outstanding messages as then an ACK with a RECEPIT would also mean that I
>> would get the RECIEPT before the next message?
>>
>> I have not problem with the asychronous nature of the messaging, just the
>> order of messages. I cannot put it in a buffer, because not further
>> messages
>> come until I ack and the ack has a receipt request on it - so I am
>> effectively blocked.
>>
>
> I don't follow. no further messages come, but RECEIPTS will still come.
>
> Lets say we have the following code... send subscribe, wait for it's
> ack, and get 2 messages:
>
> client sends SUBSCRIBE;
> waitForReceipt() ;
> receiveWithAutoAck();
> receiveWithAutoAck();
>
> if receiveWithAutoAck waitForReceipt are implemented as follows I
> don't see how out of order async RECEIPTS would be a problem.
>
> receiveWithAutoAck() {
> if ( buffer is empty ) {
> client blocks reading socket
> client receives MESSAGE
> } else {
> get the first message from the buffer.
> }
> client sends ACK
> waitForReceipt();
> return the message;
> }
>
> waitForReceipt() {
> while (have not receive receipt) {
> client blocks reading socket
> if( we get a MESSAGE )
> add MESSAGE to the end of the buffer
> else
> return the receipt
> }
> }
>
>
>>
>> James.Strachan wrote:
>> >
>> > On 8/22/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> >> Hi Peter,
>> >>
>> >> Yes.. Unfortunately this is how asynchronous messaging works. There
>> >> is no way around it unless you switch to a request/reply model like
>> >> HTTP uses. But then you loose all the performance gains that a
>> >> asynchronous model provides!
>> >>
>> >> If your application is single threaded, you should place those
>> >> unexpected messages into a buffer while your are polling for your
>> >> response. Then when your application does a receive(), it should
>> >> first check that buffer for messages and nothing is there, then it
>> >> should wait on the socket for dispatched messages.
>> >
>> > Agreed - though maybe we could enforce the RECEIPT of the SUBSCRIBE
>> > first before we dispatch any messages?
>> > --
>> >
>> > James
>> > -------
>> > http://radio.weblogs.com/0112098/
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5933510
>> Sent from the ActiveMQ - User forum at Nabble.com.
>>
>>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
>
--
View this message in context: http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5935067
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Stomp Receipts
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 8/22/06, blueshed <pe...@blueshed.co.uk> wrote:
>
> That would help. But surely the same mechanism could be used with single
> outstanding messages as then an ACK with a RECEPIT would also mean that I
> would get the RECIEPT before the next message?
>
> I have not problem with the asychronous nature of the messaging, just the
> order of messages. I cannot put it in a buffer, because not further messages
> come until I ack and the ack has a receipt request on it - so I am
> effectively blocked.
>
I don't follow. no further messages come, but RECEIPTS will still come.
Lets say we have the following code... send subscribe, wait for it's
ack, and get 2 messages:
client sends SUBSCRIBE;
waitForReceipt() ;
receiveWithAutoAck();
receiveWithAutoAck();
if receiveWithAutoAck waitForReceipt are implemented as follows I
don't see how out of order async RECEIPTS would be a problem.
receiveWithAutoAck() {
if ( buffer is empty ) {
client blocks reading socket
client receives MESSAGE
} else {
get the first message from the buffer.
}
client sends ACK
waitForReceipt();
return the message;
}
waitForReceipt() {
while (have not receive receipt) {
client blocks reading socket
if( we get a MESSAGE )
add MESSAGE to the end of the buffer
else
return the receipt
}
}
>
> James.Strachan wrote:
> >
> > On 8/22/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> >> Hi Peter,
> >>
> >> Yes.. Unfortunately this is how asynchronous messaging works. There
> >> is no way around it unless you switch to a request/reply model like
> >> HTTP uses. But then you loose all the performance gains that a
> >> asynchronous model provides!
> >>
> >> If your application is single threaded, you should place those
> >> unexpected messages into a buffer while your are polling for your
> >> response. Then when your application does a receive(), it should
> >> first check that buffer for messages and nothing is there, then it
> >> should wait on the socket for dispatched messages.
> >
> > Agreed - though maybe we could enforce the RECEIPT of the SUBSCRIBE
> > first before we dispatch any messages?
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5933510
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Stomp Receipts
Posted by blueshed <pe...@blueshed.co.uk>.
That would help. But surely the same mechanism could be used with single
outstanding messages as then an ACK with a RECEPIT would also mean that I
would get the RECIEPT before the next message?
I have not problem with the asychronous nature of the messaging, just the
order of messages. I cannot put it in a buffer, because not further messages
come until I ack and the ack has a receipt request on it - so I am
effectively blocked.
James.Strachan wrote:
>
> On 8/22/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> Hi Peter,
>>
>> Yes.. Unfortunately this is how asynchronous messaging works. There
>> is no way around it unless you switch to a request/reply model like
>> HTTP uses. But then you loose all the performance gains that a
>> asynchronous model provides!
>>
>> If your application is single threaded, you should place those
>> unexpected messages into a buffer while your are polling for your
>> response. Then when your application does a receive(), it should
>> first check that buffer for messages and nothing is there, then it
>> should wait on the socket for dispatched messages.
>
> Agreed - though maybe we could enforce the RECEIPT of the SUBSCRIBE
> first before we dispatch any messages?
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
--
View this message in context: http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5933510
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Stomp Receipts
Posted by James Strachan <ja...@gmail.com>.
On 8/22/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Peter,
>
> Yes.. Unfortunately this is how asynchronous messaging works. There
> is no way around it unless you switch to a request/reply model like
> HTTP uses. But then you loose all the performance gains that a
> asynchronous model provides!
>
> If your application is single threaded, you should place those
> unexpected messages into a buffer while your are polling for your
> response. Then when your application does a receive(), it should
> first check that buffer for messages and nothing is there, then it
> should wait on the socket for dispatched messages.
Agreed - though maybe we could enforce the RECEIPT of the SUBSCRIBE
first before we dispatch any messages?
--
James
-------
http://radio.weblogs.com/0112098/
Re: Stomp Receipts
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Peter,
Yes.. Unfortunately this is how asynchronous messaging works. There
is no way around it unless you switch to a request/reply model like
HTTP uses. But then you loose all the performance gains that a
asynchronous model provides!
If your application is single threaded, you should place those
unexpected messages into a buffer while your are polling for your
response. Then when your application does a receive(), it should
first check that buffer for messages and nothing is there, then it
should wait on the socket for dispatched messages.
On 8/22/06, blueshed <pe...@blueshed.co.uk> wrote:
>
> Yup, the prefetchSize is 1 - but still I get back the MESSAGE before the
> RECEIPT. The ACK is required before more messages such as RECEIPT can come
> through.
>
> Perhaps this will explain:
>
> ->CONNECTED
> <-SUBSCRIBE
> ->MESSAGE
> <-ACK
> ->RECEIPT(SUBSCRIBE)
> ->RECIEPT(ACK)
>
> I hoped I could run it like this:
>
> ->CONNECTED
> <-SUBSCRIBE
> ->RECEIPT(SUBSCRIBE)
> ->MESSAGE
> <-ACK
> ->RECIEPT(ACK)
>
> PeterB
> PS. Thanks for getting back to first mail so quickly.
>
>
>
>
>
> James.Strachan wrote:
> >
> > If you set the prefetchSize to 1 then you will only be given 1 message
> > by your subscription so that you can ACK the message, then you'll be
> > given another message etc.
> >
> > http://incubator.apache.org/activemq/stomp.html
> >
> > e.g. add the following header
> >
> > activemq.prefetchSize: 1
> >
> > More background here
> > http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html
> >
> > On 8/22/06, blueshed <pe...@blueshed.co.uk> wrote:
> >>
> >> I have built an asynchronous stomp client that works well enough. I tried
> >> to
> >> introduce a synchronous stomp client but came across a problem: reciepts
> >> are
> >> sent out of order. When I send a SUBCRIBE I get a MESSAGE back before the
> >> RECEIPT - the MESSAGE requires an ACK before I get any more messages. The
> >> ACK too requests a RECEIPT and then two RECEIPTS come back. I would like
> >> my
> >> Stomp Client to work with Twisted Python and it is single threaded. I
> >> would
> >> like to work with messages in order with as little state as possible. Any
> >> thoughts? Could message consumption on the server complete the
> >> consumption
> >> before sending more messages?
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5921824
> >> Sent from the ActiveMQ - User forum at Nabble.com.
> >>
> >>
> >
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5924444
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Stomp Receipts
Posted by blueshed <pe...@blueshed.co.uk>.
Yup, the prefetchSize is 1 - but still I get back the MESSAGE before the
RECEIPT. The ACK is required before more messages such as RECEIPT can come
through.
Perhaps this will explain:
->CONNECTED
<-SUBSCRIBE
->MESSAGE
<-ACK
->RECEIPT(SUBSCRIBE)
->RECIEPT(ACK)
I hoped I could run it like this:
->CONNECTED
<-SUBSCRIBE
->RECEIPT(SUBSCRIBE)
->MESSAGE
<-ACK
->RECIEPT(ACK)
PeterB
PS. Thanks for getting back to first mail so quickly.
James.Strachan wrote:
>
> If you set the prefetchSize to 1 then you will only be given 1 message
> by your subscription so that you can ACK the message, then you'll be
> given another message etc.
>
> http://incubator.apache.org/activemq/stomp.html
>
> e.g. add the following header
>
> activemq.prefetchSize: 1
>
> More background here
> http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html
>
> On 8/22/06, blueshed <pe...@blueshed.co.uk> wrote:
>>
>> I have built an asynchronous stomp client that works well enough. I tried
>> to
>> introduce a synchronous stomp client but came across a problem: reciepts
>> are
>> sent out of order. When I send a SUBCRIBE I get a MESSAGE back before the
>> RECEIPT - the MESSAGE requires an ACK before I get any more messages. The
>> ACK too requests a RECEIPT and then two RECEIPTS come back. I would like
>> my
>> Stomp Client to work with Twisted Python and it is single threaded. I
>> would
>> like to work with messages in order with as little state as possible. Any
>> thoughts? Could message consumption on the server complete the
>> consumption
>> before sending more messages?
>> --
>> View this message in context:
>> http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5921824
>> Sent from the ActiveMQ - User forum at Nabble.com.
>>
>>
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
--
View this message in context: http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5924444
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Stomp Receipts
Posted by James Strachan <ja...@gmail.com>.
If you set the prefetchSize to 1 then you will only be given 1 message
by your subscription so that you can ACK the message, then you'll be
given another message etc.
http://incubator.apache.org/activemq/stomp.html
e.g. add the following header
activemq.prefetchSize: 1
More background here
http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html
On 8/22/06, blueshed <pe...@blueshed.co.uk> wrote:
>
> I have built an asynchronous stomp client that works well enough. I tried to
> introduce a synchronous stomp client but came across a problem: reciepts are
> sent out of order. When I send a SUBCRIBE I get a MESSAGE back before the
> RECEIPT - the MESSAGE requires an ACK before I get any more messages. The
> ACK too requests a RECEIPT and then two RECEIPTS come back. I would like my
> Stomp Client to work with Twisted Python and it is single threaded. I would
> like to work with messages in order with as little state as possible. Any
> thoughts? Could message consumption on the server complete the consumption
> before sending more messages?
> --
> View this message in context: http://www.nabble.com/Stomp-Receipts-tf2145063.html#a5921824
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
James
-------
http://radio.weblogs.com/0112098/