Hi Scott
Could you please provide me the link from where i can take your
changes and test.I could not find the latest build
from http://www.eclipse.org/ecf/dailies32.php and
also http://download.eclipse.org/rt/ecf/3.5dailies3.2-repo/site.p2/ i
am not able to access.
Thanks and Regards
Abhisek
On Wed, May 19, 2010 at 9:22 AM, abhisek saikia <agscontact@xxxxxxxxx
<mailto:agscontact@xxxxxxxxx>> wrote:
wow...so fast....Sure...i will test now
On Wed, May 19, 2010 at 5:02 AM, Scott Lewis <slewis@xxxxxxxxxxxxx
<mailto: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>
<mailto: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>>
<mailto: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>
<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>
<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>
<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>>>
<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,
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>>>>
<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
<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>>>>
<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
<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>>>
<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>>>
<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
