You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Ephemeris Lappis (JIRA)" <ji...@apache.org> on 2013/08/13 12:00:51 UTC

[jira] [Created] (SM-2213) Service reference updating fails with

Ephemeris Lappis created SM-2213:
------------------------------------

             Summary: Service reference updating fails with <process>
                 Key: SM-2213
                 URL: https://issues.apache.org/jira/browse/SM-2213
             Project: ServiceMix
          Issue Type: Bug
          Components: servicemix-camel
    Affects Versions: 3.4.2
         Environment: Windows XP
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
            Reporter: Ephemeris Lappis
            Priority: Critical


Hello.

I have two dependent modules :
1) an OSQi bundle with its BundleActivator that registers two service factories
2) a blueprint with service references to the first bundle's interfaces.

The blueprint references the service :

{noformat}
	<reference
		id="myFifiRead"
		interface="my.fifi.eight.camel.FifiReadService" />
{noformat}

And then a route uses the references :
{noformat}
		<route>
			<from uri="jetty:http://0.0.0.0:1111/fifi-8/read" />
			<to uri="bean:myFifiRead" />
{noformat}

This works as expected. When such a route processes an exchange, the service is called. When I update my bundle, the services seem to be "relinked" and the blueprint goes on working as if nothing had changed...

As my interfaces extends the Camel processor interface, I've changed the routes to use the DSL instruction instead of the bean "to" :

{noformat}
		<route>
			<from uri="jetty:http://0.0.0.0:1111/fifi-8/read" />
			<process ref="myFifiRead" />
{noformat}

This new code works as the first one, and seems to have rather better performances (about 75% on my test case and on my machine) that the "to"...
But now when I redeploy a new version of my bundle, the blueprint fails while stopping : after the OSGi bundle activator is stopped, and the "ungetService" callbacks are called, the routes update process blocks (status 'stopping' in the console) until a rather long timeout and ends with an error (first lines of log) :

{noformat}
org.osgi.service.blueprint.container.ServiceUnavailableException: Timeout expired when waiting for mandatory OSGi service reference: (objectClass=my.fifi.eight.camel.FifiReadService)
	at org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:175)
	at org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:49)
	at org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:206)
	at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:50)
	at org.apache.aries.proxy.impl.DefaultWrapper.invoke(DefaultWrapper.java:31)
	at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:78)
{noformat}

So, what is the main difference between the two ways of calling the service reference that make the second one fails when updating dependencies ? Is this a bug or a normal behavior ?

Is there a way using some parameters to make the dependency update works in both cases ?
Thanks for your help.

NB : I've tested this on versions : 4.4.2, 4.5.1 and 4.5.2 with the same behavior...

Regards.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira