[jboss-jira] [JBoss JIRA] Commented: (JGRP-1252) TCP Gossip Discovery Issue

[Grahame Rogers (JIRA)]

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

Grahame Rogers commented on JGRP-1252:
--------------------------------------

Hi,

I went back to the more manual test code I originally posted, as there was an issue with the more automated test harness where for some reason when using the jdklogger, threads were getting blocked - I will revisit this at some point as I appreciate this would be an easier way to replicate the issue.

However, using the manual test I think I can see what the problem is, but would like to run it by you as obviously I don't fully understand the code.
I start 4 chat clients (A,B,C and D). I then shut down D, then shut down the GR, restart GR and almost immediately start a new client (E).

Now I believe my new client (E) goes and fetches a list of active clients from the GossipRouter via TCPGossip class and in my scenario, at this point A and B have re-connected but C has not (plausible timing issue). So TCPGossip then adds A and B's UUID, plus logical names to it's UUID cache (UUID.add). However, what happens next is the ClientGmsImpl class then attempts to join via the co-ordinator and the co-ordinator at this point is able to return a view which now also contains C, but my UUID cache does not contain this, so any subsequent toString() calls on this UUID results in the logical name not being returned, but instead something like 88d1f8ba-feb9-b998-2346-116e1344efcc which is generated from toStringLong when no cache entry exists.

So at his point instead of my client logging out a view containing A,B,C and E, it logs A,B,88d1f8ba-feb9-b998-2346-116e1344efcc and E instead.

Does this scenario sound correct to you?

If so, then it almost seems that the issue is with relying on the discovery phase to tie up a logical name to a UUID instance, it's almost as if UUID (or a similar object) needs to contain a getLogicalName method so this caching of relationships is not required.
Either that or perhaps there is another way for my code to derive a members logical name other than toString()?

> TCP Gossip Discovery Issue
> --------------------------
>
>                 Key: JGRP-1252
>                 URL: https://issues.jboss.org/browse/JGRP-1252
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.11
>         Environment: Windows XP and Solaris 5.10
>            Reporter: Grahame Rogers
>            Assignee: Vladimir Blagojevic
>              Labels: new_and_noteworthy
>             Fix For: 2.11.1, 2.12
>
>         Attachments: JGroupsTest.zip, JGroupsTest.zip, JGroupsTest.zip, JGRP-1252-output.txt, JGRP-1252-output2.txt
>
>
> I run the chat demo app that was shipped with an older version of Jgroups. Using tcp transport, with tcpgossip for discovery I start up 2 instances of the chat application. I then restart the gossip server and also another instance of the chat application. The 3rd instance of the chat application receives a view update (membershipListener.viewAccepted) only the logical name of one of the 2 previous instances of the chat client is incorrect. I have detailed the results in: http://old.nabble.com/TCPGossip-Discovery-Issue-td30227966.html
> I will attach the test client to this bug report.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira