[jira] [Created] (CAMEL-11810) Lifecycle problems for services retrieved from Blueprint container

["Grzegorz Grzybek (JIRA)" <ji...@apache.org>]

Grzegorz Grzybek created CAMEL-11810:
----------------------------------------

             Summary: Lifecycle problems for services retrieved from Blueprint container
                 Key: CAMEL-11810
                 URL: https://issues.apache.org/jira/browse/CAMEL-11810
             Project: Camel
          Issue Type: Bug
          Components: camel-blueprint
            Reporter: Grzegorz Grzybek
            Assignee: Grzegorz Grzybek


I have a case where one bundle/blueprint-container defines:
{code:xml}
    <bean id="messageIdRepositoryImpl" class="org.apache.camel.processor.idempotent.MemoryIdempotentRepository"/>

    <service id="messageIdRepository" interface="org.apache.camel.spi.IdempotentRepository" ref="messageIdRepositoryImpl" />
{code}

and another one defines Camel context with:
{code:xml}
    <reference id="messageIdRepository" interface="org.apache.camel.spi.IdempotentRepository"/>
    <camelContext xmlns="http://camel.apache.org/schema/blueprint">

        <route id="xx">

            <from uri="file://xxx?y=z&amp;readLock=idempotent&amp;idempotent=true&amp;idempotentRepository=#messageIdRepository&amp;other.properties[...]" />
{code}

The problem is that when bundle defining {{messageIdRepositoryImpl}} is stopped, stopping bundle/blueprint-container leads to wait on Proxy/ReferenceRecipe:
{noformat}
org.osgi.service.blueprint.container.ServiceUnavailableException: Timeout expired when waiting for mandatory OSGi service reference: (objectClass=org.apache.camel.spi.IdempotentRepository)
	at org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:234)
	at org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:56)
	at org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:306)
	at Proxy28f0d520_9465_4682_9ec1_02ae44e9fa4a.toString(Unknown Source)
	at java.lang.String.valueOf(String.java:2994)[:1.8.0_144]
	at java.lang.StringBuilder.append(StringBuilder.java:131)[:1.8.0_144]
	at org.apache.camel.impl.DefaultCamelContext.shutdownServices(DefaultCamelContext.java:3214)
	at org.apache.camel.impl.DefaultCamelContext.shutdownServices(DefaultCamelContext.java:3234)
	at org.apache.camel.impl.DefaultCamelContext.shutdownServices(DefaultCamelContext.java:3222)
	at org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:3101)
	at org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
	at org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:129)
...
{noformat}

There are few problems here. First - {{GenericFileEndpoint.doStart()}} does this:
{code:java}
if (idempotentRepository != null) {
    getCamelContext().addService(idempotentRepository, true);
}
{code}

which adds the blueprint recipe (proxy) to {{org.apache.camel.impl.DefaultCamelContext#servicesToStop}} without a way to specify {{stopOnShutdown=false}}.

IMO services obtained from OSGi registry should not be tied to lifecycle of single context with route having {{#referenceToOsgiOrBlueprintService}} in endpoint URI.

Also - the above stack trace is not retrieved when stopping an osgi service, but when log.warning an exception!:
{code:xml}
log.warn("Error occurred while shutting down service: " + service + ". This exception will be ignored.", e);
{code}
In the above code we have implicit {{toString()}} call on service which leads to another proxy call which calls {{org.apache.aries.blueprint.container.ReferenceRecipe.ServiceDispatcher#call()}} → {{org.apache.aries.blueprint.container.ReferenceRecipe#getService()}} → {{org.apache.aries.blueprint.container.ReferenceRecipe#monitor.wait(metadata.getTimeout()}}.

The most obvious fix is to move idempotent repository to a blueprint file where file endpoint is used.

But as OSGi devil's advocate, I suggest more generic solution: when looking up objects inside {{org.apache.camel.blueprint.BlueprintContainerRegistry}}, in addition to calling {{org.osgi.service.blueprint.container.BlueprintContainer#getComponentInstance()}} we may check if {{blueprintContainer.getComponentMetadata(name) instanceof ReferenceMetadata}} and in such case return a proxied proxy that would prevent waiting for blueprint reference when we're stopping the context - we'd have to check if the target service is available anyway (why ReferenceRecipe doesn't have a method like "tryGetService()"?)...

Less generic fix could be to add a flag used instead of default:
{code:java}
// idempotent repository may be used by others, so add it as a service so its stopped when CamelContext stops
if (idempotentRepository != null) {
    getCamelContext().addService(idempotentRepository, true);
}
{code}

so user could decide whether idempotent repository is or isn't "external" ("shared").



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)