weixin_39789979
2020-12-29 20:53 阅读 0

JmDNS stops after a few seconds

In version 3.4.1 i was able to create a JmDNS instance, which listened for new services as long as i explicitly stopped it. Since version 3.5 the JmDNS instance stops after a very short period of time. At the moment i work with a fixed timer which starts the JmDNS resolution every 3 seconds but i think this is not the right way to do that.

Any help is appreciated.

该提问来源于开源项目:jmdns/jmdns

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

11条回答 默认 最新

  • weixin_39850152 weixin_39850152 2020-12-29 20:53

    Could you check the commit history to see if any of the changes could have caused this? I didn't do any recent testing, but I would strongly assume that listening for services still works as this is one of the major use cases of this lib...

    点赞 评论 复制链接分享
  • weixin_39789979 weixin_39789979 2020-12-29 20:53
    
    public class Test
    {
      public static void main(String... args)
      {
         JmDNS jmDNS = JmDNS.create(InetAddress.getLocalHost());
         ServiceInfo info = ServiceInfo.create("_http._tcp.local.", "example", 1234, "");
         jmDNS.registerService(info);
      }
    }
    

    Well the SocketListener in the JmDNSImpl is in both versions a daemon thread. In the commit history i searched for other new daemon threads and WeakReferences but did not find anything.

    How is it possible that this piece of code keeps itself alive under version 3.4.1 and gets terminated by the JVM under version 3.5.1 after the registerService command.

    点赞 评论 复制链接分享
  • weixin_39789979 weixin_39789979 2020-12-29 20:53

    https://github.com/jmdns/jmdns/commit/07e5bbd89f1fa4fc07d40cc94056e7d905f10b21

    This commit was/is responsible for that behaviour i described. Since the _stateTimer in the DNSTaskStarterImpl is marked as a daemon thread, the JVM will terminate any JmDNS instance immediately.

    点赞 评论 复制链接分享
  • weixin_39892800 weixin_39892800 2020-12-29 20:53

    I suppose if your main() had a blocking loop (or just Thread.sleep(Integer.INFINITE), the jmDNS instance would not be killed. I would not rely on any library having or not having daemon threads.

    点赞 评论 复制链接分享
  • weixin_39539563 weixin_39539563 2020-12-29 20:53

    Yes, jmdns.close() blocks for 5 seconds. I do not consider that a "short time". That is an eternity, compared to the time it takes to discovery and resolve multiple services. At a minimum, it would be nice if the library had onDiscoveryStarted and onDiscroveryStopped-like event listener methods. It would be even nicer if close() didn't block with a 5 second delay.

    点赞 评论 复制链接分享
  • weixin_39655981 weixin_39655981 2020-12-29 20:53

    I'm facing the same issue. i got the following logs (without response to the client):

    
    [SocketListener(raspberrypi)] DEBUG javax.jmdns.impl.DNSIncoming - DNSIncoming() questions:0 answers:2 authorities:0 additionals:2
    [SocketListener(raspberrypi)] DEBUG javax.jmdns.impl.DNSIncoming - DNSIncoming() unknown type: TYPE_NSEC index 47
    [SocketListener(raspberrypi)] DEBUG javax.jmdns.impl.DNSIncoming - DNSIncoming() unknown type: TYPE_NSEC index 47
    [SocketListener(raspberrypi)] DEBUG javax.jmdns.impl.JmDNSImpl - raspberrypi handle response: [Pointer type: TYPE_PTR index 12, class: CLASS_IN index 1-unique, name: 31.1.168.192.in-addr.arpa. ttl: '119/120' alias: 'Android.local.']
    [SocketListener(raspberrypi)] DEBUG javax.jmdns.impl.JmDNSImpl - raspberrypi handle response cached record: [Pointer type: TYPE_PTR index 12, class: CLASS_IN index 1-unique, name: 31.1.168.192.in-addr.arpa. ttl: '87/120' alias: 'Android.local.']
    [SocketListener(raspberrypi)] DEBUG javax.jmdns.impl.JmDNSImpl - raspberrypi registering service type: 31.1.168.192.in-addr.arpa. as: in-addr.arpa.
    [SocketListener(raspberrypi)] DEBUG javax.jmdns.impl.JmDNSImpl - raspberrypi handle response: [Pointer type: TYPE_PTR index 12, class: CLASS_IN index 1-unique, name: 6.3.5.4.D.1.E.F.F.F.7.4.3.4.2.F.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. ttl: '119/120' alias: 'Android.local.']
    [SocketListener(raspberrypi)] DEBUG javax.jmdns.impl.JmDNSImpl - raspberrypi handle response cached record: [Pointer type: TYPE_PTR index 12, class: CLASS_IN index 1-unique, name: 6.3.5.4.D.1.E.F.F.F.7.4.3.4.2.F.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. ttl: '87/120' alias: 'Android.local.']
    [SocketListener(raspberrypi)] DEBUG javax.jmdns.impl.JmDNSImpl - raspberrypi registering service type: 6.3.5.4.D.1.E.F.F.F.7.4.3.4.2.F.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. as: ip6.arpa.
    

    it is also strange that it response to ipv6 even though i disable it in the JVM

    
    -Djava.net.preferIPv4Stack=true
    
    点赞 评论 复制链接分享
  • weixin_39655981 weixin_39655981 2020-12-29 20:53

    i have also un expected behavior. in some cases it works for one minute and then stopped. in some cases i leave it for long time and it still works. I'm running it in Raspberry pi.

    if i understood the comment from correctly; i need to make sure that the daemon thread is busy and running all the time. so i enabled the debug logging and the results was better. im getting the response now most of the time -Dorg.slf4j.simpleLogger.defaultLogLevel=DEBUG

    but enabling debug is not practical for the normal practice

    点赞 评论 复制链接分享
  • weixin_39655981 weixin_39655981 2020-12-29 20:53

    i noticed also that increasing the java process priority (e.g. nice --12) will help a lot in this issue.

    点赞 评论 复制链接分享
  • weixin_39655981 weixin_39655981 2020-12-29 20:53

    Again, JmDNS works in a very random way here. it stops responding after setting the attributes (ServiceInfo.setText()) for the first time. I traced the server network traffic (tcpdump -i wlan0 port 5353) and it is clearly missing a response from the JmDNS. re-announce the new records is not happening as well.

    this makes the library not stable at all.

    点赞 评论 复制链接分享
  • weixin_39655981 weixin_39655981 2020-12-29 20:53

    is there any time needed between the calls of ServiceInfo.setText() i.e. is there any time period needed between re-announcing the updates.

    点赞 评论 复制链接分享
  • weixin_39850152 weixin_39850152 2020-12-29 20:53

    I don't know, I didn't implement it. If you find a bug and can provide a decent fix, please come up with a PR.

    点赞 评论 复制链接分享