Dear Alan and Michael,
I have promised to let you know how we are doing with librabbitmq-c. I
have experimenting with manipulation of TCP socket, also on the OS
level. I did not reach very good results.
The issue was that silent braking of the network let open connection
on both sides, messages, if published were stored in the internal TCP
queue.
On the server side also the connection remained hanging and when
consuming, it consumed the message and did not released until it was
closed by the server.
Thus the behavior of the system was not predictable. When using
tx_transaction by publishing and by silent breaking the connection, it
remain hanging about 12 minutes and only afterwards reported rpc error
and closed the connection on the client side.
The solution was to use heartbeat with such interval, that it was
always longer then any potential processing. Our clients are neither
in consuming mode, or in publishing mode, and some short time takes
processing when the messages are generated.
We have the RabbitMQ cluster with more nodes and Virtual IP address
mapped to one node. So we use tx_transaction and message
acknowledgments to guaranty that no messages are lost.
And in case the queues ownership is taken by other node, consumer
cancelation method is handled and connection is reestablished.
All our clients are single threaded, but even though quite robust to
network issues and cluster failures.
The only weak point is, that heartbeat can not be shorter than the
processing between publishing and consuming. But this is not an issue
in our case.
The system is in integration testing and also by the customer is
considered quite reliable.
I would like to ask you one question yet. We would like to present our
results and may be also to promote RabbitMQ platform. Aso to present
librabbitmq usage and to meet people from the community.
Don't you have some suggestion? Some conference, workshop or journal.
The best in 2015 that we can manage to send an abstract yet.
Thank you very much
Jan
2014-08-15 20:27 GMT+02:00 Alan Antonuk <
alan.a...@gmail.com>:
>
>
>
> On Fri, Aug 15, 2014 at 8:09 AM, Michael Klishin <
mkli...@pivotal.io>
> wrote:
>>
>> On 15 August 2014 at 18:26:10, Ján Kianička (
jan.ki...@gmail.com)
>> wrote:
>>
>> > I am thinking about setting socket keep alive per connection,
>> > but amqp_socket is somehow different that standard socket in
>> > C and did not work with getsockopt() and setsockopt().
>
>
> amqp_socket abstracts away the differences between a raw TCP socket, and one
> that has SSL layered on top of it. If you want to manipulate the underlying
> socket use amqp_get_sockfd() to get the socket, then use socket functions as
> you might. See:
>
https://github.com/alanxz/rabbitmq-c/blob/master/librabbitmq/amqp.h#L992
>
> Note that incorrect use of socket functions such as setsockopt() on sockets
> that rabbitmq-c owns can have adverse affects. So test what you do
> carefully.
>
>>
>> > Also I am thinking about amqp keep alive implementation, but
>> > I did not find some examples in C using librabbitmq-c. Don't you
>> > have someone experience?
>>
>> Implementing heartbeats correctly and reliably assumes the library
>> can use a separate thread (or similar). In case of the C client, there
>> is no consensus about how that should be done, from what I see.
>
>
> rabbitmq-c has partial support for AMQP heartbeats. By partial I mean, the
> heartbeats are only serviced while blocking on amqp_basic_publish() or
> amqp_simple_wait_frame() (or anything that depends on that - such as
> amqp_consume_message()). This tends to cover the use-case where the program
> does a wait for messages to be delivered from a consumer. Enabling these in
> rabbitmq-c involves passing a value greater than 0 for the heartbeat
> parameter of amqp_login().
>
> As mentioned by Michael: to get complete support for heartbeats in a client,
> there needs to be some kind of currency to handle sending and receiving
> heartbeats (such as a background thread, or an event-loop), which doesn't
> exist currently in rabbitmq-c (though I have been making some slow progress
> on how this might be done).
>
> HTH
> -Alan
>