On 01-04-2012 11:04, Bela Ban wrote:
> 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.
And what will happen if the coordinator never fails?
>
>
> 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
>>
>>
|