| Author |
Message |
< RabbitMQ mailing list ~ AMQP message publishing - I wish it was synchronous |
| Guest |
 Posted: Mon Jan 04, 2010 9:27 pm |
 |
|
|
Guest
|
Before I begin let me state for the record that I have read the 0-8
and 0-9 AMQP specs and realise that they will not change just because
I believe that it might be a good idea. Neither do I advocate
deviation from the specs for the sake of expedience.
OK, I've been looking at including Channel.Flow method processing in
the Bunny client (again) and have come to the conclusion that
publishing should be synchronous in AMQP terms. My reasoning is as
follows -
The AMQP Channel.Flow method is a device to try to prevent servers
getting swamped by message producing clients. The server sends a
Channel.Flow method with :active argument set to false to a producer
in order to get the producer to stop sending messages when server
memory is getting critically low.
When a client application publishes a message it passes that message
into the care of the server. If something goes wrong the client
application needs to be notified, but it is equally important for the
client to know that the server has the message and will do its level
best to deliver it to an appropriate destination queue. It seems to
me that the second piece of information, namely a "yes I have your
message", is missing. This absence of information means that the
client has to make a judgement on the success of the publish
operation based on what it does not receive, rather than what is does
receive.
If, after issuing a Basic.Publish method, a client does not receive
an error indication or Channel.Flow method, it has to assume that a
publish has succeeded. For a simple single-threaded synchronous
client like Bunny, the lack of a publish-ok method means that it has
to wait to see whether a message arrives that indicates a problem. So
in the case of Basic.Publish, the client could do a blocking read
that times out if no message is received. However, even if I could
rely on the timeout to work without fail (which my current testing is
suggesting may not be the case), I don't like that solution at all.
With a publish-ok method things become much more straightforward. If
the client receives a publish-ok then everything is rosy in the
garden. If not, the client handles the issue. There could be
a :nowait flag as there are for other methods for asynchronous
processing.
If anyone has any ideas as to how I can get around this issue using
Ruby without additional threads, fibers, eventmachine etc. I would be
very pleased to hear from them.
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: Mon Jan 04, 2010 10:12 pm |
|
|
|
Guest
|
It would be nice to have a lazy ack and things like that will be in
future versions of amqp.
For now, have you looked at the TX class?
alexis
On Mon, Jan 4, 2010 at 9:26 PM, Chris Duncan <celldee@gmail.com> wrote:
> Before I begin let me state for the record that I have read the 0-8
> and 0-9 AMQP specs and realise that they will not change just because
> I believe that it might be a good idea. Neither do I advocate
> deviation from the specs for the sake of expedience.
>
> OK, I've been looking at including Channel.Flow method processing in
> the Bunny client (again) and have come to the conclusion that
> publishing should be synchronous in AMQP terms. My reasoning is as
> follows -
>
> The AMQP Channel.Flow method is a device to try to prevent servers
> getting swamped by message producing clients. The server sends a
> Channel.Flow method with :active argument set to false to a producer
> in order to get the producer to stop sending messages when server
> memory is getting critically low.
>
> When a client application publishes a message it passes that message
> into the care of the server. If something goes wrong the client
> application needs to be notified, but it is equally important for the
> client to know that the server has the message and will do its level
> best to deliver it to an appropriate destination queue. It seems to
> me that the second piece of information, namely a "yes I have your
> message", is missing. This absence of information means that the
> client has to make a judgement on the success of the publish
> operation based on what it does not receive, rather than what is does
> receive.
>
> If, after issuing a Basic.Publish method, a client does not receive
> an error indication or Channel.Flow method, it has to assume that a
> publish has succeeded. For a simple single-threaded synchronous
> client like Bunny, the lack of a publish-ok method means that it has
> to wait to see whether a message arrives that indicates a problem. So
> in the case of Basic.Publish, the client could do a blocking read
> that times out if no message is received. However, even if I could
> rely on the timeout to work without fail (which my current testing is
> suggesting may not be the case), I don't like that solution at all.
>
> With a publish-ok method things become much more straightforward. If
> the client receives a publish-ok then everything is rosy in the
> garden. If not, the client handles the issue. There could be
> a :nowait flag as there are for other methods for asynchronous
> processing.
>
> If anyone has any ideas as to how I can get around this issue using
> Ruby without additional threads, fibers, eventmachine etc. I would be
> very pleased to hear from them.
>
> 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: Mon Jan 04, 2010 10:58 pm |
|
|
|
Guest
|
Hi Alexis,
I have looked at it, but I obviously didn't understood it correctly.
So, let's see if I grok this. Suppose I send a tx.select, send my
basic.publish and then send a tx.commit. If I receive a tx.commit-ok
all is well, otherwise I'll receive a channel exception from the server.
Not as straightforward as a publish-ok, but hey, if it works ... 
Thanks,
Chris
On 4 Jan 2010, at 22:11, Alexis Richardson wrote:
> It would be nice to have a lazy ack and things like that will be in
> future versions of amqp.
>
> For now, have you looked at the TX class?
>
> alexis
>
>
> On Mon, Jan 4, 2010 at 9:26 PM, Chris Duncan <celldee@gmail.com>
> wrote:
>> Before I begin let me state for the record that I have read the 0-8
>> and 0-9 AMQP specs and realise that they will not change just because
>> I believe that it might be a good idea. Neither do I advocate
>> deviation from the specs for the sake of expedience.
>>
>> OK, I've been looking at including Channel.Flow method processing in
>> the Bunny client (again) and have come to the conclusion that
>> publishing should be synchronous in AMQP terms. My reasoning is as
>> follows -
>>
>> The AMQP Channel.Flow method is a device to try to prevent servers
>> getting swamped by message producing clients. The server sends a
>> Channel.Flow method with :active argument set to false to a producer
>> in order to get the producer to stop sending messages when server
>> memory is getting critically low.
>>
>> When a client application publishes a message it passes that message
>> into the care of the server. If something goes wrong the client
>> application needs to be notified, but it is equally important for the
>> client to know that the server has the message and will do its level
>> best to deliver it to an appropriate destination queue. It seems to
>> me that the second piece of information, namely a "yes I have your
>> message", is missing. This absence of information means that the
>> client has to make a judgement on the success of the publish
>> operation based on what it does not receive, rather than what is does
>> receive.
>>
>> If, after issuing a Basic.Publish method, a client does not receive
>> an error indication or Channel.Flow method, it has to assume that a
>> publish has succeeded. For a simple single-threaded synchronous
>> client like Bunny, the lack of a publish-ok method means that it has
>> to wait to see whether a message arrives that indicates a problem. So
>> in the case of Basic.Publish, the client could do a blocking read
>> that times out if no message is received. However, even if I could
>> rely on the timeout to work without fail (which my current testing is
>> suggesting may not be the case), I don't like that solution at all.
>>
>> With a publish-ok method things become much more straightforward. If
>> the client receives a publish-ok then everything is rosy in the
>> garden. If not, the client handles the issue. There could be
>> a :nowait flag as there are for other methods for asynchronous
>> processing.
>>
>> If anyone has any ideas as to how I can get around this issue using
>> Ruby without additional threads, fibers, eventmachine etc. I would be
>> very pleased to hear from them.
>>
>> 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: Mon Jan 04, 2010 11:04 pm |
|
|
|
Guest
|
Roughly.
Using TX allows you to get a synchronous ack. But it's comparitively
slow obviously. You can do acks asyncly but that has a weaker SLA of
course.
I am being vague in the hope that a better-informed person will make a
more precise and possibly helpful statement about how to make the most
of this 
Meanwhile I suggest you experiment based on what you glean from the
spec and searching the rabbitmq.com site...
alexis
On Mon, Jan 4, 2010 at 10:57 PM, Chris Duncan <celldee@gmail.com> wrote:
> Hi Alexis,
>
> I have looked at it, but I obviously didn't understood it correctly. So,
> let's see if I grok this. Suppose I send a tx.select, send my basic.publish
> and then send a tx.commit. If I receive a tx.commit-ok all is well,
> otherwise I'll receive a channel exception from the server.
>
> Not as straightforward as a publish-ok, but hey, if it works ...
>
> Thanks,
>
> Chris
>
> On 4 Jan 2010, at 22:11, Alexis Richardson wrote:
>
>> It would be nice to have a lazy ack and things like that will be in
>> future versions of amqp.
>>
>> For now, have you looked at the TX class?
>>
>> alexis
>>
>>
>> On Mon, Jan 4, 2010 at 9:26 PM, Chris Duncan <celldee@gmail.com> wrote:
>>>
>>> Before I begin let me state for the record that I have read the 0-8
>>> and 0-9 AMQP specs and realise that they will not change just because
>>> I believe that it might be a good idea. Neither do I advocate
>>> deviation from the specs for the sake of expedience.
>>>
>>> OK, I've been looking at including Channel.Flow method processing in
>>> the Bunny client (again) and have come to the conclusion that
>>> publishing should be synchronous in AMQP terms. My reasoning is as
>>> follows -
>>>
>>> The AMQP Channel.Flow method is a device to try to prevent servers
>>> getting swamped by message producing clients. The server sends a
>>> Channel.Flow method with :active argument set to false to a producer
>>> in order to get the producer to stop sending messages when server
>>> memory is getting critically low.
>>>
>>> When a client application publishes a message it passes that message
>>> into the care of the server. If something goes wrong the client
>>> application needs to be notified, but it is equally important for the
>>> client to know that the server has the message and will do its level
>>> best to deliver it to an appropriate destination queue. It seems to
>>> me that the second piece of information, namely a "yes I have your
>>> message", is missing. This absence of information means that the
>>> client has to make a judgement on the success of the publish
>>> operation based on what it does not receive, rather than what is does
>>> receive.
>>>
>>> If, after issuing a Basic.Publish method, a client does not receive
>>> an error indication or Channel.Flow method, it has to assume that a
>>> publish has succeeded. For a simple single-threaded synchronous
>>> client like Bunny, the lack of a publish-ok method means that it has
>>> to wait to see whether a message arrives that indicates a problem. So
>>> in the case of Basic.Publish, the client could do a blocking read
>>> that times out if no message is received. However, even if I could
>>> rely on the timeout to work without fail (which my current testing is
>>> suggesting may not be the case), I don't like that solution at all.
>>>
>>> With a publish-ok method things become much more straightforward. If
>>> the client receives a publish-ok then everything is rosy in the
>>> garden. If not, the client handles the issue. There could be
>>> a :nowait flag as there are for other methods for asynchronous
>>> processing.
>>>
>>> If anyone has any ideas as to how I can get around this issue using
>>> Ruby without additional threads, fibers, eventmachine etc. I would be
>>> very pleased to hear from them.
>>>
>>> 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: Mon Jan 04, 2010 11:13 pm |
|
|
|
Guest
|
OK. I'll keep playing. Thanks for your input.
Regards,
Chris
On 4 Jan 2010, at 23:03, Alexis Richardson wrote:
> Roughly.
>
> Using TX allows you to get a synchronous ack. But it's comparitively
> slow obviously. You can do acks asyncly but that has a weaker SLA of
> course.
>
> I am being vague in the hope that a better-informed person will make a
> more precise and possibly helpful statement about how to make the most
> of this
>
> Meanwhile I suggest you experiment based on what you glean from the
> spec and searching the rabbitmq.com site...
>
> alexis
>
>
>
>
> On Mon, Jan 4, 2010 at 10:57 PM, Chris Duncan <celldee@gmail.com>
> wrote:
>> Hi Alexis,
>>
>> I have looked at it, but I obviously didn't understood it
>> correctly. So,
>> let's see if I grok this. Suppose I send a tx.select, send my
>> basic.publish
>> and then send a tx.commit. If I receive a tx.commit-ok all is well,
>> otherwise I'll receive a channel exception from the server.
>>
>> Not as straightforward as a publish-ok, but hey, if it works ...
>>
>> Thanks,
>>
>> Chris
>>
>> On 4 Jan 2010, at 22:11, Alexis Richardson wrote:
>>
>>> It would be nice to have a lazy ack and things like that will be in
>>> future versions of amqp.
>>>
>>> For now, have you looked at the TX class?
>>>
>>> alexis
>>>
>>>
>>> On Mon, Jan 4, 2010 at 9:26 PM, Chris Duncan <celldee@gmail.com>
>>> wrote:
>>>>
>>>> Before I begin let me state for the record that I have read the 0-8
>>>> and 0-9 AMQP specs and realise that they will not change just
>>>> because
>>>> I believe that it might be a good idea. Neither do I advocate
>>>> deviation from the specs for the sake of expedience.
>>>>
>>>> OK, I've been looking at including Channel.Flow method
>>>> processing in
>>>> the Bunny client (again) and have come to the conclusion that
>>>> publishing should be synchronous in AMQP terms. My reasoning is as
>>>> follows -
>>>>
>>>> The AMQP Channel.Flow method is a device to try to prevent servers
>>>> getting swamped by message producing clients. The server sends a
>>>> Channel.Flow method with :active argument set to false to a
>>>> producer
>>>> in order to get the producer to stop sending messages when server
>>>> memory is getting critically low.
>>>>
>>>> When a client application publishes a message it passes that
>>>> message
>>>> into the care of the server. If something goes wrong the client
>>>> application needs to be notified, but it is equally important
>>>> for the
>>>> client to know that the server has the message and will do its
>>>> level
>>>> best to deliver it to an appropriate destination queue. It seems to
>>>> me that the second piece of information, namely a "yes I have your
>>>> message", is missing. This absence of information means that the
>>>> client has to make a judgement on the success of the publish
>>>> operation based on what it does not receive, rather than what is
>>>> does
>>>> receive.
>>>>
>>>> If, after issuing a Basic.Publish method, a client does not receive
>>>> an error indication or Channel.Flow method, it has to assume that a
>>>> publish has succeeded. For a simple single-threaded synchronous
>>>> client like Bunny, the lack of a publish-ok method means that it
>>>> has
>>>> to wait to see whether a message arrives that indicates a
>>>> problem. So
>>>> in the case of Basic.Publish, the client could do a blocking read
>>>> that times out if no message is received. However, even if I could
>>>> rely on the timeout to work without fail (which my current
>>>> testing is
>>>> suggesting may not be the case), I don't like that solution at all.
>>>>
>>>> With a publish-ok method things become much more
>>>> straightforward. If
>>>> the client receives a publish-ok then everything is rosy in the
>>>> garden. If not, the client handles the issue. There could be
>>>> a :nowait flag as there are for other methods for asynchronous
>>>> processing.
>>>>
>>>> If anyone has any ideas as to how I can get around this issue using
>>>> Ruby without additional threads, fibers, eventmachine etc. I
>>>> would be
>>>> very pleased to hear from them.
>>>>
>>>> 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 |
|
| pennyplayersclub |
| Posted: Wed Oct 05, 2011 11:56 am |
|
|
|
Joined: 04 Oct 2011
Posts: 8
|
| Most are prefer like this................ |
|
|
| 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
