[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] connections/threads are not cleaned up after failing importService call
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Fri, 15 Sep 2017 20:03:14 -0700
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
I'm assuming that you are using the generic provider.
I think you can do what you need to do by:
1) You can cast the ImportRegistration to
to get the container ID
3) Using the IContainerManager service (a singleton ecf service) and the
ID from 2 call:ÂÂ IContainer c = containerManager.getContainer(id) to
get the associated container instance.
4) Call c.disconnect() to release the connection and associated threads.
On 9/15/2017 7:27 AM, Peter Hermsdorf wrote:
we encountered a problem while trying to import services exported from
a process running in a local VM (_not_ JVM). The VM forwards the
necessary port to the host machine.
As for the problem: RemoteAdminService#importService causes a
RemoteAdminServiceEvent.IMPORT_ERROR to be signalled and the
connections/threads opened due to the importService call do not get
closed, even though we call ImportRegistration#close() on failed
attempts. The latter does not happen, if there is no one listening on
the port at all. Since, we have code that regularly calls
importService again for services, that should be, but are not
currently imported (according to
RemoteAdminService#getImportedEndpoints), we slowly accumulate more
and more threads.
The tcp connection to the local VM seems to be successful, but due to
issues regarding requested hostname and actual hostname ECF
(correctly) does not "connect the services" (see
https://dev.eclipse.org/mhonarc/lists//ecf-dev/msg07259.html for a
discussion of the "hostname problem - localhost !=
getCanonicalHostname()" in EndPointDescriptions; in this case it is
host::getCanonicalHostname() != VM::getCanonicalHostname())
So importService creates threads/connections, fails to import, and
even with a call to ImportRegistration#close() does not clean up the
Any suggestions on how to solve this issue or more generally handle
this reconnect use-case are more than welcome!
PS: we use the ecf generic provider on the latest ecf release
ecf-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit