You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Ilyushonak Barys <Ba...@troika.ru> on 2011/07/25 11:54:25 UTC
static exchange route heartbeat
Greetings!
Could you please help me with the following issue.
I have static exchange route from source broker (S) to destination (D).
It works fine until network problems occurred.
If the connection between S and D is broken (firewall for example), I have internal private queue overflow on the source (S) broker.
Is it expected behavior?
How should I manage this issue?
Best Regards,
Barys Ilyushonak
_______________________________________________________
The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp
RE: static exchange route heartbeat
Posted by Ilyushonak Barys <Ba...@troika.ru>.
Gordon,
Thank you very much for the detailed answer. It is really helpful for me.
Regards,
Boris
-----Original Message-----
From: Gordon Sim [mailto:gsim@redhat.com]
Sent: Tuesday, July 26, 2011 3:43 PM
To: users@qpid.apache.org
Subject: Re: static exchange route heartbeat
On 07/25/2011 10:54 AM, Ilyushonak Barys wrote:
> Could you please help me with the following issue.
> I have static exchange route from source broker (S) to destination (D).
> It works fine until network problems occurred.
> If the connection between S and D is broken (firewall for example), I have internal private queue overflow on the source (S) broker.
> Is it expected behavior?
Not entirely... exchange routes use temporary queues and non-reliable transfer (i.e. messages are dequeued as soon as they are transferred).
That should mean that while the connection is considered open by the source broker it will continue to send messages. When the connection is considered closed it will delete the queue entirely.
However the writing out of messages is enabled by the socket being writeable. So possibly if the socket is not detected as closed, but is not writeable either, then messages could not be sent and the queue would back up eventually reaching its limits.
Heartbeats are enabled (and hardcoded at present) on federation links which I would have expected to catch this issue before too long (by closing the connection).
> How should I manage this issue?
There are two issues. The first is ensuring that 'broken' connections are detected properly. It sounds like perhaps this is not happening in your case. More detail might help identify why. Are you using firewalls to emulate connectivity failures?
The other issue is more generally handling the fact that you cannot buffer indefinitely, will eventually hit some limit and you want this to be clear and to affect the link rather than publishers to the source.
This could for example be using a ring queue for the route (or when it is available a delete policy https://issues.apache.org/jira/browse/QPID-3247). However at present you can't control the details of the queue for exchange routes. You would need to explicitly create a queue and then use a queue route from that.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
_______________________________________________________
The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: static exchange route heartbeat
Posted by Gordon Sim <gs...@redhat.com>.
On 07/25/2011 10:54 AM, Ilyushonak Barys wrote:
> Could you please help me with the following issue.
> I have static exchange route from source broker (S) to destination (D).
> It works fine until network problems occurred.
> If the connection between S and D is broken (firewall for example), I have internal private queue overflow on the source (S) broker.
> Is it expected behavior?
Not entirely... exchange routes use temporary queues and non-reliable
transfer (i.e. messages are dequeued as soon as they are transferred).
That should mean that while the connection is considered open by the
source broker it will continue to send messages. When the connection is
considered closed it will delete the queue entirely.
However the writing out of messages is enabled by the socket being
writeable. So possibly if the socket is not detected as closed, but is
not writeable either, then messages could not be sent and the queue
would back up eventually reaching its limits.
Heartbeats are enabled (and hardcoded at present) on federation links
which I would have expected to catch this issue before too long (by
closing the connection).
> How should I manage this issue?
There are two issues. The first is ensuring that 'broken' connections
are detected properly. It sounds like perhaps this is not happening in
your case. More detail might help identify why. Are you using firewalls
to emulate connectivity failures?
The other issue is more generally handling the fact that you cannot
buffer indefinitely, will eventually hit some limit and you want this to
be clear and to affect the link rather than publishers to the source.
This could for example be using a ring queue for the route (or when it
is available a delete policy
https://issues.apache.org/jira/browse/QPID-3247). However at present you
can't control the details of the queue for exchange routes. You would
need to explicitly create a queue and then use a queue route from that.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org