Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] multiple service call
Thanks a lot Scott

On Wed, May 19, 2010 at 2:55 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Abhisek,

Thanks.  I believe this is because the discovery locator cache on the consumer is not being purged upon ungraceful shutdown of remote provider.   So when the service host startups up the second time, the consumer discovery thinks it's already there...and doesn't notify.

I've opened this bug to track:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=313445

Scott

abhisek saikia wrote:
Hi Scott

 Thanks for your response.
 I am using jmdns discovery and ECF generic
 Yes,on termination of host,in the consumer side i am geting the event removedService(ServiceReference arg0, Object proxy)  of ServiceTrackerCustomizer .but after that if i start the host equinox,consumer is not able to receive any event of addingService(ServiceReference reference) of the ServiceTrackerCustomizer.
 If i use close osgi console command,consumer is able to receive  addingService event once the host started again.
   Thanks an Regards
  Abhisek

On Wed, May 19, 2010 at 1:58 AM, Scott Lewis <slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>> wrote:

   Hi Abhisek,

   abhisek saikia wrote:

       Hi Scott

         Today i tried with ECF
       org.eclipse.ecf.sdk_3.3.0.v20100518-1435 from head.It has the
       fix for this issue.I tested my use case for multiple service
       call.Its working fine.
          But the other issue is still there(abrupt termination of
       provider).
         This issue can be reproduced with any ECF generic sample. I
       also have attached the sample which i tried
        Steps to reproduce:
           1.start consumer equinox
           2.start provider equinox
           3.let the service calls happen
           4.terminate provider equinox using kill -9(if using unix
       environment)  or kill from task manager(windows) or press
       terminate button(if launching from eclipse)


   Ok.  So I would like to work through this case a little bit with
   you...understand what you are seeing...and we'll open a bug and
   address it if necessary.

   First please verify these assumptions:

   a) Using zeroconf/jmdns for discovery
   b) Using ECF generic for distribution
   c) You are using 'provider' rather than 'host' for terminology (I
   know that OSGi remote services spec uses 'provider' but I/we don't
   use that because we also have the concept of a 'provider',
   separate from the remote services role...i.e. host and consumer.

   Here's my assumptions about what is happening (please
   verify/clarify):  you start the consumer first (1), and then the
   host (2).  The remote service is registered by host, and published
   via jmdns discovery provider.  The consumer discovers the remote
   service, creates a proxy, and the consumer's
   ServiceTrackerCustomizer.addingService method is called. In the
   consumer example code this results in several remote service calls
   (i.e. via the proxy, as well as via async/Future and
   async/Callback.  These calls complete successfully.

   At this point, the host is terminated.  What happens then on the
   consumer for you?  On my tests, if I terminate the host via
   Eclipse (i.e. the red stop button), I immediately see the
   following output on my consumer console:

   IHello Service proxy removed
   [log;-0700 2010.05.18
   13:04:13:273;INFO;org.eclipse.ecf.osgi.services.distribution;OSGi
   ECF service distribution: unregistered
        endpointDescription=RemoteServiceEndpointDescriptionImpl[svcInterfaces=[org.eclipse.ecf.examples.remoteservices.hello.IHello];supportedConfigTypes=[ecf.generic.server];serviceIntents=null;location=null;remoteServiceId=0;discoveryServiceID=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.default._iana];location=osgiservices://192.168.1.102:3787/svc_0;full=_osgiservices._tcp.default._iana@osgiservices://192.168.1.102:3787/svc_0];endpointID=null;endpointAsID=StringID[ecftcp://localhost:3787/server];connectTargetID=null;remoteServicesFilter=null;props={ecf.rsvc.ns=ecf.namespace.generic.remoteservice
   <http://192.168.1.102:3787/svc_0;full=_osgiservices._tcp.default._iana@osgiservices://192.168.1.102:3787/svc_0%5D%3BendpointID%3Dnull%3BendpointAsID%3DStringID%5Becftcp://localhost:3787/server%5D;connectTargetID=null;remoteServicesFilter=null;props=%7Becf.rsvc.ns=ecf.namespace.generic.remoteservice>,

   osgi.remote.service.interfaces=org.eclipse.ecf.examples.remoteservices.hello.IHello,
   ecf.sp.cns=org.eclipse.ecf.core.identity.StringID, ecf.rsvc.id
   <http://ecf.rsvc.id>=[B@c3e967, ecf.sp.ect=ecf.generic.server,

   ecf.sp.cid=[B@1079ff}]
     proxyServiceRegistration=
   {org.eclipse.ecf.examples.remoteservices.hello.IHello}={service.imported=org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceImpl@1cb374f,
   service.imported.configs=[ecf.generic.client], service.id
   <http://service.id>=52}

   ]

   The first line 'IHello Service proxy removed' indicates that the
   remote service registration *is* getting cleaned up when the
   connect with the remote host is terminated...this is some comment
   code that I added to the ServiceTrackerCustomizer.removedService
   method (which is called when the appropriate service is removed).
   The log message confirms (via the IProxyDistributionListener) that
   the remote service proxy registration was removed.

   This is basically as it should be...as the remote service proxy is
   being cleaned up.  Notice, however, that there is no undiscovery
   event received on the consumer.  That's because with zeroconf,
   since the host was terminated abnormally, the host was not able to
   send out an zeroconf 'unpublish' to the consumer.  The ECF generic
   provider *did* get the socket close, and this was/is used to do
   the proxy remove clean up...but the discovery mechanism still has
   the remote service in it's cache.

   So, in fact, zeroconf still believes the remote services is out
   there.  Zeroconf has what's called a 'time to live' for the
   multicast message...and until that expires the remote osgi service
   information will be present.

   But my question is...assuming you are seeing the same thing as
   above...what do you do now?...and what is the result?...and how
   does this result differ from what you are expecting to happen?

   Thanks.  With your further assistance I think this should be easy
   to identify and fix.

   Scott

       And about container connect,which spring is using might not be
       an issue with ECF,may be in spring code we need to handle in
       such a way that we connect only after remote service has been
       discovered.May be angelo can provide more clarification on it.

       In the present version i faced only one issue which i have
       mentioned.

       Thanks and Regards

       Abhisek

       On Tue, May 18, 2010 at 12:42 AM, Scott Lewis
       <slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>
       <mailto:slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>>>
       wrote:

          Hi Abhisek,

          abhisek saikia wrote:

              Hi Scott

                   Existing or new container both are ok for me.For
       me just
              the service call should be successful which i guess
       should be
              the major specification of ECF :).I am currently not going
              with container.connect option with multiple containers
       as it
              had the defect for which client(consumer) needs to be
       started
              first ,Also been reproduced by angelo @
                     http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg03635.html  
          Could you and/or Angelo please open a bug about this
       issue?...and
          include the explanation from Angelo in the bug description?
             Also, please address this question on the bug:

          On the consumer, if the spring framework is creating a
       container,
          and connecting to a targetId with code like this (the
       following is
          copied from Angelo's mailing list post):

          protected IContainer createContainer() throws
          ContainerCreateException,
                    ContainerConnectException {
                IContainer container = super.createBasicContainer();
                if (targetId != null) {
                    container.connect(targetId, connectContext);
                }
                return container;
            }

          Whenever this code is executed (e.g. upon startup), then
       this logic:

                if (targetId != null) {
                    container.connect(targetId, connectContext);
                }

          *will* synchronously attempt to connect to the service
       host...and
          if the service host is not yet started (whether localhost
       or some
          other process) you will get a a connect exception...e.g.
       like he got:

          Caused by: org.eclipse.ecf.core.ContainerConnectException:
          Exception during connection to ecftcp://localhost:3787/server
          <stack trace deleted>
            ... 17 more
          Caused by: java.net.ConnectException: Connection refused:
       connect

          This means simply that the spring initialization code is
       trying to
          connect directly to a given host container (i.e. targetId), and
          that container hasn't had a chance to startup, register the
       remote
          service, and then publish the remote service for discovery
       by the
          consumer.  In other words, the consumer framework startup is
          racing against the startup/initialization of the host.

          One way to avoid the need to explicitly call
          container.connect(targetId, connectContext) at *all* is to
       (on the
          consumer) wait until the remote service is discovered via
          discovery...and only *then* have the container connect to the
          target container.  The logic for doing so (i.e. connect to the
          target container) is already present in the
          DefaultProxyContainerFinder, and the equivalent to targetId is
          already included in the metadata available via discovery.   One
          major change in DefaultProxyContainerFinder *since* the
       release of
          ECF 3.2 was represented by this bug:

          https://bugs.eclipse.org/bugs/show_bug.cgi?id=303979

          This makes it unnecessary to even create a proxy container in
          advance of the service discovery, as after this bug was
       addressed
          a container will be automatically created (if one doesn't
       already
          exist) for dealing with incoming remote services being
       discovered.
           In other words, I believe that with the most recent code from
          HEAD it should be unnecessary for the spring framework bean
       to be
          created on the consumer side at all.  Both the container
       creation
          and the connection can/could all be done lazily...at remote
          service discovery time instead of eagerly (at spring bean
       creation
          time).

          But I'm probably misunderstanding something about your/Angelo's
          use case.   So let's please move this to a new bug,
       however, and
          we can discuss further/diagnose/etc on that new bug.

          Thanks,

          Scott


               Anyway as per your suggestion i will try with the
       unreleased
              code chunk of ECF .

              Thanks and Regards

              Abhisek

              On Mon, May 17, 2010 at 11:33 PM, Scott Lewis
              <slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>
       <mailto:slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>>
              <mailto:slewis@xxxxxxxxxxxxx
       <mailto:slewis@xxxxxxxxxxxxx> <mailto:slewis@xxxxxxxxxxxxx
       <mailto:slewis@xxxxxxxxxxxxx>>>>

              wrote:

                 Hi Abhisek,

                 You seem to be using ECF 3.2 release version
       (Release date:
               Feb
                 19, 2010).  There have been a number of bugs fixed since
                 then...one of which having to do with a problem of
       not properly
                 publishing the same service multiple times.  For
       testing, bug
                 identification, etc I would urge you to get the
       latest from
              HEAD,
                 as we are in the testing phase for ECF 3.3/Helios
       release right
                 now...and so it would be most helpful to get some
              assistance from
                 the community with testing ECF 3.3/Helios for your
       specific use
                 cases.  If you need instructions for how to get the
       lastest
              from
                 HEAD in your workspace please let me know...and/or
       see section
                 'Anonymous CVS Access to ECF Source Code':
                  http://www.eclipse.org/ecf/dev_resources.php

                 abhisek saikia wrote:


                     Hi Scott
                        I used
       org.eclipse.ecf.sdk_3.2.0.v20100219-1253.zip
                                   <http://www.eclipse.org/downloads/download.php?file=/rt/ecf/3.2/3.6/org.eclipse.ecf.sdk_3.2.0.v20100219-1253.zip>
                         My issue is a bit different.I have 2
       providers(in 2
                     different machines) and one  consumer in another
              machine.The
                     providers implement the same Interface.I am
       using Service
                     tracker in consumer side.I am able to receive
       only one
              remote
                     reference.While debugging ECF code i found if a
              container is
                     already connected(i.e it already discovered
       provider in
                     machine 1),it cant find the remote service
       reference from
                     machine 2(as the code has a check for
              isContainerConnect which
                     is true while remotelocation becomes machine2,
       as its
              already
                     connected to provider of machine 1) .


                 A couple of things.  First...since 3.2 there has
       been some
                 improvement/change of the logic in
              DefaultProxyContainerFinder wrt
                 handling of multiple remote services.

                 Second...it is possible that this represents a
       bug/problem
              in the
                 DefaultProxyContainerFinder for handling your use case.

                 Third...it's also possible that for your use case
       there is an
                 ambiguity about what you want to happen on the
       multiple-service
                 consumer...i.e. do you want the *existing* proxy
       container
              to be
                 used, or do you want a *new* container to be
              created/connected for
                 this remote service?  There are some facilities already
              present in
                 ECF to support some of these use cases, so it may be a
              matter of
                 figuring out what you wish to happen and then using
       those
              facilities.

                 So...I recommend that you get the latest code from HEAD,
              and try
                 this same use case again.  If it still has problems
       then lets
                 identify them, and we'll address those problems
       and/or needed
                 generalization to handle your use case.


                 Thanks,

                 Scott


                 _______________________________________________
                 ecf-dev mailing list
                 ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
       <mailto:ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>>
              <mailto:ecf-dev@xxxxxxxxxxx
       <mailto:ecf-dev@xxxxxxxxxxx> <mailto:ecf-dev@xxxxxxxxxxx
       <mailto:ecf-dev@xxxxxxxxxxx>>>


                 https://dev.eclipse.org/mailman/listinfo/ecf-dev


                     ------------------------------------------------------------------------



              _______________________________________________
              ecf-dev mailing list
              ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
       <mailto:ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>>
              https://dev.eclipse.org/mailman/listinfo/ecf-dev
             
          _______________________________________________
          ecf-dev mailing list
          ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
       <mailto:ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>>
          https://dev.eclipse.org/mailman/listinfo/ecf-dev


       ------------------------------------------------------------------------

       _______________________________________________
       ecf-dev mailing list
       ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
       https://dev.eclipse.org/mailman/listinfo/ecf-dev


   _______________________________________________
   ecf-dev mailing list
   ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
   https://dev.eclipse.org/mailman/listinfo/ecf-dev


------------------------------------------------------------------------

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
 

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top