Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Problem using multiple services from single server

Hi,

my switch to Eclipse 3.8 (Juno) and with that to ECF 3.9.3 was so far successful. That means after fiddling around with dependencies, launch configs and feature configuration i have a running server and a running RCP app with working _multiple_ service discovery - as expected! great!

:) so far so good. I still need to fix the build and test suites but that seems possible till now.

current open points:
1) on client side i still see the following error for every service imported:

!ENTRY org.eclipse.ecf.osgi.services.remoteserviceadmin 4 0 2015-03-12 10:58:40.889
!MESSAGE org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.osgi.services.remoteserviceadmin;code=4;message=org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:postEvent:No EventAdmin service available to send eventTopic=org/osgi/service/remoteserviceadmin/IMPORT_REGISTRATION eventProperties={event=RemoteServiceAdminEvent[containerID=StringID[ecftcp://peter-desktop:8889/server], getType()=1, getSource()=org.eclipse.ecf.osgi.services.remoteserviceadmin_4.2.0.v20150306-2024 [91], getException()=null, getImportReference()=org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$ImportReference@1276b35, getExportReference()=null], bundle.id=91, objectClass=[Ljava.lang.String;@ef769a, timestamp=1426154320883, endpoint.id=ecftcp://peter-desktop:8889/server, service.imported.configs=[Ljava.lang.String;@153b262, bundle.symbolicname=org.eclipse.ecf.osgi.services.remoteserviceadmin, import.registration=ECFEndpointDescription[{component.id=3, component.name=com.godyo.service, ecf.endpoint.id.ns=org.eclipse.ecf.core.identity.StringID, ecf.generic.server.port=8889, endpoint.id=ecftcp://peter-desktop:8889/server, endpoint.package.version.com.godyo.service.api=1.0.0, objectClass=[Ljava.lang.String;@137cdb0, remote.configs.supported=[Ljava.lang.String;@a111ba, remote.intents.supported=[Ljava.lang.String;@92e44d, service.imported=org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceImpl@1e47e28, service.imported.configs=[Ljava.lang.String;@16a85a}], bundle=org.eclipse.ecf.osgi.services.remoteserviceadmin_4.2.0.v20150306-2024 [91], bundle.version=4.2.0.v20150306-2024, bundle.signer=[Ljava.lang.String;@186ec5b};severity4;exception=null;children=[]]

but nevertheless the services are discovered and working

2) on server startup i see multiple of these

WARNING 75 Getting a lock required more than 10000 ms. There might be a synchronization problem in this callstack or just the build/dispose process of some components took too long!
java.lang.Exception: Debug stacktrace
    at org.eclipse.equinox.internal.ds.InstanceProcess.getLock(InstanceProcess.java:120)
    at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:560)
    at org.eclipse.equinox.internal.ds.ServiceReg.getService(ServiceReg.java:53)
    at org.eclipse.osgi.internal.serviceregistry.ServiceUse$1.run(ServiceUse.java:141)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.osgi.internal.serviceregistry.ServiceUse.getService(ServiceUse.java:139)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:468)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:467)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:594)
    at org.osgi.util.tracker.ServiceTracker.addingService(ServiceTracker.java:411)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:1)
    at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
    at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:317)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$3.run(RemoteServiceAdmin.java:1307)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin$3.run(RemoteServiceAdmin.java:1)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.postEvent(RemoteServiceAdmin.java:1301)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.publishEvent(RemoteServiceAdmin.java:1182)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.publishExportEvent(RemoteServiceAdmin.java:1338)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.exportService(RemoteServiceAdmin.java:371)
    at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.handleServiceRegistering(AbstractTopologyManager.java:436)
    at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.access$0(BasicTopologyManagerImpl.java:1)
    at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl$1.run(BasicTopologyManagerImpl.java:84)
    at java.lang.Thread.run(Thread.java:744)

this needs to be investigated, nevertheless the services are obviously exported without any further notification. they are listed as services on the osgi console and are available on the client.

So it seems like my main problem is fixed and i can stay with this setup. Thanks again Scott!
Any further hints on the error messages are still welcome.

thx, bxe, peter

Am 11.03.2015 um 17:38 schrieb Scott Lewis:
Hi Peter,

After thinking about this a little bit, I believe I have more of an explanation for what's going on with you/your use case.  In short, I think it comes down to this:

On 3/11/2015 3:10 AM, Peter Hermsdorf wrote:
<stuff deleted>
Realistically, it might become difficult/impossible to support ECF 3.7 on Indigo for much longer...and I *believe* that ECF 3.9.3 will run on everything back to Kepler (although I admit I haven't tested on Kepler yet...I will do so/help do so, however, if that is necessary.  Please let me know).  The dependency here is on the use of the OSGI Wiring API (required for compliance with modern versions of OSGi RSA spec), which I *think* only appeared in Kepler version of Equinox (can't remember what number version of Equinox that was right now).
Of course thats a problem. I tried upgrading to the latest version, but as you already statet, there is a dependency to a core equinox.osgi package version 1.7 whereas eclipse indigo only has version 1.6 available.

An upgrade of our RCP app to Eclipse 4 is planned, but currently not in work. I case we would need a fix in ECF 3.7 I would consider patching/building it myself ....

i.e. the version of ECF RSA that you are using (ECF 3.7/Indigo) was done prior to two changes that are affecting you:

1) It was prior to the OSGi RSA 1.1 specification, which required reworking the use of the edef-given properties...for both discovery and distribution/lookup/import on the consumer.   The reason this was necessary was that RSA 1.1 added the notion of a remote service 'update' (i.e. updating the remote service's properties), and so to do this with EDEF meant adding additional properties, and more importantly, changing the semantics/handling of endpointdescription equality.  I now believe this is why my initial response of making the endpoint.service.id unique in your generated edef didn't for you, because you are using a version prior to when this property (only) was used to determine ed uniqueness.

2) Some changing (simplification, really) of use of ECF-specific remote service properties.  I can't immediately go into technical detail here, as I have to remind myself about the specifics (I've forgotten), but I'm pretty sure that that's this could be affecting you/your use case as well.

IMHO there are two ways to deal with this:

1) Help you transition to ECF 3.9.3 (or something more recent from ECF).   One thing to consider:   I'm pretty sure that ECF 3.9.3 will run properly on Equinox Kepler or later, and I believe that Kepler had/has support for RCP 3.8 (as opposed to requiring that you move to Eclipse 4.x immediately).   

2) As you say above, we could look to apply a 'fix' to ECF 3.7 (what you are experiencing may not actually be a bug in 3.7, but rather simply not yet applying the right set of remote service property values...I'm not sure at this point).  I will help with this if you so desire, but as you might expect I'm not anxious to do this...i.e. I would prefer 1.   Why?  Two reasons:  a) Moving forward it's simpler for ECF; b) When you move to something more recent in terms of ECF versions it would be better if you didn't have to rework your edef in addition to adjusting to the UI and other changes.

I'm willing to help with either 1 or 2 based upon what you decide, but I'm limited by resources (my time).

To help me figure out what would be involved with 2, would you let me know what the exact version of ECF you are using is?  (i.e. with qualifier)

Thanks,

Scott



_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev


Back to the top