Community
Participate
Working Groups
This arose with an application (see the referenced URL) that uses Spring DM 1.2.1 and calls a service repeatedly. Each time the service is called, Spring DM gets the service again and does not do an unget until the caller's application context is destroyed. This behaviour is fixed in Gemini Blueprint/Spring DM 2.0, but it shows a weakness in the current Equinox implementation for misbehaving applications. After the use count has become negative, the application experiences degraded performance until the use count has become positive again. This problem shows up on Equinox 3.6.1 and 3.7.
Getting a service and ungetting a service are paired operations. Thus the use count. It is an error for the use count to overflow. So this must be detected. The proper change here will be for a ServiceException to be thrown if overflow is detected. I don't see any reasonable scenario where a bundle needs to get a service more than MAX_INTEGER times. This would indicate a bundle error because the bundle is leaking use count and not properly managing the necessary calls to unget.
The problem is in Spring DM 1.2.1 but since the codebase has migrated to Gemini Blueprint where the problem is fixed, we want to avoid issuing another Spring DM release simply to fix this problem. So if the solution in Equinox is to throw an exception, we'd like to be able to configure Equinox to suppress the exception so we can upgrade the version of Equinox in Virgo without having to upgrade Spring DM 1.2.1 to Blueprint, which is a large change and will be done in a future version.
If this fix is for Juno, then you have a complete release cycle to update, no? We can leave things as they are for the 3.7.x maint stream.
(In reply to comment #3) > If this fix is for Juno, then you have a complete release cycle to update, no? > > We can leave things as they are for the 3.7.x maint stream. Yeah, that's pretty good. I just don't want to over-commit the Virgo release that pulls in Juno's Equinox at this stage. However, I suppose I could live with bumping up the priority of the Blueprint upgrade.
Assigning to BJ. I assume you are going to cause a ServiceException to be thrown from BundleContext.getService() in this case since we have determined that this kind of scenario indicates a bug in the client bundle? Or perhaps you throw an IllegalStateException since there is no good ServiceException type to cover this case. We already throw IllegalStateException if the BundleContext is invalid so it seems like a natural choice to throw that if we determine the BundleContext is being used in an invalid way also.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=350944#c0 for Virgo consequences of this bug.
I pushed the following fix to master. http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=ebca5861a14f56b46a0bfee8a40c3495d0c69d1c A ServiceException will be thrown if the request would overflow the use count.
See https://dev.eclipse.org/mhonarc/lists/virgo-dev/msg00936.html for details on why overflowing the usecount is bad.
