Recent changes to patches

bKlAGihuyEgasx

2012-10-19T03:03:46Z

6NTxym A big thank you for your post. Cool.

Another thread preventing application shutdown

2012-06-27T23:04:05Z

I found another thread which was preventing application shutdown, this time spawned by an executor.

This patch also adds names to JmDNS' executor threads to make it easier to figure out which one causes it if it occurs in the future (similar to what's being done at Lucene.)

Non-daemon threads prevent application shutdown

2012-06-08T06:30:43Z

Our application wasn't shutting down after the last window closed. Turned out JmDNS had some non-daemon threads keeping the JVM alive.

This patch marks those as daemons.

JmmDNS wasn't requesting on loopback

2012-06-07T06:57:34Z

Updating to JmDNS 3.x broke our test case where the server is advertised on the loopback address. This patch makes that work again.

JmmDNS improvements

2012-06-07T06:07:24Z

Tracking down my own issue in 3525349, this patch fixes some issues and improves things a little but without fixing it...

Fix #1: When JmmDNS started, it wasn't scanning for network interfaces up-front. Now it does.

Fix #2: The timeout was being applied incorrectly - if you had N network interfaces it would apply a timeout of up to N times your requested timeout.

Fix #3: The executor wasn't being shut down in the event of an error, causing threads to hang around forever.

free Factory's DNSTaskStarter when calling JmDNS.close()

2012-03-30T16:16:53Z

calling JmDNS.create() and then calling close() on the returned instance doesn't free the associated DNSTaskStarter from within the Factory.

this becomes evident during long-lived code which repeatedly creates and closes JmDNS, and the problem is easily reproducible for testing with a simple loop of code.

i've fixed this by adding a disposeStarter(JmDNS ...) method to the Factory in DNSTaskStarter, and then calling this method from close() in JmDNSImpl

i've been chasing a memory leak in JmDNS for a short while, admittedly my previous patch was indeed premature - but this one actually nails the problem (have double-checked by comparing heap dumps, etc)

free resources properly in DNSStatefulObjectSemaphore

2012-03-30T03:19:02Z

method signalEvent() in DNSStatefulObjectSemaphore was not removing semaphores from the correct collection, it was removing them from the local copy (used only for iteration), and not actually from the class's ConcurrentHashMap - thus it was holding/'leaking' resources, including references to threads (ouch), preventing garbage collection.

Patch is a one-liner! :)

avoid slow getHostName() when name passed in

2011-09-15T15:50:42Z

On certain networks, getHostName() is very slow (10 or 20 seconds).
I am calling "JmDNS.create(addr, hostname)". Note the passing of an alread-known hostname. However, there is some code in HostInfo.java which calls getHostName() even if hostname was passed in (see patch). This patch alleviated this in my application. I post it here for possible inclusion in JmDNS. If my thinking is not correct, or I am missing some critical usage which forces the lookup, please advise. I'm always trying to learn.
Regards,
SteveT

Remove call to isEmpty (for Android)

2010-11-20T00:17:49Z

I noticed in the log you've done this before. Here's a new one that's popped up.

Replace dots with dashes in hostname instead of truncating

2010-11-17T23:06:47Z

When creating a HostInfo, the name is currently truncated at the first dot. Since the default Java behavior is to return a dotted-quad IP address when no hostname is present, this results in devices all having similar names (192, 192-1, 192-2, etc). If we instead replace the dots with dashes, then the hostname chosen is a bit more descriptive.

It's fairly minor, but it's sometimes nice in debugging scenarios to have the slightly more descriptive hostname default. I've been using this for a while now, with no negative repercussions, but I'm not sure if there's something bad that might happen in other setups when using this approach.