Skip to main content

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

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, osgi.remote.service.interfaces=org.eclipse.ecf.examples.remoteservices.hello.IHello, ecf.sp.cns=org.eclipse.ecf.core.identity.StringID, 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=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>> 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>>>
        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>>

           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



Back to the top