Skip to main content

Why don't Peer Advertisements expire by default?

7 replies [Last post]
ariel_ro
Offline
Joined: 2009-12-28

Hello,

If I find another peer using getRemoteAdvertisement() method call the peer advertisement found remains in the local cache for 2 days, even though the expiration time is a few seconds.

Since peers(mostly edges in a network) are not such a persistent presence, wouldn't it be more elegant for peer advertisements to expire by default?

Meanwhile, the (obvious)workaround that I found is to flush them manually.
Is there a way to ease this task?

P.S: It's in a way nice that peer advs don't need to be published over and over again in a thread(because of their special regime they are persistent). But still, a thread is needed to clean them so it's back again with threading.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ariel_ro
Offline
Joined: 2009-12-28

Peer advs should expire. The fact that they don't is a bug in 2.5 which is corrected(according to adamman) in 2.6.

adamman71
Offline
Joined: 2007-01-31

I have not had the time to look at this in details, but I am wondering whether your issue is caused by that fact that the Peer advertisement is RE-published. In that case, the application is working as designed...

Yet, there is an opened issue for peergroup advertisement: https://jxta-jxse.dev.java.net/issues/show_bug.cgi?id=28

ariel_ro
Offline
Joined: 2009-12-28

First of all, I'm using JXTA 2.5.

Have a look at this thread:
http://forums.java.net/jive/message.jspa?messageID=203376

The only thing I can ellaborate based on my issue is that peer advertisement don't need to be republished unless they're flushed. Other than that they remain for some time in the cache.

The way discovery works in my application is by publishing the peer advertisements and then flushing them at the time they're found to simulate expiration.

My problem with regards to peer discovery is solved(for the moment). If you happen to know any good practices about that I'll be happy to hear them. Again I'm using 2.5 version and don't think I'll have time to migrate to 2.6 in the next 3 months.

adamman71
Offline
Joined: 2007-01-31

I read 203376. There is a general confusion on lifetime, expiration, the role of SRDI and the need to remote publish advertisements. The latest programmer's guide (2.6 beta 2) provides information about what is happening under the hood. I think people should read that first to understand how they should implement their applications.

More over, some bugs related to publication of advertisement, SRDI replication and connectivity between peers have been found and solved in 2.6 beta 2. Unfortunately, 2.5 has been released without being properly tested. 2.5 does not always do what it claims it does, and its behavior is not always well documented. Some of the issues reported in 203376 are typical of what has been solved in 2.6.

Beyond that, I insist that using the discovery protocol to find out whether a peer is connected or not, is not a good idea. If a peer goes off, advertisements do not go off at the same time. The isReachable() method is the better way.

ariel_ro
Offline
Joined: 2009-12-28

Thank you for your answer, the JXTA community must be revived.

Back to my problem, the idea is that peer advertisements seem to be a different breed of advs. When I broadcast a pipe advertisement (for instance) it expires exactly after the time I tell it to. Peer advertisements do not. I know because I checked it.

Anyways I got around this problem, it's not a issue for me anymore. Now I'm trying to see how I can see when a peer signed out of the network.

I know that you do this inside a discoveryEvent(DiscoveryEvent ev) but I'm having some problems.

It would be nice to catch the TcpListener closeImpl() (the one that appears in the console each time a peer signes out).

I'm using JXTA only inside the same subnet for the moment so a lot of things should be simplified.

adamman71
Offline
Joined: 2007-01-31

There is no separate mechanism for peer advertisement expiration, but then again, if you think there is a bug, can you explain how to replicate it?

The discovery process is not a good idea to find out whether a peer has signed out. Advertisements may be 'alive' while the peer is not. Use the new isReachable() method from the EndpointService. See the 2.6 programmer's guide.

Catching the TcpListener closeImpl would not work when routes take multiple hops (it is not the target peer who would disconnect), unless you would only work in LAN, but that case is too restrictive...

J.

adamman71
Offline
Joined: 2007-01-31

There is a garbage collection of advertisements in (local) cache managers. On top of my head, it runs every minute or so. If the advertisement is stored locally with high expiration and lifetime, then application is working as expected.

Otherwise, I am do not understand your issue. Can you clarify?

J.