[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: {Disarmed} Re: [ecf-dev] avoid broadcast
|
Hi Scott
Thanks a lot for your response.I completely agree with you for different behaviour of discovery service.
1) Actually I am confused with why in consumer I am getting same remote reference add event thrice with different service id.I feel its a bug.
Please correct me if i am wrong(this is not happening in case of jmdns)
2)So as per the behavior of file discovery,if my consumer starts first and my host next,my host services will never be discovered by the consumer.
Do you mean to handle this i have to make a code dependent on the discovery api?
Please correct me if i am wrong .
Thanks and Regards
Abhisek
On Sat, May 22, 2010 at 11:39 PM, Scott Lewis
<slewis@xxxxxxxxxxxxx> wrote:
Hi Abhisek,
abhisek saikia wrote:
Hi Mrakus
Today i tested with the nightly build ,hello sample using file discovery and ecf generic.
I am facing the below issue
1)In my consumer i am geting 3 service reference with different service ids for the same remote interface.in <http://interface.in> ServiceTrackerCustomizer.addService
2) if host is not started consumer tries to connect 3 times and then never tries again.Is there any reconnect slot or time limit for retry?
No. If you wish, you can put in your own logic to retry via the file-based discovery if this behavior is needed/desired. FYI, there is new API for doing so...see bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=305073
You can/should probably also consult: http://wiki.eclipse.org/File-based_Discovery
Just a comment: one truth about the discovery portion of OSG remote services is that there are a lot of different use cases for discovery...i.e. to deal with different deployment network configurations, different security requirements, etc., etc. No one discovery solution will fit all these different use cases. That's why ECF's approach of being able to use different discovery providers (zeroconf, slp, zookeeper, dnssd, file-based discovery, custom providers, etc) is so powerful/useful...because it allows the same mechanisms for distribution and OSGi remote services standards compliance to be used with different discovery approaches, configurations, and mechanisms. But to choose, it's necessary to understand/specify the use cases and deployment environments...since no one discovery mechanism will meet all remote service use cases.
Scott
