[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] connections/threads are not cleaned up after failing importService call

Hi Peter,

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 org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.ImportRegistration
2) Call org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.ImportRegistration.getContainerID() 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 threads/connections.

Any suggestions on how to solve this issue or more generally handle this reconnect use-case are more than welcome!

Best regards,

Bye Peter

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