Re: [jgroups-dev] Connection expiration timeout in UNICAST2

Bela Ban <[email protected]> Sun, 01 Apr 2012 12:04:28 +0200
Newsgroups gmane.comp.java.javagroups.devel
Message-ID <[email protected]>
Yes, it should: every message that's forwarded will only get removed 
from the forward_table when it has been delivered (to the sender as well).

When the coordinator crashes and a new view is installed, all messages 
from the forward_table are sent to the new coordinator.


On 4/1/12 11:43 AM, Pedro Ruivo wrote:
> Hi Bela,
>
> I want to broadcast a message (with total order):
> - I forward a unicast message to the coordinator.
> - in UNICAST2, the message is added to the send table
> - in UDP, the message is sent.
>
> However, the network is so overloaded that the coordinator never
> receives the unicast message. When the connection is closed/removed, the
> message is still in the sender table and I think that this message will
> be lost.
>
> I have another question. Are you saying that the SEQUENCER will
> retransmit the messages in forward table after a while?
>
> Cheers,
> Pedro
>
> On 01-04-2012 10:34, Bela Ban wrote:
>> Hi Pedro,
>>
>> UNICAST2 closes idle connections to targets from which we haven't
>> received a message in a given time frame, or to which we haven't sent a
>> message in a given time frame.
>>
>> If there is a message to a target for which no connection exists, a new
>> connection will be established, so I don't know why this should be an
>> issue in SEQUENCER.
>>
>> I'm not sure I understand the problem you describe below; if there are
>> still messages in the forward-table of SEQUENCER, when they are sent and
>> the connection was closed, a new connection should be established.
>>
>>
>>
>> On 3/31/12 11:57 PM, Pedro Ruivo wrote:
>>> Hi Bela
>>>
>>> I was running some tests when I noticed that some nodes have been
>>> blocked waiting for the delivery of their own messages (the messages are
>>> sent in total order).
>>>
>>> I looked in the code and I've discovered that the connection to the
>>> coordinator is getting removed due to connection expiration timeout.
>>> However the send table still has "forward" messages to be delivered in
>>> the coordinator.
>>>
>>> Did not it should check if the send table has or not messages before
>>> removing it?
>>>
>>> The partial log is in below. Some of the messages are big, i.e. they can
>>> generate up to 10 fragmentation messages.
>>>
>>> Cheers,
>>> Pedro Ruivo
>>>
>>> ---
>>> 21:34:28,621 TRACE [SEQUENCER] forwarding msg [dst:<null>, src:
>>> node22-44738 (1 headers), size=53296 bytes, flags=NO_FC] (seqno 6) to
>>> coord (node20-1449)
>>> 21:34:28,621 TRACE [UNICAST2] node22-44738 -->    DATA(node20-1449: #34,
>>> conn_id=0)
>>> 21:34:28,621 TRACE [UDP] sending msg to node20-1449, src=node22-44738,
>>> headers are SEQUENCER: FORWARD (tag=[node22-44738|6]), UNICAST2: DATA,
>>> seqno=34, UDP: [channel_name=infinispan-cluster]
>>> ...
>>> 21:35:10,267 TRACE [UDP] received [dst: node22-44738, src: node20-1449
>>> (2 headers), size=0 bytes, flags=OOB], headers are UNICAST2: STABLE,
>>> seqno=32, UDP: [channel_name=infinispan-cluster]
>>> 21:35:10,267 TRACE [UNICAST2] node22-44738<-- STABLE(node20-1449:
>>> 32-32, conn_id=0)
>>> 21:35:10,268 TRACE [UDP] sending msg to node20-1449, src=node22-44738,
>>> headers are SEQUENCER: FORWARD (tag=[node22-44738|5]), UNICAST2: DATA,
>>> seqno=33, UDP: [channel_name=infinispan-cluster]
>>> 21:35:10,268 TRACE [UDP] sending msg to node20-1449, src=node22-44738,
>>> headers are SEQUENCER: FORWARD (tag=[node22-44738|6]), UNICAST2: DATA,
>>> seqno=34, UDP: [channel_name=infinispan-cluster]
>>> ...
>>> 21:36:10,268 TRACE [UDP] received [dst: node22-44738, src: node20-1449
>>> (2 headers), size=0 bytes, flags=OOB], headers are UNICAST2: STABLE,
>>> seqno=32, UDP: [channel_name=infinispan-cluster]
>>> 21:36:10,269 TRACE [UNICAST2] node22-44738<-- STABLE(node20-1449:
>>> 32-32, conn_id=0)
>>> 21:36:10,269 TRACE [UDP] sending msg to node20-1449, src=node22-44738,
>>> headers are SEQUENCER: FORWARD (tag=[node22-44738|5]), UNICAST2: DATA,
>>> seqno=33, UDP: [channel_name=infinispan-cluster]
>>> 21:36:10,269 TRACE [UDP] sending msg to node20-1449, src=node22-44738,
>>> headers are SEQUENCER: FORWARD (tag=[node22-44738|6]), UNICAST2: DATA,
>>> seqno=34, UDP: [channel_name=infinispan-cluster]
>>> 21:36:10,269 TRACE [TP$TransferQueueBundler] sending 1 msgs (54304 bytes
>>> (84.85% of max_bundle_size) to 1 destination(s)
>>> 21:36:10,270 TRACE [UDP] received [dst: node22-44738, src: node20-1449
>>> (2 headers), size=0 bytes, flags=OOB], headers are UNICAST2: STABLE,
>>> seqno=32, UDP: [channel_name=infinispan-cluster]
>>> 21:36:10,270 TRACE [UNICAST2] node22-44738<-- STABLE(node20-1449:
>>> 32-32, conn_id=0)
>>> 21:36:10,270 TRACE [UDP] sending msg to node20-1449, src=node22-44738,
>>> headers are SEQUENCER: FORWARD (tag=[node22-44738|5]), UNICAST2: DATA,
>>> seqno=33, UDP: [channel_name=infinispan-cluster]
>>> 21:36:10,270 TRACE [UDP] sending msg to node20-1449, src=node22-44738,
>>> headers are SEQUENCER: FORWARD (tag=[node22-44738|6]), UNICAST2: DATA,
>>> seqno=34, UDP: [channel_name=infinispan-cluster]
>>> ...
>>> 21:36:17,270 TRACE [UNICAST2] node22-44738 -->    STABLE(node20-1449: 2-2,
>>> conn_id=2)
>>> 21:36:17,270 TRACE [UDP] sending msg to node20-1449, src=node22-44738,
>>> headers are UNICAST2: STABLE, seqno=2, conn_id=2, UDP:
>>> [channel_name=infinispan-cluster]
>>> 21:36:17,270 DEBUG [UNICAST2] node22-44738: removed expired connection
>>> for node20-1449 (108649 ms old) from send_table
>>> 21:36:17,270 TRACE [UNICAST2] node22-44738 -->    STABLE(node20-1449: 2-2,
>>> conn_id=2)
>>> 21:36:17,270 TRACE [UDP] sending msg to node20-1449, src=node22-44738,
>>> headers are UNICAST2: STABLE, seqno=2, conn_id=2, UDP:
>>> [channel_name=infinispan-cluster]
>>> 21:36:17,270 DEBUG [UNICAST2] node22-44738: removed expired connection
>>> for node20-1449 (119581 ms old) from recv_table
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> _______________________________________________
>>> Javagroups-development mailing list
>>>
>>>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Javagroups-development mailing list
>
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Javagroups-development mailing list