Eclipse Community Forums: Gemini » Performance and concurrency of calls into services

Home » Eclipse Projects » Gemini » Performance and concurrency of calls into services

Performance and concurrency of calls into services [message #926453]

Fri, 28 September 2012 13:14

Eclipse User

We ran into the problem described in

https://bugs.eclipse.org/bugs/show_bug.cgi?id=377198

where our bundle's code calls into a service that is resolved via Gemini Blueprint. The code is multi-threaded and invokes methods on that service often.

In short, the synchronization around service lookups in Gemini Blueprint appears to be a huge, huge bottleneck. At this point we're basically going to have to tell our developers to avoid Gemini Blueprint in many circumstances when it comes to wiring together services and references to those services.

Is there a way around this? Short of resolving the bug (granted, the solution proposed in the bug may not be correct), what is the recommended way to go?

Thanks again,
rich

Re: Performance and concurrency of calls into services [message #929100 is a reply to message #926453]

Mon, 01 October 2012 04:12

Eclipse User

The only clean solution I can think of is to fix that bug or patch Gemini Blueprint with some code based on the proposed solution. The proposed solution looks plausible, but I haven't checked the code to see if the service holder is volatile and is cleared if the service goes away.

An obvious workaround, which may not be acceptable, is to code a method on the service interface which returns the service object. Then any performance/scalability sensitive caller can get hold of the service object directly and avoid all overheads and bottlenecks. Of course, this would go pear-shaped if you need to stop the service and have those callers react appropriately. But, depending on the design of your bundles and how their lifecycles behave and coordinate, this may be a suitable workaround.

Re: Performance and concurrency of calls into services [message #929704 is a reply to message #929100]

Mon, 01 October 2012 13:28

Eclipse User

Thanks for the idea in terms of a workaround. In the absence of a fix we'll likely need just not use Blueprint for high traffic services. My next concern then is that we may discover that a number of our services start to run into this as we scale up.

Re: Performance and concurrency of calls into services [message #930300 is a reply to message #929704]

Tue, 02 October 2012 03:27

Eclipse User

Fair enough. I think the raw pathlength of calls to Blueprint services is also likely to be an issue for performance sensitive services. I wonder if Declarative Services is more appropriate because of its lack of service damping and presumably therefore proxying?

Re: Performance and concurrency of calls into services [message #930900 is a reply to message #930300]

Tue, 02 October 2012 14:48

Eclipse User

I went from programmatically dealing with services directly to Blueprint services, so never delved into Declarative Services. Lemme see if I understand what you're suggesting.

Given: bundle A consumes service X provided by bundle B:

Would I just need to change the way that bundle B declares service X (and not change bundle A at all, which would still use Blueprint)?

or...

Would I need to (also) change the way that bundle A is wired to service X?

That is, do we need to provide *and* consume through Declarative Services in order to avoid the synchronization?

Previous Topic:	Best practice - gemini jpa
Next Topic:	Various Web Site Links Wrong / Spring DM Examples

Goto Forum:

-=] Back to Top [=-

Current Time: Wed May 07 16:18:33 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter