Skip to main content

How to Get rid of old advertisments

7 replies [Last post]
Joined: 2007-06-25


I am new to JXTA technology and still learning how it works, what i can not understand the is how to discard the old advertisement.

What I am doing:
I am using a JXTA peer service from tutorial with some modification. The server publish a pipe service in module and client discover this service to connect with server.

When I close server and client and re-run them client appears to find the old service and try to resolve the pipe with old ID. (every time server run it generates a new pipeID). I want to discard the old pipeID and want to discover the newly publish id. I am using flush to remove old id but still finds the same old id on next event. I don't know i am doing it right or not. The code is posted here as well to flush the advertisement.

public void discoveryEvent(DiscoveryEvent ev) {

DiscoveryResponseMsg res = ev.getResponse();
System.out.println(" [ Got a Discovery Response from" + ev.getSource() + " ]");
Enumeration en = res.getAdvertisements();
ModuleSpecAdvertisement madv = null;
if (en != null)
while (en.hasMoreElements())
madv = (ModuleSpecAdvertisement) en.nextElement();
PipeAdvertisement pipeAdv = madv.getPipeAdvertisement();
for (int i = 0; i < 3; i++)
myPipe = pipes.createOutputPipe(pipeAdv, 10000);

String data = "Hello My Friend! I am connected with you";
msg = new Message();
StringMessageElement msgElement = new StringMessageElement( "DataTag", data, null);

msg.addMessageElement(null, msgElement);



} catch (Exception e)
System.err.println("flushing the advertisment...");
catch (Exception ex)
System.err.println("Error while flushing the advertisment...");



Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-02-28

Hi there,

check that the pipe advertisement is not being remotely published. If it is, the client will keep finding it until it expires. This could be your problem.



Joined: 2007-06-25


What you are saying that make sense. but unfortunately it is not being done. I can give you scenario.

1- Run Server
2- Run Client.
Communication successful.

3 - Stop client.
4 - Stop server

5 - Run server
6 -Run Client.
At step five Server generate Pipe with a new id but Client find the old advertisement. of step 2.

Now Stop the both peers
run them again and server generates another id as id are generated with this code

PipeAdvertisement advertisement = (PipeAdvertisement)AdvertisementFactory.newAdvertisement (PipeAdvertisement.getAdvertisementType());


advertisement.setName("example Pipe");
return advertisement;

Even then client find ID of step 2. That really strange, I was wondering if you or someone else can help me. I can paste the code of client and server if you want.


Joined: 2005-07-26

Hi Kabir,

The peer hosting the server code, creates each time a new pipe service (new PipeID).
Server doesn’t publish the PipeAdvertisement remotely (into rendezvous peers)!

It seems that Pipe Advertisement is embedded into the ModuleAdvertiesement (perhaps to reduce the network traffic).

peer clients discover the service through discovery service, provided by the JXTA platform (== default NetPeerGroup).

The result of discovery is put in the memory (I think def. for 2 hours) and persistently into file system, accessible to the client code (here, on local hard-disc) for365 days, I think.

I think deleting the .jxta subdirectory, created by the app, when it’s running for the first time can quickly help to locate and understand the source and reason of this unwanted behavior.

By use of DiscoveryService.flushAdvertisement(Advertisement adv)
You remove only the ModuleAdvertisement from local cache, not the PipeAdvertisment, which includes the PipeID, representing the pipe service
in yourApp.

[b]Question:[/b] Which version of platform are you using?

[b]Note:[/b] There are also other approaches to make resources available to peers in an jxta network, depending on application requirements and environments.
For example: you can distribute certain adverts in from of XML-files to peers, when the app are deployed to their hosts.

[b]By the way…[/b]
It’s will be useful, to keep the “life time” of discovered network resources (represented by adverts) configurable (at least for the persistent cache) in next releases of the platform. For developers and end-users These are important system configuration parameters.


Joined: 2007-06-25

Hello Asghar,

What you said is great and helps to understand the working of platform. But I am afraid I still have problem with it.

The platform I am using is 4.2.1.

While you are right I am using module advertisement and then adding my pipe Advert into it. I thought removing module advertisement will remove all the advertisement associated with it. I may be wrong in this assumption, but even if I flush only pipe Advert and also even I flush both the module and pipe advert it still finds that.

My presumption here, based on our program logic, e.g. if we identify that an advertisement is not being used by other peer or the peer of that advertisement is not available or we are unable to resolve pipe or any thing else. We can use flush method to get rid of that advertisement. I am right? (If no please correct me)

I am thinking the scenario where one peer republishes the same advertisement of same name but with different ID (due to some reason), how client will know about the new advertisement as he is still able to find old and not able to resolve new pipe.

By the way I am not using rendezvous peer yet as I am working on same machine but in different folders that might help to identify the problem.

Waiting for comments from group


Joined: 2005-07-26

Hello again,

Sorry in my previous record I had a mistake:

A created or discovered advertisement is always added to the local cache. The default values for advertisement expiration:
local lifetime of 365 days, and
remote lifetime of 2 hours. That is the time, the advertisement is kept in the cache of peers ( and not in the local memory ) that have searched and retrieved the advertisement). However I don’t know if it apply to a rendezvous peer too, which mainly caches adverts to serve the discovery requests, originating from the same peer group, it belongs to. This can become important, because any jxta network has at least one rendezvous peer!

We can use flush method to get [b]rid[/b] of that advertisement. I am right? ……

As far as mentioned in the JXTA API´s Javadoc, flushAdvertisment() is used (for the reasons you mentioned) , to remove adverts form local cache only AND not from remote locations (That’s reasonable!)
When this method is used carefully, it certainly increases the application performance (reduce the propagation of false information in the net). Important for JXME based apps.
In your case, I hope the method does, what it promises.

• Do you call this method (of course for both adverts, to be at sure side) in the server application too?

• What happen, if you delete the .jxta sub-dir ONLY at the server side, before rerunning the app?

• What is rid ?
[b]Note:[/b] I learned a new English word today: “rid of“.
First I thought: it must be something related to JXTA, like Remote ID, really! But before sending this message, I looked up in my dictionary….


Joined: 2007-06-25

Hello Asghar,

Thanks very much, you guys have been great help not only sorting out this problem but you provide me some extra valueable information as well.

[b]Do you call this method (of course for both adverts, to be at sure side) in the server application too?[/b]

No I call this method only from client side, at server side i dont know how a peer will know which advertisement is not used by him. The logic I used in client is try resolve a pipe if not resolved flush it and get next element from enumeration.

[b]What happen, if you delete the .jxta sub-dir ONLY at the server side, before rerunning the app[/b]

It works fine.

Thank ever so much for all the support i get from here

Joined: 2005-07-26

.. dear kabir, thank you too.

Learning, education binges changes, drives on.

Java demonstrates the power of fairness, diversity, teamwork and friendships.

JXTA is not a dead cat. It’s a tiger, thanks to it’s wonderful community and hard work done.

Java is changing my life.

Being ALSO thankful is beautiful!