Community
Participate
Working Groups
Hi, the JMDNS discovery provider reports "8.e.f.ip6.arpa." link local addresses as service types. This looks suspicious and might be a bug in JMDNS itself. A commented testcase illustrating this problem can be found in the discovery tests.
http://sourceforge.net/tracker/index.php?func=detail&aid=1791481&group_id=93852&atid=605791 tracks this issue in the JMDNS bugtracking.
changing target milestone
Markus, Can you reliably reproduce this exception? On my network I cannot, and this makes it difficult to debug, obviously (which I'm trying to do, now that I have the jmDNS source and committer access for fixing). If you can reliably reproduce I could send you a copy of the jmDNS as an Eclipse project and you could link the jar to the source (have to update to use the jar as well, but I could also provide the changes to org.eclipse.ecf.provider.jmdns). So please LMK and whether there is some bandwidth to help. Obviously I would like to get this fixed for Ganymede.
Created attachment 106249 [details] error messages from running equinox p2 direcotr application Errors from scenario described in comment 4
Scott, I think I am seeing this same bug in a whole different area. Using Eclipse 3.4 I'm trying to run the equinox p2 director application to handle some provisioning operations. During application startup I get similar messages to the original errors. P2 director stalls for between 15 seconds and 8 min right after these messages, and then continues to process without problems. I have attached a slightly obfuscated dump of the messages. If you are still looking for a repeatable case for testing, I can probably help you out. Just let me know. Rich Scott
Created attachment 106251 [details] error messages from running equinox p2 direcotr application Errors from scenario described in comment 4
(In reply to comment #5) > Scott, > > I think I am seeing this same bug in a whole different area. Using Eclipse 3.4 > I'm trying to run the equinox p2 director application to handle some > provisioning operations. During application startup I get similar messages to > the original errors. P2 director stalls for between 15 seconds and 8 min right > after these messages, and then continues to process without problems. I have > attached a slightly obfuscated dump of the messages. > > If you are still looking for a repeatable case for testing, I can probably help > you out. Just let me know. > > Rich Scott > Hi Rich, First...you can turn off the ECF discovery for the director application if you wish...the director doesn't actually use discovery yet. To do this you can just close these three plugins in your workspace...or remove them from the run config that is running the director: org.eclipse.ecf.discovery org.eclipse.ecf.provider.jmdns org.eclipse.ecf.provider.jslp This should prevent the "DEBUG OUTPUT: true" from appearing (jSLP), and it should also prevent the IPv6 spam from appearing. The output from your log does look like you are running jmdns (ECF's zeroconf provider) on an IPv6 network...as I've determined that jmdns 2.0 itself does not understand IPv6 addressing (and in ECF when a service is reported by jmdns to the ECF provider ECF detects this and puts the info out to the log...as you are seeing). To deal with this we/ECF will have to get an enhancement to jmdns 2.1. Now, as for your delay in starting/loading p2...this does not make sense to me...and I don't think it has anything to do with ECF at all. I have heard reports, though, that with some proxys (i.e. those that don't do name resolution) that this can cause a delay in p2 startup, because of the use of the URL class in p2 (which makes frequent calls to URL.equals which uses DNS). See bug #121201. If you remove the plugins above and the delay goes away then please let us know about it here. But this is not what I expect (I expect the delay to continue...even after removing the ecf discovery stuff from the running of the director app). Thanks for the log output...it will help make the case for adding IPv6 support in Jmdns 2.X.
(In reply to comment #7) Scott, Thanks for the reply. When running director from within eclipse your suggestion worked great. I am also no longer seeing the startup delay. Do you know if there is a similar method that can be used to eliminate those plugins when running director headless (ie from the command line)? I am running it like eclipsec.exe -application org.eclipse.equinox.p2.director.app.application <args> Do I need to generate a eclipse install that drops those 3 plugins and everything that depends on them? Is that even possible or will all of ecf have to go. If I just remove those 3 and try to run, I get launch errors due to unresolved dependencies to those plugins. Thanks Rich > (In reply to comment #5) > > Scott, > > > > I think I am seeing this same bug in a whole different area. Using Eclipse 3.4 > > I'm trying to run the equinox p2 director application to handle some > > provisioning operations. During application startup I get similar messages to > > the original errors. P2 director stalls for between 15 seconds and 8 min right > > after these messages, and then continues to process without problems. I have > > attached a slightly obfuscated dump of the messages. > > > > If you are still looking for a repeatable case for testing, I can probably help > > you out. Just let me know. > > > > Rich Scott > > > > Hi Rich, > > First...you can turn off the ECF discovery for the director application if you > wish...the director doesn't actually use discovery yet. To do this you can > just close these three plugins in your workspace...or remove them from the run > config that is running the director: > > org.eclipse.ecf.discovery > org.eclipse.ecf.provider.jmdns > org.eclipse.ecf.provider.jslp > > This should prevent the "DEBUG OUTPUT: true" from appearing (jSLP), and it > should also prevent the IPv6 spam from appearing. > > The output from your log does look like you are running jmdns (ECF's zeroconf > provider) on an IPv6 network...as I've determined that jmdns 2.0 itself does > not understand IPv6 addressing (and in ECF when a service is reported by jmdns > to the ECF provider ECF detects this and puts the info out to the log...as you > are seeing). To deal with this we/ECF will have to get an enhancement to jmdns > 2.1. > > Now, as for your delay in starting/loading p2...this does not make sense to > me...and I don't think it has anything to do with ECF at all. I have heard > reports, though, that with some proxys (i.e. those that don't do name > resolution) that this can cause a delay in p2 startup, because of the use of > the URL class in p2 (which makes frequent calls to URL.equals which uses DNS). > See bug #121201. > > If you remove the plugins above and the delay goes away then please let us know > about it here. But this is not what I expect (I expect the delay to > continue...even after removing the ecf discovery stuff from the running of the > director app). > > Thanks for the log output...it will help make the case for adding IPv6 support > in Jmdns 2.X. >
(In reply to comment #8) > (In reply to comment #7) > Scott, > > Thanks for the reply. When running director from within eclipse your suggestion > worked great. I am also no longer seeing the startup delay. So would you help us out with trying to figure out why this is? AFAIK, there should be no reason why the rest of the application (i.e. the directory) is delayed/slowed by the presence of the ECF discovery API and the two providers (Jmdns and jSLP). Could you try to re-activate these plugins and then run the director under the Eclipse debugger...and then during the delay period pause the threads (particularly the main thread)...and perhaps attach a stack trace here? If ECF's two providers are somehow causing this delay I would like to understand why. Thanksinadvance. > > Do you know if there is a similar method that can be used to eliminate those > plugins when running director headless (ie from the command line)? I am > running it like > > eclipsec.exe -application org.eclipse.equinox.p2.director.app.application > <args> > > Do I need to generate a eclipse install that drops those 3 plugins and > everything that depends on them? Yes...basically that's right. >Is that even possible or will all of ecf have > to go. If I just remove those 3 and try to run, I get launch errors due to > unresolved dependencies to those plugins. The p2 work has dependencies on the ECF filetransfer plugins: org.eclipse.ecf.filetransfer, and org.eclipse.ecf.provider.filetransfer, and these in turn have dependencies on org.eclipse.ecf, and org.eclipse.ecf.identity. The discovery code/providers has dependencies on org.eclipse.ecf and org.eclipse.ecf.identity. So if you include org.eclipse.ecf.identity org.eclipse.ecf org.eclipse.ecf.ssl org.eclipse.ecf.filetransfer org.eclipse.ecf.provider.filetransfer org.eclipse.ecf.provider.filetransfer.ssl and *nothing else* (i.e. non of the discovery API or providers), then the director application should just run with the 6 plugins above. But if you would, I would really appreciate you helping us track down the cause of this delay (assuming it's somewhere in the discovery API), because we've not seen this in any tests, so I think it must be sensitive to your network or system environment. Thanks
Scott, I will try to get a stack trace for you, but won't get get a chance to try it until Monday. Rich (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > Scott, > > > > Thanks for the reply. When running director from within eclipse your suggestion > > worked great. I am also no longer seeing the startup delay. > > > So would you help us out with trying to figure out why this is? AFAIK, there > should be no reason why the rest of the application (i.e. the directory) is > delayed/slowed by the presence of the ECF discovery API and the two providers > (Jmdns and jSLP). > > Could you try to re-activate these plugins and then run the director under the > Eclipse debugger...and then during the delay period pause the threads > (particularly the main thread)...and perhaps attach a stack trace here? > > If ECF's two providers are somehow causing this delay I would like to > understand why. > > Thanksinadvance. > > > > > > Do you know if there is a similar method that can be used to eliminate those > > plugins when running director headless (ie from the command line)? I am > > running it like > > > > eclipsec.exe -application org.eclipse.equinox.p2.director.app.application > > <args> > > > > Do I need to generate a eclipse install that drops those 3 plugins and > > everything that depends on them? > > > Yes...basically that's right. > > > >Is that even possible or will all of ecf have > > to go. If I just remove those 3 and try to run, I get launch errors due to > > unresolved dependencies to those plugins. > > > The p2 work has dependencies on the ECF filetransfer plugins: > org.eclipse.ecf.filetransfer, and org.eclipse.ecf.provider.filetransfer, and > these in turn have dependencies on org.eclipse.ecf, and > org.eclipse.ecf.identity. The discovery code/providers has dependencies on > org.eclipse.ecf and org.eclipse.ecf.identity. > > So if you include > > org.eclipse.ecf.identity > org.eclipse.ecf > org.eclipse.ecf.ssl > org.eclipse.ecf.filetransfer > org.eclipse.ecf.provider.filetransfer > org.eclipse.ecf.provider.filetransfer.ssl > > and *nothing else* (i.e. non of the discovery API or providers), then the > director application should just run with the 6 plugins above. > > But if you would, I would really appreciate you helping us track down the cause > of this delay (assuming it's somewhere in the discovery API), because we've not > seen this in any tests, so I think it must be sensitive to your network or > system environment. > > Thanks >
FWIW JMDNS 2.1 has been checked into ECF's CVS.
Upstream handles this here: https://sourceforge.net/tracker/?func=detail&atid=605791&aid=1791481&group_id=93852
Resolving as fixed given comment 12. If this isn't actually fixed and there is something for ECF to do, please reopen.
