Does anyone have a work-a-round for the following block?
JmDNS.Shutdown" prio=5 tid=0x0838d600 nid=0x8379c00 in Object.wait() [0xbed0e000..0xbed0ea80]
at java.lang.Object.wait(Native Method)
- waiting on <0x309803b0> (a java.lang.Object)
at java.lang.Object.wait(Object.java:474)
at javax.jmdns.JmDNS.unregisterAllServices(JmDNS.java:682)
- locked <0x309803b0> (a java.lang.Object)
at javax.jmdns.JmDNS.close(JmDNS.java:2313)
- locked <0x30456058> (a ish.util.Zeroconf)
at javax.jmdns.JmDNS$Shutdown.run(JmDNS.java:2251)
at java.lang.Thread.run(Thread.java:595)
Any work-a-round, or fix, would be much appreciated. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Timer-2" prio=5 tid=0x082fc000 nid=0x82fc200 waiting for monitor entry [0xbee53000..0xbee53b00]
at javax.jmdns.JmDNS$Renewer.run(JmDNS.java:1620)
- waiting to lock <0x30456058> (a ish.util.Zeroconf)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, set up a config file to the same effect. The lock-up is random (i.e., doesn't always occur) and in my subsequent quick tests today I've not been able to get it to lock up just yet... but here's the logging so far. Note: I get no logging output during the shutdown.
-- As the application is starting up --
26/09/2007 11:28:55 javax.jmdns.JmDNS <init>
FINER: JmDNS instance created
26/09/2007 11:28:57 javax.jmdns.JmDNS$Prober run
FINE: run() JmDNS probing oncourse._oncourse._tcp.local. state probing 2
26/09/2007 11:28:57 javax.jmdns.JmDNS$Prober run
FINER: run() JmDNS probing #probing 1
26/09/2007 11:28:58 javax.jmdns.JmDNS$Prober run
FINE: run() JmDNS probing oncourse._oncourse._tcp.local. state probing 3
26/09/2007 11:28:58 javax.jmdns.JmDNS$Prober run
FINER: run() JmDNS probing #probing 2
26/09/2007 11:28:59 javax.jmdns.JmDNS$Prober run
FINE: run() JmDNS probing oncourse._oncourse._tcp.local. state announcing 1
26/09/2007 11:28:59 javax.jmdns.JmDNS$Prober run
FINER: run() JmDNS probing #probing 3
26/09/2007 11:29:00 javax.jmdns.JmDNS$Announcer run
FINER: run() JmDNS announcing oncourse._oncourse._tcp.local. state announcing 2
26/09/2007 11:29:00 javax.jmdns.JmDNS$Announcer run
FINER: run() JmDNS announcing #announcing 1
26/09/2007 11:29:01 javax.jmdns.JmDNS$Announcer run
FINER: run() JmDNS announcing oncourse._oncourse._tcp.local. state announced
26/09/2007 11:29:01 javax.jmdns.JmDNS$Announcer run
FINER: run() JmDNS announcing #announcing 2
26/09/2007 11:29:01 javax.jmdns.JmDNS registerService
FINE: registerService() JmDNS registered service as service[oncourse._oncourse._tcp.local.,delish.ish.com.au/203.29.62.201:8181,The ish onCourse ser...]
-- When a client connects --
26/09/2007 11:30:54 javax.jmdns.JmDNS$Responder run
FINER: run() JmDNS responding
26/09/2007 11:30:54 javax.jmdns.JmDNS$Responder run
FINER: run() JmDNS responding
26/09/2007 11:30:55 javax.jmdns.JmDNS$Responder run
FINER: run() JmDNS responding
-- nothing further --
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, try to catch it in the act if you can. JmDNS.unregisterAllServices() instantiates the Canceler TimerTask, and then waits for notification that the all services have been canceled. If the Canceler hangs or throws an Exception/Error, the unregisterAllServices() will sit forever. There are several logger lines that will let you know how far the Canceler got if it hangs or has an Exception/Error.
It may be worth adding lock.notifyAll(); to the catch statement in Canceler.run() (JmDNS.java line 2234).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Docbug submitted a patch for JmDNS.java. We just need Rick to incorporate it into a new build ;-)
The patch takes care of locks in two seperate cases. I tested the second one and it looks good. I assume the first case (yours) is correct as well. If you patch your local copy of JmDNS and try it out, let us know if it works!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Re: getting Rick to incorporate the outstanding patches into a new build.... given that that patch has been sitting there unpatched for well over a year, what's the likelihood of that happening? I noticed in this thread http://sourceforge.net/forum/forum.php?thread_id=1227698&forum_id=324611 you were considering a branch with bug-fixes as your company is using JmDNS.
My employer also is bundling JmDNS into our application (http://ish.com.au/oncourse), so it'd be good to see this project revitalised, either by Rick or yourself. Before seeing the patch I started making a couple of simple threading improvements... anyway, let me know what you work out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had trouble getting the file patched too. I originally tried it in NetBeans, which threw an error and refused to patch. When I used the patch tool that ships with Ubuntu, it patched without issue. If you need it, I can email you the updated JmDNS.java.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, I should mention that I targeted Java 1.5. So there were one or two comments that were awaiting 1.5 that I uncommented (e.g., thread names).
Rick, so you know, I'm not interested in maintaining a fork. I simply wanted some fixes in place that for my company's apps were being badly affected by shutdown lockups…and we'd waited a while for them… it appeared to me that jmdns proper was inactive. What I've got is a maven-based clone - as I'd cloned it off someone else who'd mavenised it but renamed it completely (so the project layout has changed a little but it was easy for me to take and use).
So it would be better for these patches to be applied to the main source and relevant releases sent out to maven repos etc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No Problem! I am adding generics and doing a general clean up. The code will compile clean. I have already applied all patches so your apps should be fine.
I have no interest in supporting maven (old dog, new tricks). I will maintain the ant build, however. If you or anyone else wants to maintain maven support that would be great!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just tried this again with the latest version of jmdns (3.0) and it is still not shutting down. I'm running the sample class, DiscoverServiceTypes, and it doesn't ever exit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It does fix the problem of the sample DiscoverServiceTypes shutting down. I'm yet to try 3.0 with this patch out on a real app, but if you can apply the patch to cvs that'd be great. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for providing this. FYI - I still see a deadlock in close(), although it is slightly different than the originally reported (closeMulticastSocket() rather than in unregisterAllServices()). Filed it here as issue 2933183.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My other tasks were blocked by this issue, so I spent some time on it today. I have submitted a patch that appears to resolve the problem. As I noted in the patch, I have not looked for cases outside of closeMulticastSocket() where the SocketListener thread is joined.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does anyone have a work-a-round for the following block?
JmDNS.Shutdown" prio=5 tid=0x0838d600 nid=0x8379c00 in Object.wait() [0xbed0e000..0xbed0ea80]
at java.lang.Object.wait(Native Method)
- waiting on <0x309803b0> (a java.lang.Object)
at java.lang.Object.wait(Object.java:474)
at javax.jmdns.JmDNS.unregisterAllServices(JmDNS.java:682)
- locked <0x309803b0> (a java.lang.Object)
at javax.jmdns.JmDNS.close(JmDNS.java:2313)
- locked <0x30456058> (a ish.util.Zeroconf)
at javax.jmdns.JmDNS$Shutdown.run(JmDNS.java:2251)
at java.lang.Thread.run(Thread.java:595)
Any work-a-round, or fix, would be much appreciated. Thanks.
Woops, this part of the stack is also relevant.
"Timer-2" prio=5 tid=0x082fc000 nid=0x82fc200 waiting for monitor entry [0xbee53000..0xbee53b00]
at javax.jmdns.JmDNS$Renewer.run(JmDNS.java:1620)
- waiting to lock <0x30456058> (a ish.util.Zeroconf)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Can you get the logger output from JmDNS? When you start your app, add the following lines of code:
Logger logger = Logger.getLogger(JmDNS.class.toString());
ConsoleHandler handler = new ConsoleHandler();
logger.addHandler(handler);
logger.setLevel(Level.FINER);
handler.setLevel(Level.FINER);
Okay, set up a config file to the same effect. The lock-up is random (i.e., doesn't always occur) and in my subsequent quick tests today I've not been able to get it to lock up just yet... but here's the logging so far. Note: I get no logging output during the shutdown.
-- As the application is starting up --
26/09/2007 11:28:55 javax.jmdns.JmDNS <init>
FINER: JmDNS instance created
26/09/2007 11:28:57 javax.jmdns.JmDNS$Prober run
FINE: run() JmDNS probing oncourse._oncourse._tcp.local. state probing 2
26/09/2007 11:28:57 javax.jmdns.JmDNS$Prober run
FINER: run() JmDNS probing #probing 1
26/09/2007 11:28:58 javax.jmdns.JmDNS$Prober run
FINE: run() JmDNS probing oncourse._oncourse._tcp.local. state probing 3
26/09/2007 11:28:58 javax.jmdns.JmDNS$Prober run
FINER: run() JmDNS probing #probing 2
26/09/2007 11:28:59 javax.jmdns.JmDNS$Prober run
FINE: run() JmDNS probing oncourse._oncourse._tcp.local. state announcing 1
26/09/2007 11:28:59 javax.jmdns.JmDNS$Prober run
FINER: run() JmDNS probing #probing 3
26/09/2007 11:29:00 javax.jmdns.JmDNS$Announcer run
FINER: run() JmDNS announcing oncourse._oncourse._tcp.local. state announcing 2
26/09/2007 11:29:00 javax.jmdns.JmDNS$Announcer run
FINER: run() JmDNS announcing #announcing 1
26/09/2007 11:29:01 javax.jmdns.JmDNS$Announcer run
FINER: run() JmDNS announcing oncourse._oncourse._tcp.local. state announced
26/09/2007 11:29:01 javax.jmdns.JmDNS$Announcer run
FINER: run() JmDNS announcing #announcing 2
26/09/2007 11:29:01 javax.jmdns.JmDNS registerService
FINE: registerService() JmDNS registered service as service[oncourse._oncourse._tcp.local.,delish.ish.com.au/203.29.62.201:8181,The ish onCourse ser...]
-- When a client connects --
26/09/2007 11:30:54 javax.jmdns.JmDNS$Responder run
FINER: run() JmDNS responding
26/09/2007 11:30:54 javax.jmdns.JmDNS$Responder run
FINER: run() JmDNS responding
26/09/2007 11:30:55 javax.jmdns.JmDNS$Responder run
FINER: run() JmDNS responding
-- nothing further --
Yeah, try to catch it in the act if you can. JmDNS.unregisterAllServices() instantiates the Canceler TimerTask, and then waits for notification that the all services have been canceled. If the Canceler hangs or throws an Exception/Error, the unregisterAllServices() will sit forever. There are several logger lines that will let you know how far the Canceler got if it hangs or has an Exception/Error.
It may be worth adding lock.notifyAll(); to the catch statement in Canceler.run() (JmDNS.java line 2234).
Scratch what I said earlier. There's no need to debug it further, as your problem was already described here: http://sourceforge.net/tracker/index.php?func=detail&aid=1473279&group_id=93852&atid=605793
Docbug submitted a patch for JmDNS.java. We just need Rick to incorporate it into a new build ;-)
The patch takes care of locks in two seperate cases. I tested the second one and it looks good. I assume the first case (yours) is correct as well. If you patch your local copy of JmDNS and try it out, let us know if it works!
Thanks. I'll give that a go.
Re: getting Rick to incorporate the outstanding patches into a new build.... given that that patch has been sitting there unpatched for well over a year, what's the likelihood of that happening? I noticed in this thread http://sourceforge.net/forum/forum.php?thread_id=1227698&forum_id=324611 you were considering a branch with bug-fixes as your company is using JmDNS.
My employer also is bundling JmDNS into our application (http://ish.com.au/oncourse), so it'd be good to see this project revitalised, either by Rick or yourself. Before seeing the patch I started making a couple of simple threading improvements... anyway, let me know what you work out.
Ugh. The patch is not a valid patch. No wonder it hasn't been applied. It leaves the source unable to compile. See around line 2146.
Do you have a valid patch?
Thanks.
I had trouble getting the file patched too. I originally tried it in NetBeans, which threw an error and refused to patch. When I used the patch tool that ships with Ubuntu, it patched without issue. If you need it, I can email you the updated JmDNS.java.
For anyone interested… I've taken JmDNS 2.1 and applied relevant patches over here:
http://github.com/ldeck/jmdns
Any further patches welcome.
Thanks for doing it! I have not be getting forum updates lately so I did not even know this thread was active. Lame I know.
I want to move JmDNS to Java 1.5. (at least) I have a branch ready. Anyone still must use 1.4?
I'll second that, but please wait for Java 1.6. Our production systems are not yet ready for 1.6.
Yeah, I should mention that I targeted Java 1.5. So there were one or two comments that were awaiting 1.5 that I uncommented (e.g., thread names).
Rick, so you know, I'm not interested in maintaining a fork. I simply wanted some fixes in place that for my company's apps were being badly affected by shutdown lockups…and we'd waited a while for them… it appeared to me that jmdns proper was inactive. What I've got is a maven-based clone - as I'd cloned it off someone else who'd mavenised it but renamed it completely (so the project layout has changed a little but it was easy for me to take and use).
So it would be better for these patches to be applied to the main source and relevant releases sent out to maven repos etc
No Problem! I am adding generics and doing a general clean up. The code will compile clean. I have already applied all patches so your apps should be fine.
I have no interest in supporting maven (old dog, new tricks). I will maintain the ant build, however. If you or anyone else wants to maintain maven support that would be great!
I just tried this again with the latest version of jmdns (3.0) and it is still not shutting down. I'm running the sample class, DiscoverServiceTypes, and it doesn't ever exit.
Maybe this is a fix for your problem: http://sourceforge.net/support/tracker.php?aid=2910894
I just checked the code and the patch is in there. Must be something else or the fix is flawed.
Rick
I just tried canehan's suggestion and that seems to work. Do you think you can add that fix and do another release? Thanks.
We are getting ready a new release. I will make sure that the patch is applied.
Rick, it appears that canehan's patch isn't actually a real patch file so I've attached a proper one against the latest source here:
https://sourceforge.net/tracker/?func=detail&aid=2931171&group_id=93852&atid=605793
It does fix the problem of the sample DiscoverServiceTypes shutting down. I'm yet to try 3.0 with this patch out on a real app, but if you can apply the patch to cvs that'd be great. Thanks.
Again if anyone needs it sooner I've got the patch applied here (called it version 3.0.1):
http://github.com/ldeck/jmdns
Thanks for providing this. FYI - I still see a deadlock in close(), although it is slightly different than the originally reported (closeMulticastSocket() rather than in unregisterAllServices()). Filed it here as issue 2933183.
Hi all,
ldeck's patch is now in release 3.1. I am looking into the issue by jpile.
My other tasks were blocked by this issue, so I spent some time on it today. I have submitted a patch that appears to resolve the problem. As I noted in the patch, I have not looked for cases outside of closeMulticastSocket() where the SocketListener thread is joined.
Thanks I will see if I can get it in this weekend.