Community
Participate
Working Groups
Build Identifier: ECF 3.2.0.v20100219-1253 Hi, While using ecf generic with ECF remote services (OSGi 4.2 spec) I've encountered some limitation on how remote service calls are handled. Maybe the limitation is known or maybe I'm just not using the remote services the right way... First some context: - I have a server on which a number of remote services are registered within one ecf generic container (they all have the same containerFactoryArgs property value, e.g. ecftcp://localhost:8500/server) - I have two clients connecting to the server container and making calls to the remote services - zoodiscovery is used for service discovery (but I don't think it's relevant info here) What I see is that the call to a remote service on one client will block the call to another remote service on the other client. After some stepping into the ECF generic code I found out following behaviour of ecf generic: - On the server, there's one thread for each client connected to the server to handle incoming requests. So here incoming calls are in parallel - If the incoming request is a method call on a remote service the incoming request is forwarded (passing some other classes first) to the shared object wrapper being the ecf container containing the remote services (SOWrapper.deliverSharedObjectMessage). Till here calls from the two clients are still concurrent. - the shared object message is then put in a queue and is handled by the one and only thread attached to the SOWrapper instance. From here all clients calls from any client to any remote service (within the same ecf container) are serialized. Is this a known limitation of the ecf generic protocol or do I need to remote the services in a different way? I was thinking to put each remote service in its own container (but using the same IP address and port, e.g. serviceA in container ecftcp://localhost:8500/serviceA, serviceB in ecftcp://localhost:8500/serviceB,...) but this solves the problem only partially: calls to the same remote service would still be serialized in the SOWrapper. Reproducible: Always Steps to Reproduce: 1. One ecf generic server container with at least one registered remote service 2. Remote service has method taking some time to return (e.g. put a sleep in it) 3. Two ecf generic clients connecting to the server container and making concurrent calls to the lengthy method on the remote service
You are correct about the limitation...up until recently the ECF generic provider did have only a single thread for processing remote requests. Recently, however, this limitation has been removed, and the ECF generic provider (in RegistrySharedObject class) now uses the Equinox event manager to invoke remote calls in a separate thread. This enhancement will be in ECF 3.4, and is available now via recent builds (available at our builder here: https://ecf2.osuosl.org/hudson/). BTW, I'm considering adding API to RegistrySharedObject so that subclasses can define their own execution context (i.e. their own thread pool, etc) for handling remote execution requests. Please let us know (via this bug or ecf-dev mailing list) if you think this will prove useful. Thanks for the report. I'm resolving as fixed. If this doesn't address your issue...or if there are things that you would like to see different, etc please reopen and detail.
I forgot to mention on comment 1 that this addition will be in the Helios service release (i.e. ECF 3.3.1) as well as in ECF 3.4 and subsequent versions.
(In reply to comment #2) > I forgot to mention on comment 1 that this addition will be in the Helios > service release (i.e. ECF 3.3.1) as well as in ECF 3.4 and subsequent versions. Hi Scott, Thanks for the quick response. About the API on RegistrySharedObject: with my little knowledge about the ECF framework I would say it might be useful as I'm looking on how to put authorization on service method invocations (most probably in combination with spring security) and it looks like RegistrySharedObject is the place to customize (? need some more investigation on my side...). One more question: Before reporting a bug that might be already solved, I'm looking first on the CVS repository (:pserver:anonymous@dev.eclipse.org:/cvsroot/rt HEAD) for the latest source code but I have the impression it isn't always the latest code. Am I right?
(In reply to comment #3) > One more question: Before reporting a bug that might be already solved, I'm > looking first on the CVS repository > (:pserver:anonymous@dev.eclipse.org:/cvsroot/rt HEAD) for the latest source > code but I have the impression it isn't always the latest code. Am I right? We haven't switched to git yet so dev.eclipse.org is still our primary repo. What you might experiencing though, is that anonymous pserver access sometimes takes a few minutes to sync up with committer access (afaik due to some kind of replication).
(In reply to comment #3) > (In reply to comment #2) > > I forgot to mention on comment 1 that this addition will be in the Helios > > service release (i.e. ECF 3.3.1) as well as in ECF 3.4 and subsequent versions. > > Hi Scott, > > Thanks for the quick response. > About the API on RegistrySharedObject: with my little knowledge about the ECF > framework I would say it might be useful as I'm looking on how to put > authorization on service method invocations (most probably in combination with > spring security) and it looks like RegistrySharedObject is the place to > customize (? need some more investigation on my side...). Yes, that would probably be right (RegistrySharedObject for authorization on service method invocations). I think it's likely that more additions will be made to RegistrySharedObject...along with some refactoring...during this release cycle (i.e. both before 3.4 and for 3.5/3.6). So if you can, I would suggest cooperating closely with us (via mailing list) and possibly even considering contributing some work to ECF directly. > > One more question: Before reporting a bug that might be already solved, I'm > looking first on the CVS repository > (:pserver:anonymous@dev.eclipse.org:/cvsroot/rt HEAD) for the latest source > code but I have the impression it isn't always the latest code. Am I right? It is the 'latest' code...with the caveat (ala comment 4) that since the Foundation has gone to allowing a 'slight delay' for pserver access one may not get updates immediately.
(In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #2) > > > I forgot to mention on comment 1 that this addition will be in the Helios > > > service release (i.e. ECF 3.3.1) as well as in ECF 3.4 and subsequent versions. > > > > Hi Scott, > > > > Thanks for the quick response. > > About the API on RegistrySharedObject: with my little knowledge about the ECF > > framework I would say it might be useful as I'm looking on how to put > > authorization on service method invocations (most probably in combination with > > spring security) and it looks like RegistrySharedObject is the place to > > customize (? need some more investigation on my side...). > Yes, that would probably be right (RegistrySharedObject for authorization on > service method invocations). > I think it's likely that more additions will be made to > RegistrySharedObject...along with some refactoring...during this release cycle > (i.e. both before 3.4 and for 3.5/3.6). So if you can, I would suggest > cooperating closely with us (via mailing list) and possibly even considering > contributing some work to ECF directly. I'll try to help as much as I can. I'm still in the investigation phase of what is needed (+learning ECF). Meanwhile I subscribed to the ecf dev list, so you will hear from me via the dev list. > > > > One more question: Before reporting a bug that might be already solved, I'm > > looking first on the CVS repository > > (:pserver:anonymous@dev.eclipse.org:/cvsroot/rt HEAD) for the latest source > > code but I have the impression it isn't always the latest code. Am I right? > It is the 'latest' code...with the caveat (ala comment 4) that since the > Foundation has gone to allowing a 'slight delay' for pserver access one may not > get updates immediately.
