Re: [jgroups-dev] TreeMesh progress and questions

Mike Jensen wrote:
> I am casting almost all addresses now to UUID's for safety (exceptions
> include things like FIND_INITIAL_MBRS). And things seem to be working
> much better now.

I hope this is guarded by an instanceof check; should we ever decide to 
replace UUIDs with something else, your code will break.

> But I have a weird situation in connecting I am not sure how to solve. 
> Basically the situation is like this:
>
> 1) We get an up event of MeshHandshakeHeader from a node wishing to 
> establish a connection to us
> 2) We read the information they provided, all is good, and we decide to
> accept the connection. So we then try to reply with our own information
> for the connecting node.
> 3) In pseudo code it looks like this:
>
> if (hdr instanceof MeshHandshakeHeader) {
> newConnectionAttempt((String)msg.getObject(), (UUID)msg.getSrc(), 
> <boolean::IsResponse>);
> }



> newConnectionAttempt(String data, UUID source, boolean isResponse) {
> // parse data
> // check if we want to keep this connection
> if (keepConnection && !isResponse) {
> // send response
> Message msg = new Message(source, local_addr,
> createHandshakeData(conType));
> msg.putHeaderIfAbsent(getID(), new MeshHandshakeHeader(true));
> down_prot.down(new Event(Event.MSG, msg));
> }
> }
>
> The issue is that even though I am using the UUID that was the source of
> the incoming connection request, when I try to send using this UUID as
> the destination I get the following:
>
> WARNING: <local hostname>: no physical address for <UUID of remote 
> node>, dropping message

Aha, I think I know what the issue is !

As part of the discovery process, a joining node sends its physical 
address and logical name (if set) along with the discovery request. The 
discovery response(s) also contain physical address information about 
their senders.

However, if A gets a connection request from B, A might not have any 
idea of the physical address of B, because B was not involved in the 
discovery address.

There are 2 ways of correcting this issue:

#1 When B sends its connection request to A, it also includes physical 
address information. When A receives the request, it'll add B's 
information to its local cache. Take a look at how this is done in 
Discovery.

#2 (In addition or instead of #1) When A wants to send a request to B, 
but doesn't have B's information (e.g. physical address), it sends a 
GET_PHYSICAL_ADDRESS event up the stack. The default is to run the 
discovery process again (this event is caught and processed by 
Discovery). But you could have a protocol, which catches this event and 
fetches the physical address, too.


I definitely think #1 should fix the issue, and I would actually not 
implement #2 here, as it might prove problematic to fetch the physical 
address, as your mesh doesn't have a 'broadcast' mode. Or maybe you 
could ask the parents of the connecting node for physical node information ?

> Why would it be unable to look up the UUID of the source of a message we
> just received? What ends up happening is that the connection attempt
> ends up timing out, since the response was never received. After the
> connection times out, the node will try to establish another
> connection.

To the same node it tried to connect before ?

> Then on the second try it ALWAYS works, it works if it is
> connecting to the same node, or a different node. Why would it always
> work on the second try but not the first when the code paths are the same?

It should fail the 2nd time, too, unless the discovery mechanism for 
some reason suddenly has B's physical address. You can dump A's physical 
address cache to see if this is true.

> As for having another demo/phone call. That sounds good, I am always
> willing to talk and explain where I am. I just am trying to be
> sensitive to your time. Now that I am making progress again, I don't
> feel that there is an urgent need for this. But maybe we will want to
> do this later this week (like maybe Thursday morning for me).

OK. Just ping me on #jgroups. Note that I'll be here next week, then I'm 
gone for 2 weeks.

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Javagroups-development mailing list