[jboss-jira] [JBoss JIRA] (JGRP-1755) TP: dropping message to wrong destination in a shared transport

[Bela Ban (JIRA)]

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

Bela Ban edited comment on JGRP-1755 at 12/23/13 4:00 AM:
----------------------------------------------------------

Note that this only occurs when a *shared transport is used*.

Hmm, the {{LEAVE_RSP}} *is* actually received quickly, so the question is why the coordinator keeps resending it. Perhaps the leaver hasn't yet acked it ?
                
      was (Author: belaban):
    Hmm, the {{LEAVE_RSP}} *is* actually received quickly, so the question is why the coordinator keeps resending it. Perhaps the leaver hasn't yet acked it ?
                  
> TP: dropping message to wrong destination in a shared transport
> ---------------------------------------------------------------
>
>                 Key: JGRP-1755
>                 URL: https://issues.jboss.org/browse/JGRP-1755
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4.2, 3.5
>
>         Attachments: bla3.java, shared.xml
>
>
> TP has a check whether the dest of incoming unicast messages matches its local address (or the local address in the ProtocolAdapter if a shared transport is used). Messages whose dest != local address are dropped.
> However, in the following scenario, we can have spurious warnings for 2 minutes (by default):
> * 2 processes with 2 members on a shared transport each (see attached shared.xml and bla3.java)
> ** Start 2 bla2 instances on the same box
> * On the second instance, a member leaves and immediately rejoins (press [2] on the second member)
> * For some reason, the leaving member didn't receive the {{LEAVE_RSP}} unicast message from the coordinator (first member)
> * The newly joined member now receives the {{LEAVE_RSP}} unicast from the coordinator, but now it is a different member and therefore has a different local address, so we see the warning
> * This will continue for 2 minutes, until the connection to the unknown member is closed by the coordinator (configurable)
> TODOs:
> * Investigate why the {{LEAVE_RSP}} unicast is not received by the leaving member
> * In the warning, add the sender's address and print the headers of the message so it's easier to find the culprit

--
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