| Author |
Message |
|
| Guest |
 Posted: Tue Jan 05, 2010 12:22 pm |
 |
|
|
Guest
|
I've been wanting to incorporate Channel.Flow method handling into the Bunny Ruby client library for a while. It's needed, but I want to do it in a simple, efficient way. I want to be able to give a client application the option to stop sending messages as soon as possible after receiving a Channel.Flow method (with :active => false) and that means that I need to know whether a Basic.Publish succeeds as well as whether it fails.
At the moment there is the potential for a client application to keep firing messages at the server whilst being oblivious to the fact that the server is telling it to stop. If the client application is just writing and not reading, purely a publisher of messages, then there has to be an efficient way of notifying the client that a publish has succeeded. As far as I can see, the simplest way to do that is with a publish-ok.
Transactions may give me what I want but I don't think that I should be enforcing the use of transactions in my client library just so that it will handle Channel.Flow methods properly.
Regards,
Chris
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jan 05, 2010 1:37 pm |
|
|
|
Guest
|
Chris
I agree that use of TX, especially around a single message, is a bit
hefty for many cases, especially in the presence of persistence. A
form of asynchronous ack is possible with TX too, but of course that
is not really what you are asking about.
The interesting phenomenon here, IMO, is the relationship between flow
control and (n)acks. It would be good to make this clearer either
within or as an extension of 0-8/0-91. I'll leave it to others to
comment on your proposed approach.
alexis
On Tue, Jan 5, 2010 at 12:21 PM, Chris Duncan <celldee@gmail.com> wrote:
> I've been wanting to incorporate Channel.Flow method handling into the Bunny
> Ruby client library for a while. It's needed, but I want to do it in a
> simple, efficient way. I want to be able to give a client application the
> option to stop sending messages as soon as possible after receiving a
> Channel.Flow method (with :active => false) and that means that I need to
> know whether a Basic.Publish succeeds as well as whether it fails.
>
> At the moment there is the potential for a client application to keep firing
> messages at the server whilst being oblivious to the fact that the server is
> telling it to stop. If the client application is just writing and not
> reading, purely a publisher of messages, then there has to be an efficient
> way of notifying the client that a publish has succeeded. As far as I can
> see, the simplest way to do that is with a publish-ok.
>
> Transactions may give me what I want but I don't think that I should be
> enforcing the use of transactions in my client library just so that it will
> handle Channel.Flow methods properly.
>
> Regards,
>
> Chris
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss@lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jan 05, 2010 2:57 pm |
|
|
|
Guest
|
Have you tried calling select on your socket to see if there is any data available to be read before a publish?
Then your publish method could throw a ChannelFlowException or something like that.
If you are waiting on tx-ok, then you will have to wait the latency of your link to your rabbit server before sending your next message. |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jan 05, 2010 7:33 pm |
|
|
|
Guest
|
Hi Scott,
If I read the details of the select call correctly, wouldn't I have to provide a timeout value so that if there is nothing to read from the socket I stop blocking and can publish the next message?
Regards,
Chris
On 5 Jan 2010, at 14:48, Scott Brooks wrote:
Quote: Have you tried calling select on your socket to see if there is any data available to be read before a publish?
Then your publish method could throw a ChannelFlowException or something like that.
If you are waiting on tx-ok, then you will have to wait the latency of your link to your rabbit server before sending your next message. |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 1:05 am |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 4:41 am |
|
|
|
Guest
|
Thanks Scott. I'll try that. I was looking to do a similar thing with the Ruby socket implementation but got hung up on the timeout issue. Do you know if there are any issues with Windows and select used in this way? I don't use Windows myself, but I don't want to introduce a problem for those who do.
I've also been reading the AMQP 0-10 specification. I have only skimmed it before because I wasn't targeting a broker that implemented it. It contains a section about transfer of responsibility that seems to deal with the issues that I've been trying to address in my last two posts.
Regards,
Chris
On 6 Jan 2010, at 00:58, Scott Brooks wrote:
|
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 6:56 am |
|
|
|
Guest
|
On Wed, Jan 6, 2010 at 4:40 AM, Chris Duncan <celldee@gmail.com> wrote:
>
> I've also been reading the AMQP 0-10 specification. I have only skimmed it
> before because I wasn't targeting a broker that implemented it. It contains
> a section about transfer of responsibility that seems to deal with the
> issues that I've been trying to address in my last two posts.
Yes, that's how we designed it. But, the goal of 0-10 was to provide
a way to use acks and nacks for exactly-once delivery. Your email
only asks for an ack. That's a bit easier and IMO better.
alexis
> Regards,
> Chris
> On 6 Jan 2010, at 00:58, Scott Brooks wrote:
>
> From |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 5:08 pm |
|
|
|
Guest
|
Hi Gordon,
On 6 Jan 2010, at 16:50, Gordon Sim wrote:
> On 01/06/2010 06:55 AM, Alexis Richardson wrote:
>> On Wed, Jan 6, 2010 at 4:40 AM, Chris Duncan<celldee@gmail.com>
>> wrote:
>>>
>>> I've also been reading the AMQP 0-10 specification. I have only
>>> skimmed it
>>> before because I wasn't targeting a broker that implemented it.
>>> It contains
>>> a section about transfer of responsibility that seems to deal
>>> with the
>>> issues that I've been trying to address in my last two posts.
>>
>> Yes, that's how we designed it. But, the goal of 0-10 was to provide
>> a way to use acks and nacks for exactly-once delivery. Your email
>> only asks for an ack. That's a bit easier and IMO better.
>
> The need for some confirmation of publish is much wider than
> exactly-once delivery. That confirmation mechanism should also
> support asynchronous use if desired to avoid the performance impact
> Scott points out[*].
>
> The 0-10 protocol doesn't really provide nacks per se. It has a
> message-release command which is useful when subscribers want to
> use prefetch and need to relinquish some of the messages delivered
> to them without killing the session.
>
> [*] Perhaps of interest to mention that there was some disagreement
> within the amqp wg on whether -ok response to methods identified as
> synchronous by the 0-8 spec could be used asynchronously i.e.
> whether it was valid to send methods without waiting for the -ok
> and process receipt of those -ok response as they arrive in the
> other direction. Most (all?) of them aren't explicitly correlated,
> so were you to do that you would need to rely on the order of -oks
> matching the order of methods which if I recall correctly was the
> cause for concern at the time.
I thought that the :nowait argument in the 0-8, 0-9 and 0-9-1 specs
was what provides the ability to use synchronous methods in an
asynchronous fashion. When I use the terms synchronous and
asynchronous here I'm using them in the manner that the AMQP specs
seem to use them; namely synchronous methods send a response to tell
you whether they've succeeded and asynchronous ones don't. If :nowait
is set to true doesn't that mean that the server will not send an -ok
response?
Regards,
Chris
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 5:19 pm |
|
|
|
Guest
|
On 01/06/2010 06:55 AM, Alexis Richardson wrote:
> On Wed, Jan 6, 2010 at 4:40 AM, Chris Duncan<celldee@gmail.com> wrote:
>>
>> I've also been reading the AMQP 0-10 specification. I have only skimmed it
>> before because I wasn't targeting a broker that implemented it. It contains
>> a section about transfer of responsibility that seems to deal with the
>> issues that I've been trying to address in my last two posts.
>
> Yes, that's how we designed it. But, the goal of 0-10 was to provide
> a way to use acks and nacks for exactly-once delivery. Your email
> only asks for an ack. That's a bit easier and IMO better.
The need for some confirmation of publish is much wider than
exactly-once delivery. That confirmation mechanism should also support
asynchronous use if desired to avoid the performance impact Scott points
out[*].
The 0-10 protocol doesn't really provide nacks per se. It has a
message-release command which is useful when subscribers want to use
prefetch and need to relinquish some of the messages delivered to them
without killing the session.
[*] Perhaps of interest to mention that there was some disagreement
within the amqp wg on whether -ok response to methods identified as
synchronous by the 0-8 spec could be used asynchronously i.e. whether it
was valid to send methods without waiting for the -ok and process
receipt of those -ok response as they arrive in the other direction.
Most (all?) of them aren't explicitly correlated, so were you to do that
you would need to rely on the order of -oks matching the order of
methods which if I recall correctly was the cause for concern at the time.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 5:32 pm |
|
|
|
Guest
|
On 01/06/2010 05:07 PM, Chris Duncan wrote:
> Hi Gordon,
>
> On 6 Jan 2010, at 16:50, Gordon Sim wrote:
>
>> On 01/06/2010 06:55 AM, Alexis Richardson wrote:
>>> On Wed, Jan 6, 2010 at 4:40 AM, Chris Duncan<celldee@gmail.com>
>>> wrote:
>>>>
>>>> I've also been reading the AMQP 0-10 specification. I have only
>>>> skimmed it
>>>> before because I wasn't targeting a broker that implemented it.
>>>> It contains
>>>> a section about transfer of responsibility that seems to deal
>>>> with the
>>>> issues that I've been trying to address in my last two posts.
>>>
>>> Yes, that's how we designed it. But, the goal of 0-10 was to provide
>>> a way to use acks and nacks for exactly-once delivery. Your email
>>> only asks for an ack. That's a bit easier and IMO better.
>>
>> The need for some confirmation of publish is much wider than
>> exactly-once delivery. That confirmation mechanism should also
>> support asynchronous use if desired to avoid the performance impact
>> Scott points out[*].
>>
>> The 0-10 protocol doesn't really provide nacks per se. It has a
>> message-release command which is useful when subscribers want to
>> use prefetch and need to relinquish some of the messages delivered
>> to them without killing the session.
>>
>> [*] Perhaps of interest to mention that there was some disagreement
>> within the amqp wg on whether -ok response to methods identified as
>> synchronous by the 0-8 spec could be used asynchronously i.e.
>> whether it was valid to send methods without waiting for the -ok
>> and process receipt of those -ok response as they arrive in the
>> other direction. Most (all?) of them aren't explicitly correlated,
>> so were you to do that you would need to rely on the order of -oks
>> matching the order of methods which if I recall correctly was the
>> cause for concern at the time.
>
> I thought that the :nowait argument in the 0-8, 0-9 and 0-9-1 specs
> was what provides the ability to use synchronous methods in an
> asynchronous fashion. When I use the terms synchronous and
> asynchronous here I'm using them in the manner that the AMQP specs
> seem to use them; namely synchronous methods send a response to tell
> you whether they've succeeded and asynchronous ones don't. If :nowait
> is set to true doesn't that mean that the server will not send an -ok
> response?
Yes that is correct. My point was simply that sometimes you want to get
a response (e.g. to confirm success) but you don't want to have to wait
for that response before sending further requests (i.e. you don't want
to be forced into strictly synchronous communication, but you do want to
track success).
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 5:40 pm |
|
|
|
Guest
|
Hi Gordon,
On 6 Jan 2010, at 17:28, Gordon Sim wrote:
> On 01/06/2010 05:07 PM, Chris Duncan wrote:
>> Hi Gordon,
>>
>> On 6 Jan 2010, at 16:50, Gordon Sim wrote:
>>
>>> On 01/06/2010 06:55 AM, Alexis Richardson wrote:
>>>> On Wed, Jan 6, 2010 at 4:40 AM, Chris Duncan<celldee@gmail.com>
>>>> wrote:
>>>>>
>>>>> I've also been reading the AMQP 0-10 specification. I have only
>>>>> skimmed it
>>>>> before because I wasn't targeting a broker that implemented it.
>>>>> It contains
>>>>> a section about transfer of responsibility that seems to deal
>>>>> with the
>>>>> issues that I've been trying to address in my last two posts.
>>>>
>>>> Yes, that's how we designed it. But, the goal of 0-10 was to
>>>> provide
>>>> a way to use acks and nacks for exactly-once delivery. Your email
>>>> only asks for an ack. That's a bit easier and IMO better.
>>>
>>> The need for some confirmation of publish is much wider than
>>> exactly-once delivery. That confirmation mechanism should also
>>> support asynchronous use if desired to avoid the performance impact
>>> Scott points out[*].
>>>
>>> The 0-10 protocol doesn't really provide nacks per se. It has a
>>> message-release command which is useful when subscribers want to
>>> use prefetch and need to relinquish some of the messages delivered
>>> to them without killing the session.
>>>
>>> [*] Perhaps of interest to mention that there was some disagreement
>>> within the amqp wg on whether -ok response to methods identified as
>>> synchronous by the 0-8 spec could be used asynchronously i.e.
>>> whether it was valid to send methods without waiting for the -ok
>>> and process receipt of those -ok response as they arrive in the
>>> other direction. Most (all?) of them aren't explicitly correlated,
>>> so were you to do that you would need to rely on the order of -oks
>>> matching the order of methods which if I recall correctly was the
>>> cause for concern at the time.
>>
>> I thought that the :nowait argument in the 0-8, 0-9 and 0-9-1 specs
>> was what provides the ability to use synchronous methods in an
>> asynchronous fashion. When I use the terms synchronous and
>> asynchronous here I'm using them in the manner that the AMQP specs
>> seem to use them; namely synchronous methods send a response to tell
>> you whether they've succeeded and asynchronous ones don't. If :nowait
>> is set to true doesn't that mean that the server will not send an -ok
>> response?
>
> Yes that is correct. My point was simply that sometimes you want to
> get a response (e.g. to confirm success) but you don't want to have
> to wait for that response before sending further requests (i.e. you
> don't want to be forced into strictly synchronous communication,
> but you do want to track success).
>
I see your point sir 
Regards,
Chris
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| pennyplayersclub |
| Posted: Wed Oct 05, 2011 11:59 am |
|
|
|
Joined: 04 Oct 2011
Posts: 8
|
| It will be true that now most are interested like this........... |
|
|
| Back to top |
 
|
| xtremepicks |
| Posted: Sat Feb 11, 2012 9:25 am |
|
|
|
Joined: 10 Jan 2012
Posts: 9
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
