Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] connection problem betwenn ecf 3.14.18 and 3.14.26
  • From: Peter Hermsdorf <peter.hermsdorf@xxxxxxxxx>
  • Date: Tue, 4 Jan 2022 16:01:01 +0100
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lugwI23TPthXY0+A1gfqsV1DDnvIHJLUieGqqG+Fe2o=; b=iMSqcXmbjWsWNmZH0XFcQl/+JLQFDfH9vHPH8RpyMW+6nsIK3anpehSzWtm/y0GyIjr33JOLdNBnxsywUk13q3b3uUTsoksvqdXQk3M91xlo3DCP8Nr2y4h1k/fG2PS8Jld7avVJvRW28CSWXQCjj/ENvX3l6p2m7mNBmnN4BetsJ7mTLcuyOSSiRtzHeAoi6o+wP735m9ydfJvlaEjB5vSYN/YNdN3rJ1Uq81GLIdG/PHa3YzSqg+5Qir1KpLP4pvsfdtjLrwye7wOn06qFpvsnPh8WxvMZVkVE+r+CClYkCsStplzVO/na0TZ5UMgp5jL1F9g7ahy5elEIbK8ugA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=hliS8CUXkndtakwLRcYzfP9fbDkyDF/JavPzlHS9DfwTeNimqXThADU4Y6ZzkhDPskW+Co3ADColAGw/mBIlqIU8of608X1O5WrzbbwvaFeIiJsf+zU8UbhHvltMWV3xMxHSi1cTMigmwbfDIG6a6p09WQRz7e7e834FcOUPqZOqxIeZ9+H4kU+cw6BH9bUr5MkVOh8EPaFCW4MTEGCNipyqUD21hQdefHyrsCP39sF7nHwC15KVtfMT+B1HXOd0AyaSaSI92v4ZRWM0wvzq+jxh1/AgmxsxmFr8Xw/rfSH1A+yPlM8S0pEZkTydWDkEHZXIIl7iT/+qSS7WCFnVBw==
  • Delivered-to: ecf-dev@xxxxxxxxxxx
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

Hi Scott,

sorry for being late with my reply.

Currently an update to a newer ECF and Eclipse version is not possible. That leads to a lot of compatibility problems and effort to manage everyone is using the matching clients e.g. in support scenarios with our customers which stay for some time on older versions.

A fallback mechanism in this case would be great to switch ECF versions at runtime to make it backward compatible but that is probably a project on it's own ...

In the end it was possible to use the "old" ECF implementation even with a 2021-21 eclipse target platform. For now that resolves the problem until an update is possible.

Thanks for your hints!

Best wishes,


Am 22.12.21 um 22:54 schrieb Scott Lewis:
Hi Peter,

My insight into this is that during that time (i.e. after 2020-12) I had to mess around with the generic providers serialization and classloading (for serialization).   The reason this was necessary is to allow ECF to be the default implementation for the OSGi Remote Services TCK (test compatibility kit).

What I believe to be happening is that the (old) server may not be able to deserialize a class and therefore disconnects unexpectedly...making the subsequent calls (or imports) fail.

I would suggest trying to update the old server to the same version of ECF (3.14.36) if at all possible.   Alternatively, I *believe* that 3.14.18 should be able to run on most recent Eclipse, but honestly I haven't tested that.  I don't know of any obvious reason it shouldn't work (as long as using Java 11 or parts of Eclipse require java 11.

My apologies if this is an inconvenience.  If you can't update to 3.14.26 or use 3.14.18 let me know and I'll see what else might help (e.g. replacing just that bundle).


On 12/21/2021 5:08 AM, Peter Hermsdorf wrote:

we needed to upgrade one part of our system to a newer eclipse release (2021-12). The other part is still using eclipse 2020-12 as target.

We use the generic server setup and now see the following exception when the "newer" client want's to import/connect services from the "older" server:

ERROR [framework] org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.provider.remoteservice;code=212;message=Exception sending registry update request/2 message;severity4; Container not connected;children=[]] Container not connected
    at org.eclipse.ecf.provider.generic.ClientSOContainer.checkConnected(
    at org.eclipse.ecf.provider.generic.ClientSOContainer.sendMessage(
    at org.eclipse.ecf.provider.generic.SOContext.sendMessage(
    at org.eclipse.ecf.core.sharedobject.BaseSharedObject.sendSharedObjectMsgTo(
    at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.sendRegistryUpdateRequest(
    at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.sendRegistryUpdateRequestAndWait(
    at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.addReferencesFromRemoteRegistrys(
    at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.getRemoteServiceReferences(
    at java.base/ Method)
    at com.godyo.p5.util.remoting.internal.RemoteServiceRegistration.importService(
    at com.godyo.p5.util.remoting.internal.RemoteServiceRegistration.lambda$6(
    at java.base/java.util.concurrent.Executors$
    at java.base/
    at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
    at java.base/java.util.concurrent.ThreadPoolExecutor$
    at java.base/

java versions are the same. the endpoint definitions seem to match and are unchanged.

When debugging i see that at first the connection seems to be successful (org.eclipse.ecf.provider.generic.ClientSOContainer.setStateConnected) is called, but short after that i see that org.eclipse.ecf.provider.generic.ClientSOContainer.setStateDisconnected is called.

The reason is not obvious. On server side no exceptions happen. That would also be a problem for a smooth migration/update process.

Any idea what the problem could be?

Thanks and best wishes,


Back to the top