Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » Remote service calls handled by one thread when using ecf generic?
Remote service calls handled by one thread when using ecf generic? [message #625405] Tue, 14 September 2010 14:54 Go to next message
Franky Bridelance is currently offline Franky Bridelance
Messages: 4
Registered: September 2010
Junior Member
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.
Re: Remote service calls handled by one thread when using ecf generic? [message #628811 is a reply to message #625405] Fri, 24 September 2010 08:24 Go to previous message
Markus Kuppe is currently offline Markus Kuppe
Messages: 177
Registered: July 2009
Senior Member
On 09/14/2010 04:54 PM, Franky Bridelance wrote:
> 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.

Fixed as part of https://bugs.eclipse.org/325949

Markus
Previous Topic:ClassNotFoundException with r-osgi and ECF (not with r-osgi only)
Next Topic:NoSuchMethodException thrown for some services
Goto Forum:
  


Current Time: Thu Oct 02 04:43:04 GMT 2014

Powered by FUDForum. Page generated in 0.02224 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software