Skip to main content

Is it possible to stop JXSE ?

16 replies [Last post]
arsene
Offline
Joined: 2005-01-30
Points: 0

Before using the startNetwork() of my NetworkManager, I have 10 active threads.
When I use JXSE, I have 33 active threads.
When I use the stopNetwork() of my NetworkManager, I have always 33 active threads and loggings from JXSE threads. (even after some GC)
Is it possible to stop all this garbage threads and how ?

I actually use this code to close JXSE :

if (group != null) {
final RendezVousService rendezvous = group.getRendezVousService();
rendezvous.setAutoStart(false);
rendezvous.stopRendezVous();
group.stopApp();
group.unref();
}
manager.unregisterShutdownHook();
manager.stopNetwork();

Of course, I want my program to work hours without JXTA after that and eventually to restart JXSE, later.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
hamada
Offline
Joined: 2003-06-12
Points: 0

This is a known JDK bug see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6524172
which occurs on certain platforms.

It was addressed JDK7 (10), and I encourage to vote to get it fixed in JDK6.

arsene
Offline
Joined: 2005-01-30
Points: 0

The exception happens only 3 or 4 times during the 15 mn after the stopNetwork.

The "Endpoint Detstinations GC" and "BlockingMessenger self destruct timer" are always alive few hours after the stopNetwork.

bondolo
Offline
Joined: 2003-06-11
Points: 0

> The "Endpoint Detstinations GC" and
> "BlockingMessenger self destruct timer" are always
> alive few hours after the stopNetwork.

This is not specifically a JXSE problem. Those two timers are class static and so will exist as long as the class object does. Until the JVM garbage collects the classes the Timers will not be removed. You can try forcing garbage collection via java.lang.Runtime:

            Runtime runtime = Runtime.getRuntime();
            runtime.runFinalization();
            runtime.gc();
            runtime.runFinalization();
            runtime.gc();            

Since the classes are unreferenced after JXSE stops this should cause the classes to be garbage collected and the Timers to be released. Class garbage collection is not always enabled so it's possible that this code will, unfortunately, have no effect.

HTH,

Mike

arsene
Offline
Joined: 2005-01-30
Points: 0

Now, the "EndpointRouter Timer for urn:jxta:jxta-NetGroup" is off, 45 mn after the stopNetwork.

Hope...

arsene
Offline
Joined: 2005-01-30
Points: 0

Now, I see what you meant, 0vw3.

Yes, I have this problem, too.

"Only a single instance of the World Peer Group may be instantiated at a single time."
Yes, but I don't know where is the event who says "you can now open an all new connection, the old one is fully closed" and the stopNetwork was done 1 minute ago.

(changing for another network)

arsene
Offline
Joined: 2005-01-30
Points: 0

I found this code in net.jxta.peergroup.PeerGroupFactoryTest, without any wait/notify, only sleep :

private static void waitForPeerGroupShutdown(PeerGroupID pgid, long maxWait) throws Exception {

long waitUntil = TimeUtils.toAbsoluteTimeMillis(maxWait);

while (TimeUtils.timeNow() < waitUntil) {
if (!PeerGroup.globalRegistry.registeredInstance(pgid)) {
return;
}

Thread.sleep(TimeUtils.ASECOND);
}

fail("PeerGroup did not shut down within expected time.");
}

arsene
Offline
Joined: 2005-01-30
Points: 0

Yes, if you have to wait for an event with a listener ; you can also use a Semaphore(0).

Without event to listen, for testing purposes, it's much better to use a simple JOptionPane.showMessageDialog or a System.in.read, not a Thread.sleep.

arsene
Offline
Joined: 2005-01-30
Points: 0

Yes, it is possible if you use the loadModule (real PeerGroup with real stopApp) and not the newGroup (interface to PeerGroup with fake stopApp).

arsene
Offline
Joined: 2005-01-30
Points: 0

I always have an "Endpoint Destinations GC", an "EndpointRouter TImer for urn:jxta:jxta-NetGroup" and a "BlockingMessenger self destruct timer" with some

17 juil. 2008 22:58:08 net.jxta.impl.endpoint.BlockingMessenger$1 run
GRAVE: Uncaught Throwable in selfDescructTask.
java.lang.NullPointerException
at sun.nio.ch.EPollSelectorImpl.wakeup(EPollSelectorImpl.java:170)
at net.jxta.impl.endpoint.tcp.TcpTransport.unregister(TcpTransport.java:1156)
at net.jxta.impl.endpoint.tcp.TcpMessenger.closeImpl(TcpMessenger.java:447)
at net.jxta.impl.endpoint.BlockingMessenger$BlockingMessengerState.closeOutputAction(BlockingMessenger.java:243)
at net.jxta.endpoint.MessengerState$6.doIt(MessengerState.java:120)
at net.jxta.endpoint.MessengerState.closeEvent(MessengerState.java:355)
at net.jxta.impl.endpoint.BlockingMessenger.close(BlockingMessenger.java:581)
at net.jxta.impl.endpoint.BlockingMessenger$1.run(BlockingMessenger.java:453)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

GRAVE : french for SEVERE

bondolo
Offline
Joined: 2003-06-11
Points: 0

What version of Java are you using? We have seen this NPE with older versions of JDK but it has been fixed in recent versions

arsene
Offline
Joined: 2005-01-30
Points: 0

java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

arsene
Offline
Joined: 2005-01-30
Points: 0

Thanks for your reply, adamman.

Let's go for a Thread.sleep(6 * 60 * 60 * 1000) :)

hamada
Offline
Joined: 2003-06-12
Points: 0

thread.sleep should be avoided, use object notification instead, it is already provided by NetworkManager.waitFor....

0vw3
Offline
Joined: 2007-11-18
Points: 0

uhmm.. Wouldn't it be by calling NetworkManager.registerShutdownHook() ?

So, you first call networkManager.registerShutdownHook() and then that thread will call networkManager.stopNetwork() isn't it?

But the fact is that you can never be sure about when you're completely offline in the case you'd want to start the network again in a safe way without exiting your app.

Am I wrong?

Message was edited by: 0vw3

arsene
Offline
Joined: 2005-01-30
Points: 0

I registerShutdownHook() in case of an exit during a JXTA connection ; but, I unregisterShutdownHook() before stopNetwork().

The connection is only needed once or twice a day, to update datas ; the rest of the time, the connection is off.

I think my problem is within the stopApp() of my Service/Application : I haven't any "XXXX service stopped" before "Stopping JXTA Network!".

Thanks.

adamman71
Offline
Joined: 2007-01-31
Points: 0

Hi Arsene,

I have heard that you have to be patient and give JXSE some time to terminate those threads.

Cheers,

J.