Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] multiple service call

wow...so fast....Sure...i will test now

On Wed, May 19, 2010 at 5:02 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Fix has been released to https://bugs.eclipse.org/bugs/show_bug.cgi?id=313445

I would appreciate testing in your environment Abhisek to verify that it now works for your use case.

Thanks,

Scott

abhisek saikia wrote:
Thanks a lot Scott


On Wed, May 19, 2010 at 2:55 AM, Scott Lewis <slewis@xxxxxxxxxxxxx <mailto: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>
       <mailto: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>
                 <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>
          <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>
          <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>>
              <mailto: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>>>
                     <mailto: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>>>
                     <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 <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>>
              <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>>
              <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