[jboss-jira] [JBoss JIRA] (JGRP-1563) UNICAST2: first-message-lost problem

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753340#comment-12753340 ] 

Bela Ban commented on JGRP-1563:
--------------------------------

Hmm, I'm not showing the stack trace here... 

This is the retransmit task, so if we throw an NPE, the task will just fire in the next interval, so nothing critical.

If you can reproduce it, perhaps you could create a temp snapshot of JGroups with DefaultTimeScheduler.RobustRunnable.run() (line 184) changed to 
log.error("exception executing task " + command,  t);

I'm rethinking whether UNICAST2 makes sense anyway, and have plans for a UNICAST3, which has the props of UNICAST but the speed of UNICAST2. More about this in LON.
                
> UNICAST2: first-message-lost problem
> ------------------------------------
>
>                 Key: JGRP-1563
>                 URL: https://issues.jboss.org/browse/JGRP-1563
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.2.6, 3.3
>
>
> If A sends its first message A#1 to B, but the network drops A#1, B won't be able to receive A#1 unless A sends another message.
> Even the stable task won't help: as B only sends stable messages to connected members (and A isn't), it will never send a stable message to A.
> SOLUTION:
> - Use acking for the first message
> - Continue sending the first message until it has been acked, or a configurable time period has elapsed
> - Note that we cannot cancel this task based on *membership* (view changes), as unicast messages can be sent to members outside of our view

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira