[rabbitmq-discuss] Reconnect logic for C library

Tony Menges amenges at vmware.com
Tue May 3 23:09:18 BST 2011


amqp_tx_commit does perform a transaction commit on the server; thus the
performance is impacted quite a bit but you do have a better guarantee that
the messages have been handled by the server. I haven't used the publisher 
confirms yet - I'll modify my test program to have that as an option. With 
publisher confirms, one could hold messages until they are confirmed and 
retransmit on connection failure. It may be possible to write a generic 
layer on top of the API to handle this.

The problem of knowing when the connection drops will require a bit more 
digging on my part.

Tony

----- Original Message -----
From: "Paul Dix" <paul at pauldix.net>
To: "Alexis Richardson" <alexis at rabbitmq.com>
Cc: "Tony Menges" <amenges at vmware.com>, "rabbitmq-discuss" <rabbitmq-discuss at lists.rabbitmq.com>
Sent: Tuesday, May 3, 2011 2:54:08 PM
Subject: Re: [rabbitmq-discuss] Reconnect logic for C library

yeah, that looks exactly like what I was looking for. However, is the
amqp_tx_commit a transaction or just something that confirms that the
connection is still open and usable? This all started with the fact
that I couldn't even tell if a connection was up. Thus there was no
way to do error handling in the case the connection drops (for
whatever reason).

On Tue, May 3, 2011 at 5:46 PM, Alexis Richardson <alexis at rabbitmq.com> wrote:
> Publisher confirms?
>
> http://www.rabbitmq.com/blog/2011/02/10/introducing-publisher-confirms/
>
>
> On Tue, May 3, 2011 at 10:35 PM, Paul Dix <paul at pauldix.net> wrote:
>> I've moved on from it now. However, here's basically what I wanted:
>> I have a publisher publishing messages. If the rabbit server fails, I
>> want the publisher to be able to tell which messages actually got
>> published and which didn't. Basically something like an atomic
>> publish. If it returns successfully, I can be sure that the message,
>> which is marked persistent, is actually stored on the server. Or put
>> even more simply: guaranteed delivery.
>>
>> Thanks,
>> Paul
>>
>> On Tue, May 3, 2011 at 4:34 PM, Alexis Richardson <alexis at rabbitmq.com> wrote:
>>> Paul
>>>
>>> Can you tell us more about what you are trying to do please?
>>>
>>> alexis
>>>
>>>
>>> On Tue, May 3, 2011 at 3:25 AM, Tony Menges <amenges at vmware.com> wrote:
>>>> Hi Paul,
>>>>
>>>> I started to take a look at this and wanted to make sure I understand the problem. Is the basic problem that the return code from amqp_basic_publish() shows success even after the broker has closed the connection? Are you doing a commit after each message is published? Is commit showing success when the broker is down?
>>>>
>>>> I've written a simple test driver program that allows me to vary the number of messages per transaction and the amount of delay between messages and after commits. I set the number of messages per transaction to 5, the delay between publishes to 0 and the delay after each transaction to a few seconds. After I see a commit, I ctl-C Rabbit and I see usually 5 (the transaction batch size) messages published and the commit fails with a connection closed error. The Wireshark trace shows that only 1 of the messages was actually put on the wire.
>>>>
>>>> If I put a delay between message sends, I get a SIGPIPE usually after 1 or 2 messages have been sent.
>>>>
>>>> I think that in the first case, the messages are put into the socket's output buffer fast enough that the close from the other side has not been processed (my messages are quite small so they all fit in the socket's buffer); amqp_tx_commit() actually tries to read from the socket so it will notice the socket closed.
>>>>
>>>> Does this sound consistent with your experience?
>>>>
>>>> Tony Menges
>>>> VMware, Inc
>>>>
>>>> ----- Original Message -----
>>>> From: "Paul Dix" <paul at pauldix.net>
>>>> To: "Matthias Radestock" <matthias at rabbitmq.com>
>>>> Cc: "rabbitmq-discuss" <rabbitmq-discuss at lists.rabbitmq.com>
>>>> Sent: Tuesday, April 12, 2011 6:50:13 AM
>>>> Subject: Re: [rabbitmq-discuss] Reconnect logic for C library
>>>>
>>>> Hi Matthias,
>>>> I briefly tried to use these two:
>>>>
>>>> amqp_tx_commit(connection, channel);
>>>> amqp_get_rpc_reply(connection)
>>>>
>>>> Then check the result. However, I found that it would indicate success
>>>> for a message or two after I took RabbitMQ down before it indicated a
>>>> problem. I ended up bailing on C, but I'd be interested to hear if
>>>> this is possible with the library. The two things are: fail if a
>>>> message doesn't get published (i.e. don't fail silently) and check
>>>> that a connection/channel is open.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>> On Tue, Apr 12, 2011 at 7:04 AM, Matthias Radestock
>>>> <matthias at rabbitmq.com> wrote:
>>>>> Paul,
>>>>>
>>>>> On 01/04/11 22:40, Paul Dix wrote:
>>>>>>
>>>>>> I'm working with the rabbitmq c library and I need to have reconnect
>>>>>> logic in there. Basically, try to send a message, if it fails, attempt
>>>>>> reconnect and try again. How do I accomplish this? I've been using
>>>>>> amqp_basic_publish and if I try that it just hangs.
>>>>>
>>>>> Did you work out what the problem was? The people familiar with the C client
>>>>> at Rabbit HQ are a bit swamped at the moment, so it will likely be a while
>>>>> before we can look into this.
>>>>>
>>>>> Matthias.
>>>>>
>>>> _______________________________________________
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq-discuss at lists.rabbitmq.com
>>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>> _______________________________________________
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq-discuss at lists.rabbitmq.com
>>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>>
>>>
>>
>


More information about the rabbitmq-discuss mailing list