Home » Archived » Eclipse Communications Framework (ECF) » JmDNS discovery issue
|
| Re: JmDNS discovery issue [message #623579 is a reply to message #623577] |
Mon, 19 May 2008 16:37   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
Bill Joy wrote:
> In ECF 1.2.0 and prior versions, I would add myself as a service listener
> for my type of service, then request service info for it when receiving the
> serviceAdded() event.
>
> In ECF 2.0.0, there is no longer an exposed serviceAdded() and the container
> makes the request service info call. In fact, it makes a request for every
> service which is reported.
>
> Since my network has dozens of different services running, I am seeing the
> container going through a lot of unnecessary overhead and causing extra
> network traffic.
>
> What is the purpose of resolving services when there are no registered
> listeners for that information?
The main reason was simplification of the discovery API. Especially in
moving the API to support other providers (e.g. jSLP, which is now in
there), it became apparent that the zeroconf model of having a two step
resolution process (i.e. get notification of service existence, and then
resolving manually) did not generalize well/easily to other
providers...and it adds a level of complexity in the use of the API as well.
Yes, for the zeroconf provider the cost of this is additional network
traffic.
>
> I am seeing the following exception if there is a disconnect done before
> resolution of all those services is complete:
>
> java.lang.IllegalStateException: Timer already cancelled.
> at java.util.Timer.sched(Timer.java:354)
> at java.util.Timer.schedule(Timer.java:222)
> at javax.jmdns.JmDNS$ServiceInfoResolver.start(JmDNS.java:2100)
> at javax.jmdns.JmDNS.requestServiceInfo(JmDNS.java:452)
> at
> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$3.run(JMDNSDiscoveryContainer.java:326)
> at
> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$1.run(JMDNSDiscoveryContainer.java:117)
> at java.lang.Thread.run(Thread.java:595)
>
> So I expect the Runnable doing the resolution request call should be
> checking if the service is still connected before issuing it.
I have seen this as well. I believe it would qualify as a JmDNS bug, as
the Thread running this code is created/started within JmDNS.
But if you would be kind enough to file an ECF bug on this as well we
will do our best to address it.
Thanks,
Scott
|
|
|
| Re: JmDNS discovery issue [message #623580 is a reply to message #623579] |
Mon, 19 May 2008 16:43 |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
Since you are going to add a check if the service is connected before doing
the service info request, why can't you check if there is a registered
listener for that service type before doing that call too?
"Scott Lewis" <slewis@composent.com> wrote in message
news:4831ACCE.8020700@composent.com...
> Hi Bill,
>
> Bill Joy wrote:
>> In ECF 1.2.0 and prior versions, I would add myself as a service listener
>> for my type of service, then request service info for it when receiving
>> the serviceAdded() event.
>>
>> In ECF 2.0.0, there is no longer an exposed serviceAdded() and the
>> container makes the request service info call. In fact, it makes a
>> request for every service which is reported.
>>
>> Since my network has dozens of different services running, I am seeing
>> the container going through a lot of unnecessary overhead and causing
>> extra network traffic.
>>
>> What is the purpose of resolving services when there are no registered
>> listeners for that information?
>
>
> The main reason was simplification of the discovery API. Especially in
> moving the API to support other providers (e.g. jSLP, which is now in
> there), it became apparent that the zeroconf model of having a two step
> resolution process (i.e. get notification of service existence, and then
> resolving manually) did not generalize well/easily to other
> providers...and it adds a level of complexity in the use of the API as
> well.
>
> Yes, for the zeroconf provider the cost of this is additional network
> traffic.
>
>
>>
>> I am seeing the following exception if there is a disconnect done before
>> resolution of all those services is complete:
>>
>> java.lang.IllegalStateException: Timer already cancelled.
>> at java.util.Timer.sched(Timer.java:354)
>> at java.util.Timer.schedule(Timer.java:222)
>> at javax.jmdns.JmDNS$ServiceInfoResolver.start(JmDNS.java:2100)
>> at javax.jmdns.JmDNS.requestServiceInfo(JmDNS.java:452)
>> at
>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$3.run(JMDNSDiscoveryContainer.java:326)
>> at
>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$1.run(JMDNSDiscoveryContainer.java:117)
>> at java.lang.Thread.run(Thread.java:595)
>>
>> So I expect the Runnable doing the resolution request call should be
>> checking if the service is still connected before issuing it.
>
>
> I have seen this as well. I believe it would qualify as a JmDNS bug, as
> the Thread running this code is created/started within JmDNS.
>
> But if you would be kind enough to file an ECF bug on this as well we will
> do our best to address it.
>
> Thanks,
>
> Scott
|
|
|
| Re: JmDNS discovery issue [message #623582 is a reply to message #623580] |
Mon, 19 May 2008 17:19 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
Bill Joy wrote:
> Since you are going to add a check if the service is connected before doing
> the service info request, why can't you check if there is a registered
> listener for that service type before doing that call too?
We could/might, but I don't believe this would really fix the problem,
as it still would be possible to issue the request (connected), then
disconnect, and then have the jmdns thread make the callback and fail as
below.
But I'm willing to make the connect check anyway, to reduce the likelihood.
Scott
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:4831ACCE.8020700@composent.com...
>> Hi Bill,
>>
>> Bill Joy wrote:
>>> In ECF 1.2.0 and prior versions, I would add myself as a service listener
>>> for my type of service, then request service info for it when receiving
>>> the serviceAdded() event.
>>>
>>> In ECF 2.0.0, there is no longer an exposed serviceAdded() and the
>>> container makes the request service info call. In fact, it makes a
>>> request for every service which is reported.
>>>
>>> Since my network has dozens of different services running, I am seeing
>>> the container going through a lot of unnecessary overhead and causing
>>> extra network traffic.
>>>
>>> What is the purpose of resolving services when there are no registered
>>> listeners for that information?
>>
>> The main reason was simplification of the discovery API. Especially in
>> moving the API to support other providers (e.g. jSLP, which is now in
>> there), it became apparent that the zeroconf model of having a two step
>> resolution process (i.e. get notification of service existence, and then
>> resolving manually) did not generalize well/easily to other
>> providers...and it adds a level of complexity in the use of the API as
>> well.
>>
>> Yes, for the zeroconf provider the cost of this is additional network
>> traffic.
>>
>>
>>> I am seeing the following exception if there is a disconnect done before
>>> resolution of all those services is complete:
>>>
>>> java.lang.IllegalStateException: Timer already cancelled.
>>> at java.util.Timer.sched(Timer.java:354)
>>> at java.util.Timer.schedule(Timer.java:222)
>>> at javax.jmdns.JmDNS$ServiceInfoResolver.start(JmDNS.java:2100)
>>> at javax.jmdns.JmDNS.requestServiceInfo(JmDNS.java:452)
>>> at
>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$3.run(JMDNSDiscoveryContainer.java:326)
>>> at
>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$1.run(JMDNSDiscoveryContainer.java:117)
>>> at java.lang.Thread.run(Thread.java:595)
>>>
>>> So I expect the Runnable doing the resolution request call should be
>>> checking if the service is still connected before issuing it.
>>
>> I have seen this as well. I believe it would qualify as a JmDNS bug, as
>> the Thread running this code is created/started within JmDNS.
>>
>> But if you would be kind enough to file an ECF bug on this as well we will
>> do our best to address it.
>>
>> Thanks,
>>
>> Scott
>
>
|
|
|
| Re: JmDNS discovery issue [message #623584 is a reply to message #623582] |
Mon, 19 May 2008 17:42 |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
If I understand your reply, that is not what I was suggesting.
In the old design, I would register as a listener for my service type then
request the service info when I was told the service was added.
Since you don't want that two step process, have the container ask for the
service info on service added only because I had previously registered as a
listener for that service type. No request for service info would be sent
unless there is a registered listener for the result.
This is a return to the old behavior despite the simplified API.
"Scott Lewis" <slewis@composent.com> wrote in message
news:4831B692.1080902@composent.com...
> Hi Bill,
>
> Bill Joy wrote:
>> Since you are going to add a check if the service is connected before
>> doing the service info request, why can't you check if there is a
>> registered listener for that service type before doing that call too?
>
> We could/might, but I don't believe this would really fix the problem, as
> it still would be possible to issue the request (connected), then
> disconnect, and then have the jmdns thread make the callback and fail as
> below.
>
> But I'm willing to make the connect check anyway, to reduce the
> likelihood.
>
> Scott
>
>
>
>>
>>
>> "Scott Lewis" <slewis@composent.com> wrote in message
>> news:4831ACCE.8020700@composent.com...
>>> Hi Bill,
>>>
>>> Bill Joy wrote:
>>>> In ECF 1.2.0 and prior versions, I would add myself as a service
>>>> listener for my type of service, then request service info for it when
>>>> receiving the serviceAdded() event.
>>>>
>>>> In ECF 2.0.0, there is no longer an exposed serviceAdded() and the
>>>> container makes the request service info call. In fact, it makes a
>>>> request for every service which is reported.
>>>>
>>>> Since my network has dozens of different services running, I am seeing
>>>> the container going through a lot of unnecessary overhead and causing
>>>> extra network traffic.
>>>>
>>>> What is the purpose of resolving services when there are no registered
>>>> listeners for that information?
>>>
>>> The main reason was simplification of the discovery API. Especially in
>>> moving the API to support other providers (e.g. jSLP, which is now in
>>> there), it became apparent that the zeroconf model of having a two step
>>> resolution process (i.e. get notification of service existence, and then
>>> resolving manually) did not generalize well/easily to other
>>> providers...and it adds a level of complexity in the use of the API as
>>> well.
>>>
>>> Yes, for the zeroconf provider the cost of this is additional network
>>> traffic.
>>>
>>>
>>>> I am seeing the following exception if there is a disconnect done
>>>> before resolution of all those services is complete:
>>>>
>>>> java.lang.IllegalStateException: Timer already cancelled.
>>>> at java.util.Timer.sched(Timer.java:354)
>>>> at java.util.Timer.schedule(Timer.java:222)
>>>> at javax.jmdns.JmDNS$ServiceInfoResolver.start(JmDNS.java:2100)
>>>> at javax.jmdns.JmDNS.requestServiceInfo(JmDNS.java:452)
>>>> at
>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$3.run(JMDNSDiscoveryContainer.java:326)
>>>> at
>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$1.run(JMDNSDiscoveryContainer.java:117)
>>>> at java.lang.Thread.run(Thread.java:595)
>>>>
>>>> So I expect the Runnable doing the resolution request call should be
>>>> checking if the service is still connected before issuing it.
>>>
>>> I have seen this as well. I believe it would qualify as a JmDNS bug, as
>>> the Thread running this code is created/started within JmDNS.
>>>
>>> But if you would be kind enough to file an ECF bug on this as well we
>>> will do our best to address it.
>>>
>>> Thanks,
>>>
>>> Scott
>>
|
|
|
| Re: JmDNS discovery issue [message #623585 is a reply to message #623584] |
Mon, 19 May 2008 18:02 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
Bill Joy wrote:
> If I understand your reply, that is not what I was suggesting.
>
> In the old design, I would register as a listener for my service type then
> request the service info when I was told the service was added.
>
> Since you don't want that two step process, have the container ask for the
> service info on service added only because I had previously registered as a
> listener for that service type. No request for service info would be sent
> unless there is a registered listener for the result.
>
> This is a return to the old behavior despite the simplified API.
I see. OK, please create a bug and I will modify appropriately.
BTW, what apps/services are you registering/unregistering that end up
returning null from JMDNS ServiceEvent.getInfo() (i.e. and showing the
NPE from Re: NullPointerException in AbstractDiscoveryContainerAdapter)?
I've been testing with iTunes, trying to test out a fix, but it doesn't
seem to invoke serviceRemoved (on exit or deactivation).
Thanks,
Scott
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:4831B692.1080902@composent.com...
>> Hi Bill,
>>
>> Bill Joy wrote:
>>> Since you are going to add a check if the service is connected before
>>> doing the service info request, why can't you check if there is a
>>> registered listener for that service type before doing that call too?
>> We could/might, but I don't believe this would really fix the problem, as
>> it still would be possible to issue the request (connected), then
>> disconnect, and then have the jmdns thread make the callback and fail as
>> below.
>>
>> But I'm willing to make the connect check anyway, to reduce the
>> likelihood.
>>
>> Scott
>>
>>
>>
>>>
>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>> news:4831ACCE.8020700@composent.com...
>>>> Hi Bill,
>>>>
>>>> Bill Joy wrote:
>>>>> In ECF 1.2.0 and prior versions, I would add myself as a service
>>>>> listener for my type of service, then request service info for it when
>>>>> receiving the serviceAdded() event.
>>>>>
>>>>> In ECF 2.0.0, there is no longer an exposed serviceAdded() and the
>>>>> container makes the request service info call. In fact, it makes a
>>>>> request for every service which is reported.
>>>>>
>>>>> Since my network has dozens of different services running, I am seeing
>>>>> the container going through a lot of unnecessary overhead and causing
>>>>> extra network traffic.
>>>>>
>>>>> What is the purpose of resolving services when there are no registered
>>>>> listeners for that information?
>>>> The main reason was simplification of the discovery API. Especially in
>>>> moving the API to support other providers (e.g. jSLP, which is now in
>>>> there), it became apparent that the zeroconf model of having a two step
>>>> resolution process (i.e. get notification of service existence, and then
>>>> resolving manually) did not generalize well/easily to other
>>>> providers...and it adds a level of complexity in the use of the API as
>>>> well.
>>>>
>>>> Yes, for the zeroconf provider the cost of this is additional network
>>>> traffic.
>>>>
>>>>
>>>>> I am seeing the following exception if there is a disconnect done
>>>>> before resolution of all those services is complete:
>>>>>
>>>>> java.lang.IllegalStateException: Timer already cancelled.
>>>>> at java.util.Timer.sched(Timer.java:354)
>>>>> at java.util.Timer.schedule(Timer.java:222)
>>>>> at javax.jmdns.JmDNS$ServiceInfoResolver.start(JmDNS.java:2100)
>>>>> at javax.jmdns.JmDNS.requestServiceInfo(JmDNS.java:452)
>>>>> at
>>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$3.run(JMDNSDiscoveryContainer.java:326)
>>>>> at
>>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$1.run(JMDNSDiscoveryContainer.java:117)
>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>>
>>>>> So I expect the Runnable doing the resolution request call should be
>>>>> checking if the service is still connected before issuing it.
>>>> I have seen this as well. I believe it would qualify as a JmDNS bug, as
>>>> the Thread running this code is created/started within JmDNS.
>>>>
>>>> But if you would be kind enough to file an ECF bug on this as well we
>>>> will do our best to address it.
>>>>
>>>> Thanks,
>>>>
>>>> Scott
>
|
|
|
| Re: JmDNS discovery issue [message #623586 is a reply to message #623585] |
Mon, 19 May 2008 18:24 |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
Could be that you are just not waiting long enough for the timeout
processing when services just silently drop off the network? I seem to
recall a timeout interval of something like 20-30 minutes.
My plugin is part of a custom P2P implementation where the user is given UI
to connect/disconnect.
I can reproduce the problem even when there are no peers on the network just
by connecting then disconnecting.
You probably should be able to reproduce by using JBuilder 2008 on the same
LAN.
http://cc.codegear.com/free/jbuilder
The P2P feature is available in the Turbo version.
"Scott Lewis" <slewis@composent.com> wrote in message
news:4831C099.1000907@composent.com...
> Hi Bill,
>
>
> Bill Joy wrote:
>> If I understand your reply, that is not what I was suggesting.
>>
>> In the old design, I would register as a listener for my service type
>> then request the service info when I was told the service was added.
>>
>> Since you don't want that two step process, have the container ask for
>> the service info on service added only because I had previously
>> registered as a listener for that service type. No request for service
>> info would be sent unless there is a registered listener for the result.
>>
>> This is a return to the old behavior despite the simplified API.
>
>
> I see. OK, please create a bug and I will modify appropriately.
>
> BTW, what apps/services are you registering/unregistering that end up
> returning null from JMDNS ServiceEvent.getInfo() (i.e. and showing the NPE
> from Re: NullPointerException in AbstractDiscoveryContainerAdapter)? I've
> been testing with iTunes, trying to test out a fix, but it doesn't seem to
> invoke serviceRemoved (on exit or deactivation).
>
> Thanks,
>
> Scott
>
>
>>
>>
>> "Scott Lewis" <slewis@composent.com> wrote in message
>> news:4831B692.1080902@composent.com...
>>> Hi Bill,
>>>
>>> Bill Joy wrote:
>>>> Since you are going to add a check if the service is connected before
>>>> doing the service info request, why can't you check if there is a
>>>> registered listener for that service type before doing that call too?
>>> We could/might, but I don't believe this would really fix the problem,
>>> as it still would be possible to issue the request (connected), then
>>> disconnect, and then have the jmdns thread make the callback and fail as
>>> below.
>>>
>>> But I'm willing to make the connect check anyway, to reduce the
>>> likelihood.
>>>
>>> Scott
>>>
>>>
>>>
>>>>
>>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>>> news:4831ACCE.8020700@composent.com...
>>>>> Hi Bill,
>>>>>
>>>>> Bill Joy wrote:
>>>>>> In ECF 1.2.0 and prior versions, I would add myself as a service
>>>>>> listener for my type of service, then request service info for it
>>>>>> when receiving the serviceAdded() event.
>>>>>>
>>>>>> In ECF 2.0.0, there is no longer an exposed serviceAdded() and the
>>>>>> container makes the request service info call. In fact, it makes a
>>>>>> request for every service which is reported.
>>>>>>
>>>>>> Since my network has dozens of different services running, I am
>>>>>> seeing the container going through a lot of unnecessary overhead and
>>>>>> causing extra network traffic.
>>>>>>
>>>>>> What is the purpose of resolving services when there are no
>>>>>> registered listeners for that information?
>>>>> The main reason was simplification of the discovery API. Especially
>>>>> in moving the API to support other providers (e.g. jSLP, which is now
>>>>> in there), it became apparent that the zeroconf model of having a two
>>>>> step resolution process (i.e. get notification of service existence,
>>>>> and then resolving manually) did not generalize well/easily to other
>>>>> providers...and it adds a level of complexity in the use of the API as
>>>>> well.
>>>>>
>>>>> Yes, for the zeroconf provider the cost of this is additional network
>>>>> traffic.
>>>>>
>>>>>
>>>>>> I am seeing the following exception if there is a disconnect done
>>>>>> before resolution of all those services is complete:
>>>>>>
>>>>>> java.lang.IllegalStateException: Timer already cancelled.
>>>>>> at java.util.Timer.sched(Timer.java:354)
>>>>>> at java.util.Timer.schedule(Timer.java:222)
>>>>>> at javax.jmdns.JmDNS$ServiceInfoResolver.start(JmDNS.java:2100)
>>>>>> at javax.jmdns.JmDNS.requestServiceInfo(JmDNS.java:452)
>>>>>> at
>>>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$3.run(JMDNSDiscoveryContainer.java:326)
>>>>>> at
>>>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$1.run(JMDNSDiscoveryContainer.java:117)
>>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>>>
>>>>>> So I expect the Runnable doing the resolution request call should be
>>>>>> checking if the service is still connected before issuing it.
>>>>> I have seen this as well. I believe it would qualify as a JmDNS bug,
>>>>> as the Thread running this code is created/started within JmDNS.
>>>>>
>>>>> But if you would be kind enough to file an ECF bug on this as well we
>>>>> will do our best to address it.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Scott
>>
|
|
|
| Re: JmDNS discovery issue [message #623587 is a reply to message #623586] |
Mon, 19 May 2008 20:56 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Bill,
I was doing something wrong. I'm now seeing the removes from iTunes
come through just fine.
Thanks,
Scott
Bill Joy wrote:
> Could be that you are just not waiting long enough for the timeout
> processing when services just silently drop off the network? I seem to
> recall a timeout interval of something like 20-30 minutes.
>
> My plugin is part of a custom P2P implementation where the user is given UI
> to connect/disconnect.
>
> I can reproduce the problem even when there are no peers on the network just
> by connecting then disconnecting.
>
> You probably should be able to reproduce by using JBuilder 2008 on the same
> LAN.
>
> http://cc.codegear.com/free/jbuilder
>
> The P2P feature is available in the Turbo version.
>
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:4831C099.1000907@composent.com...
>> Hi Bill,
>>
>>
>> Bill Joy wrote:
>>> If I understand your reply, that is not what I was suggesting.
>>>
>>> In the old design, I would register as a listener for my service type
>>> then request the service info when I was told the service was added.
>>>
>>> Since you don't want that two step process, have the container ask for
>>> the service info on service added only because I had previously
>>> registered as a listener for that service type. No request for service
>>> info would be sent unless there is a registered listener for the result.
>>>
>>> This is a return to the old behavior despite the simplified API.
>>
>> I see. OK, please create a bug and I will modify appropriately.
>>
>> BTW, what apps/services are you registering/unregistering that end up
>> returning null from JMDNS ServiceEvent.getInfo() (i.e. and showing the NPE
>> from Re: NullPointerException in AbstractDiscoveryContainerAdapter)? I've
>> been testing with iTunes, trying to test out a fix, but it doesn't seem to
>> invoke serviceRemoved (on exit or deactivation).
>>
>> Thanks,
>>
>> Scott
>>
>>
>>>
>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>> news:4831B692.1080902@composent.com...
>>>> Hi Bill,
>>>>
>>>> Bill Joy wrote:
>>>>> Since you are going to add a check if the service is connected before
>>>>> doing the service info request, why can't you check if there is a
>>>>> registered listener for that service type before doing that call too?
>>>> We could/might, but I don't believe this would really fix the problem,
>>>> as it still would be possible to issue the request (connected), then
>>>> disconnect, and then have the jmdns thread make the callback and fail as
>>>> below.
>>>>
>>>> But I'm willing to make the connect check anyway, to reduce the
>>>> likelihood.
>>>>
>>>> Scott
>>>>
>>>>
>>>>
>>>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>>>> news:4831ACCE.8020700@composent.com...
>>>>>> Hi Bill,
>>>>>>
>>>>>> Bill Joy wrote:
>>>>>>> In ECF 1.2.0 and prior versions, I would add myself as a service
>>>>>>> listener for my type of service, then request service info for it
>>>>>>> when receiving the serviceAdded() event.
>>>>>>>
>>>>>>> In ECF 2.0.0, there is no longer an exposed serviceAdded() and the
>>>>>>> container makes the request service info call. In fact, it makes a
>>>>>>> request for every service which is reported.
>>>>>>>
>>>>>>> Since my network has dozens of different services running, I am
>>>>>>> seeing the container going through a lot of unnecessary overhead and
>>>>>>> causing extra network traffic.
>>>>>>>
>>>>>>> What is the purpose of resolving services when there are no
>>>>>>> registered listeners for that information?
>>>>>> The main reason was simplification of the discovery API. Especially
>>>>>> in moving the API to support other providers (e.g. jSLP, which is now
>>>>>> in there), it became apparent that the zeroconf model of having a two
>>>>>> step resolution process (i.e. get notification of service existence,
>>>>>> and then resolving manually) did not generalize well/easily to other
>>>>>> providers...and it adds a level of complexity in the use of the API as
>>>>>> well.
>>>>>>
>>>>>> Yes, for the zeroconf provider the cost of this is additional network
>>>>>> traffic.
>>>>>>
>>>>>>
>>>>>>> I am seeing the following exception if there is a disconnect done
>>>>>>> before resolution of all those services is complete:
>>>>>>>
>>>>>>> java.lang.IllegalStateException: Timer already cancelled.
>>>>>>> at java.util.Timer.sched(Timer.java:354)
>>>>>>> at java.util.Timer.schedule(Timer.java:222)
>>>>>>> at javax.jmdns.JmDNS$ServiceInfoResolver.start(JmDNS.java:2100)
>>>>>>> at javax.jmdns.JmDNS.requestServiceInfo(JmDNS.java:452)
>>>>>>> at
>>>>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$3.run(JMDNSDiscoveryContainer.java:326)
>>>>>>> at
>>>>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$1.run(JMDNSDiscoveryContainer.java:117)
>>>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>>>>
>>>>>>> So I expect the Runnable doing the resolution request call should be
>>>>>>> checking if the service is still connected before issuing it.
>>>>>> I have seen this as well. I believe it would qualify as a JmDNS bug,
>>>>>> as the Thread running this code is created/started within JmDNS.
>>>>>>
>>>>>> But if you would be kind enough to file an ECF bug on this as well we
>>>>>> will do our best to address it.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Scott
>
>
|
|
|
| Re: JmDNS discovery issue [message #623588 is a reply to message #623587] |
Mon, 19 May 2008 21:00 |
Bill Joy
Messages: 60
Registered: July 2009 |
Member |
|
|
I pulled in your source changes for the bugs you asked me to enter and they
worked fine -- thanks!
https://bugs.eclipse.org/bugs/show_bug.cgi?id=232835
https://bugs.eclipse.org/bugs/show_bug.cgi?id=232842
"Scott Lewis" <slewis@composent.com> wrote in message
news:4831E973.3080901@composent.com...
> Hi Bill,
>
> I was doing something wrong. I'm now seeing the removes from iTunes come
> through just fine.
>
> Thanks,
>
> Scott
>
>
> Bill Joy wrote:
>> Could be that you are just not waiting long enough for the timeout
>> processing when services just silently drop off the network? I seem to
>> recall a timeout interval of something like 20-30 minutes.
>>
>> My plugin is part of a custom P2P implementation where the user is given
>> UI to connect/disconnect.
>>
>> I can reproduce the problem even when there are no peers on the network
>> just by connecting then disconnecting.
>>
>> You probably should be able to reproduce by using JBuilder 2008 on the
>> same LAN.
>>
>> http://cc.codegear.com/free/jbuilder
>>
>> The P2P feature is available in the Turbo version.
>>
>>
>> "Scott Lewis" <slewis@composent.com> wrote in message
>> news:4831C099.1000907@composent.com...
>>> Hi Bill,
>>>
>>>
>>> Bill Joy wrote:
>>>> If I understand your reply, that is not what I was suggesting.
>>>>
>>>> In the old design, I would register as a listener for my service type
>>>> then request the service info when I was told the service was added.
>>>>
>>>> Since you don't want that two step process, have the container ask for
>>>> the service info on service added only because I had previously
>>>> registered as a listener for that service type. No request for service
>>>> info would be sent unless there is a registered listener for the
>>>> result.
>>>>
>>>> This is a return to the old behavior despite the simplified API.
>>>
>>> I see. OK, please create a bug and I will modify appropriately.
>>>
>>> BTW, what apps/services are you registering/unregistering that end up
>>> returning null from JMDNS ServiceEvent.getInfo() (i.e. and showing the
>>> NPE from Re: NullPointerException in AbstractDiscoveryContainerAdapter)?
>>> I've been testing with iTunes, trying to test out a fix, but it doesn't
>>> seem to invoke serviceRemoved (on exit or deactivation).
>>>
>>> Thanks,
>>>
>>> Scott
>>>
>>>
>>>>
>>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>>> news:4831B692.1080902@composent.com...
>>>>> Hi Bill,
>>>>>
>>>>> Bill Joy wrote:
>>>>>> Since you are going to add a check if the service is connected before
>>>>>> doing the service info request, why can't you check if there is a
>>>>>> registered listener for that service type before doing that call too?
>>>>> We could/might, but I don't believe this would really fix the problem,
>>>>> as it still would be possible to issue the request (connected), then
>>>>> disconnect, and then have the jmdns thread make the callback and fail
>>>>> as below.
>>>>>
>>>>> But I'm willing to make the connect check anyway, to reduce the
>>>>> likelihood.
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>>
>>>>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>>>>> news:4831ACCE.8020700@composent.com...
>>>>>>> Hi Bill,
>>>>>>>
>>>>>>> Bill Joy wrote:
>>>>>>>> In ECF 1.2.0 and prior versions, I would add myself as a service
>>>>>>>> listener for my type of service, then request service info for it
>>>>>>>> when receiving the serviceAdded() event.
>>>>>>>>
>>>>>>>> In ECF 2.0.0, there is no longer an exposed serviceAdded() and the
>>>>>>>> container makes the request service info call. In fact, it makes a
>>>>>>>> request for every service which is reported.
>>>>>>>>
>>>>>>>> Since my network has dozens of different services running, I am
>>>>>>>> seeing the container going through a lot of unnecessary overhead
>>>>>>>> and causing extra network traffic.
>>>>>>>>
>>>>>>>> What is the purpose of resolving services when there are no
>>>>>>>> registered listeners for that information?
>>>>>>> The main reason was simplification of the discovery API. Especially
>>>>>>> in moving the API to support other providers (e.g. jSLP, which is
>>>>>>> now in there), it became apparent that the zeroconf model of having
>>>>>>> a two step resolution process (i.e. get notification of service
>>>>>>> existence, and then resolving manually) did not generalize
>>>>>>> well/easily to other providers...and it adds a level of complexity
>>>>>>> in the use of the API as well.
>>>>>>>
>>>>>>> Yes, for the zeroconf provider the cost of this is additional
>>>>>>> network traffic.
>>>>>>>
>>>>>>>
>>>>>>>> I am seeing the following exception if there is a disconnect done
>>>>>>>> before resolution of all those services is complete:
>>>>>>>>
>>>>>>>> java.lang.IllegalStateException: Timer already cancelled.
>>>>>>>> at java.util.Timer.sched(Timer.java:354)
>>>>>>>> at java.util.Timer.schedule(Timer.java:222)
>>>>>>>> at javax.jmdns.JmDNS$ServiceInfoResolver.start(JmDNS.java:2100)
>>>>>>>> at javax.jmdns.JmDNS.requestServiceInfo(JmDNS.java:452)
>>>>>>>> at
>>>>>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$3.run(JMDNSDiscoveryContainer.java:326)
>>>>>>>> at
>>>>>>>> org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryConta iner$1.run(JMDNSDiscoveryContainer.java:117)
>>>>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>>>>>
>>>>>>>> So I expect the Runnable doing the resolution request call should
>>>>>>>> be checking if the service is still connected before issuing it.
>>>>>>> I have seen this as well. I believe it would qualify as a JmDNS
>>>>>>> bug, as the Thread running this code is created/started within
>>>>>>> JmDNS.
>>>>>>>
>>>>>>> But if you would be kind enough to file an ECF bug on this as well
>>>>>>> we will do our best to address it.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Scott
>>
|
|
|
| |
  |
Goto Forum:
Current Time: Wed Apr 24 18:14:58 GMT 2024
Powered by FUDForum. Page generated in 0.03628 seconds |
] 
Search
Help
Register
Login
Home
