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
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>> 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>
    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