RE: Individual Members of PeerGroup

Mohamed,

Thanks for the quick response (and patch).  I have looked over the patch
and tried it.  The patch, unfortunately, doesn't resolve this particular
problem.  The patch you provided ensures that the node that initiates
the message will receive it.  For example, if there are 2 nodes A and B.
If A is the rdv node and B is the node trying to send a message to A
(via the method described below), this patch will send the message to B
(itself) as well as attempt to send it to A.  For some reason, A never
receives the message.  

Here is the problem, using the same example above (no patch)... Node A
is the rdv and B is an edge peer.  If B sends a message to A, A will not
receive the message.  However, if A sends a message to B, B will receive
the message.  To expand on this, if there are 5 nodes: A, B, C, D, and
E, where node A is the rdv node.  If B sends a message to A and C, C
will receive the message, but A will not.

I hope this is clear.  I am mucking around in the source code for Jxta
right now.  If I solve this problem, I will post it here.  

Thanks,

-----Original Message-----
From: Mohamed Abdelaziz [mailto:[email protected]] 
Sent: Wednesday, September 21, 2005 12:11 PM
To: [email protected]
Subject: Re: [JXTA user] Individual Members of PeerGroup


Yes that's bug.  Looking through the WirePipe the logic which deals with

such messages (destined to a specific set of nodes) on a rendezvous ends

up bypassing any local listener during hand off between the incoming, 
and the outgoing threads.

The attached patch will address the issue.  Keep in mind it may not be 
the final patch.

Mohamed



Index: WirePipe.java
===================================================================
RCS file: 
/cvs/platform/binding/java/impl/src/net/jxta/impl/pipe/WirePipe.java,v
retrieving revision 1.38
diff -u -r1.38 WirePipe.java
--- WirePipe.java       27 Jul 2005 16:31:49 -0000      1.38
+++ WirePipe.java       21 Sep 2005 16:06:36 -0000
@@ -465,10 +465,8 @@
      */
     void sendMessage(Message msg, Set peers) throws IOException {
 
-        // do local listeners if we are to be one of the destinations
-        if(peers.isEmpty() || peers.contains(myGroup.getPeerID())) {
-            callLocalListeners(msg, null, null);
-        }
+
+        callLocalListeners(msg, null, null);
 
         if(peers.isEmpty()) {
             if (myGroup.isRendezvous()) {


Poole, Paul P1 wrote:
> Mohamed,
>
> Regarding: "OutputPipe op = pipeSerivce.createOutputPipe(propPipeAdv,
> Collections.singleton(src_pid), 1);"
>
> I ran into one problem with this... If the src_pid belongs to the 
> rendezvous peer, it fails.  Is this a bug?  Do you know of any good 
> workarounds?  I am using a history list (based on an LRU cache, per 
> your
> suggestion) to obtain a list of peers.  Sometimes one of the peers
> selected is a rendezvous... When this happens, a message is sent, but
> the rdv peer never receives this message.  This is problematic for
> message recovery in a two node scenario since the only other node to
> request missed messages from is the rendezvous.
>
> Thanks for your assistance,
>
> Paul
>
> -----Original Message-----
> From: Mohamed Abdelaziz [mailto:[email protected]]
> Sent: Monday, September 12, 2005 3:55 PM
> To: [email protected]
> Subject: Re: [JXTA user] Individual Members of PeerGroup
>
>
> PipeMessage should define and include source PID, IMO is it a missing
> feature. However, in the interim. Exchange src id in the message, and
to
>
> convert a string into a peerid can be easily done through :
>
> try {
>                 pid =(PeerID) IDFactory.fromURI(new URI(pidStr)); } 
> catch (Exception ex) {}
>
>
> The problem with using the list of peers connected to a rendezvous, is
> the assumption that such peers are subscribers to the communication 
> channel, in addition, the pipe service does not expose any api's to 
> access the list of subscribers. That said, the simplest way to do this

> without extending the core services is to use a dynamic list.
>
> I would also add the dynamic list should be an LRU cache to ensure a
> fresh list (the JXME project has a class which fits this purpose see:

>
http://jxme.jxta.org/source/browse/jxme/proxyless/proto/src/net/jxta/imp
>
l/cm/LRUCache.java?rev=1.2&view=auto&content-type=text/vnd.viewcvs-marku
> p).
>
>
> Mohamed
>
>   


-- 
http://blogs.sun.com/roller/page/hamada
http://weblogs.java.net/blog/hamada


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]