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>