amqp_connection:open_channel link channel

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

amqp_connection:open_channel link channel

Matwey V. Kornilov

Hi,

Is it a good practice to link the channel to the process going to
consume the messages? I do want to close the channel when my consumer
crashed, and let the broker to redeliver unacked message.

{ok, Channel} = amqp_connection:open_channel(Connection),
link(Channel),

Why there is no open_channel_link counterpart, as start and start_link?
This is for case when channel goes down between open_channel and link.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: amqp_connection:open_channel link channel

Tim Watson-6
Hi,

On 16 Feb 2014, at 18:08, Matwey V. Kornilov wrote:
> Is it a good practice to link the channel to the process going to consume the messages? I do want to close the channel when my consumer crashed, and let the broker to redeliver unacked message.
>
> {ok, Channel} = amqp_connection:open_channel(Connection),
> link(Channel),
>
> Why there is no open_channel_link counterpart, as start and start_link?
>

The reason is that there is a level of indirection between the channel process(es) and the process that calls open channel, i.e., the channel process is linked to an internal supervisor process, not to the process that calls open_channel. Probably the easiest way to achieve what you want is to open the channel in your process' initialisation phase and close it during the shutdown phase. If your consumer is built on one of the OTP behaviours (such as gen_server) then you can open and close the channel in the respective init/1 and terminate/2 callbacks. HTH!

> This is for case when channel goes down between open_channel and link.

Indeed, that's a different problem to closing the channel if/when your consumer crashes. The easiest way might seem at first, to use a monitor instead of linking, guaranteeing a 'DOWN' message even if the monitor-ee was dead when the monitor was established. Personally however, I'd suggest looking at the amqp_gen_consumer behaviour instead, since that defines a terminate/2 callback which behaves as follows (from the edocs):

     %% This callback is invoked by the channel after it has shut down and
     %% just before its process exits.

Cheers,
Tim
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: amqp_connection:open_channel link channel

Matwey V. Kornilov
17.02.2014 17:02, Tim Watson пишет:

> Hi,
>
> On 16 Feb 2014, at 18:08, Matwey V. Kornilov wrote:
>> Is it a good practice to link the channel to the process going to consume the messages? I do want to close the channel when my consumer crashed, and let the broker to redeliver unacked message.
>>
>> {ok, Channel} = amqp_connection:open_channel(Connection),
>> link(Channel),
>>
>> Why there is no open_channel_link counterpart, as start and start_link?
>>
>
> The reason is that there is a level of indirection between the channel process(es) and the process that calls open channel, i.e., the channel process is linked to an internal supervisor process, not to the process that calls open_channel. Probably the easiest way to achieve what you want is to open the channel in your process' initialisation phase and close it during the shutdown phase. If your consumer is built on one of the OTP behaviours (such as gen_server) then you can open and close the channel in the respective init/1 and terminate/2 callbacks. HTH!

To use terminate, I have not to forget trap_exit and not brutal_kill in
supervisor.

>
>> This is for case when channel goes down between open_channel and link.
>
> Indeed, that's a different problem to closing the channel if/when your consumer crashes. The easiest way might seem at first, to use a monitor instead of linking, guaranteeing a 'DOWN' message even if the monitor-ee was dead when the monitor was established. Personally however, I'd suggest looking at the amqp_gen_consumer behaviour instead, since that defines a terminate/2 callback which behaves as follows (from the edocs):
>
>       %% This callback is invoked by the channel after it has shut down and
>       %% just before its process exits.

amqp_direct_consumer exits gracefully when my consumer process dies, but
it leads to whole connection and all other channels crash.

I want to close the one specific channel, when my corresponding consumer
process dies or exits. And vice versa, when channel is dead, my consumer
process have to shutdown and to be restarted (and reopen new channel) by
supervisor.


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss