camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Davidson <richard.davidson...@gmail.com>
Subject Re: OsgiServiceRegistry caching service references, why?
Date Thu, 11 Feb 2016 00:10:21 GMT
Quinn, regarding the other issues, it would be good to get as many examples
of the issues as possible. I plan have a go at fixing this tomorrow evening
so. Is there a JIRA ticket for this issue, or has it just been a discussion
on the mailing list?


On Thu, Feb 11, 2016 at 12:05 AM, Richard Davidson <
richard.davidson.uk@gmail.com> wrote:

> No I plan to only proxy the service if it is available in the camel
> OsgiServiceRegistry and therefore not using blueprint. That way it can
> change in the background.
> Beans that are obtained in the BlueprintContainer registry will have a
> blueprint proxy and will be unchanged from what they where before.
>
> Thanks,
> Richard
>
> On Wed, Feb 10, 2016 at 11:55 PM, Quinn Stevenson <
> quinn@pronoia-solutions.com> wrote:
>
>> If I’m understanding this correctly, you’re suggesting a proxy around the
>> references for ALL services - whether Blueprint has already proxied them or
>> not.  Am I understanding you correctly?  If I am, it seems a bit wasteful
>> to re-do what Blueprint is already doing for us.
>>
>> The other really strange part was when I brought the Bean Component into
>> the mix.  If I didn’t inject the reference into the route building and then
>> called the bean using to( “bean://..” ), I’d get the
>> ServiceUnavailableException I expect.  But just injecting the reference
>> breaks the behavior - even when use the Bean Component.
>>
>> I have some other strange examples of what works and what doesn’t if
>> they’d help.  I didn’t put them in the ticket because I didn’t want to
>> confuse matters.
>>
>>
>> > On Feb 10, 2016, at 8:15 AM, Richard Davidson <
>> richard.davidson.uk@gmail.com> wrote:
>> >
>> > Yes I agree. Creating a proxy like blueprint which wraps a service
>> tracker
>> > is the best option as it allows other beans in the context to keep the
>> > reference to the service. Otherwise the beans would need to be totally
>> > stateless and lookup the registry every time.
>> >
>> > On Wed, Feb 10, 2016 at 2:55 PM, Christian Schneider <
>> > chris@die-schneider.net> wrote:
>> >
>> >> Hi Richard,
>> >>
>> >> I thought the issue was created by you but it was by Quinn.
>> >>
>> >> I think we really have to avoid caching services. Especially as this
>> can
>> >> cause problems with classloader cleanup when a bundle is uninstalled.
>> >> So I think we either need to put a proxy into the service registry
>> like in
>> >> blueprint or we need to react on the event when the service is removed
>> and
>> >> clean it from the registry.
>> >>
>> >> Christian
>> >>
>> >>
>> >> On 10.02.2016 15:49, Richard Davidson wrote:
>> >>
>> >>> Hi Christian,
>> >>>
>> >>> The original ticket was not logged by me, I just commented on the
>> >>> behaviour. The original issue described at the start of the ticket in
>> >>> which
>> >>> the service object is being cached exists for scenario 2 and scenario
>> 3.
>> >>> Both these scenarios find the bean in the OsgiServiceRegistry, so the
>> >>>  BlueprintContainerRegistry is not used.
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Feb 10, 2016 at 1:47 PM, Christian Schneider <
>> >>> chris@die-schneider.net> wrote:
>> >>>
>> >>> Hi Richard,
>> >>>>
>> >>>> now I understand your problem. So the problem is only with Scenario
>> 3.
>> >>>> Can you update the issue to reflect this?
>> >>>>
>> >>>> So does the example you mentioned in the issue (which would probably
>> be
>> >>>> scenario4) really not work?
>> >>>> I am pretty sure it should work.
>> >>>>
>> >>>> Christian
>> >>>>
>> >>>>
>> >>>> On 10.02.2016 12:51, Richard Davidson wrote:
>> >>>>
>> >>>> Hi.
>> >>>>>
>> >>>>> Sorry, I may have caused more confusion!. You are correct that
if
>> the
>> >>>>> blueprint registry is used, it will create a proxy, and the
service
>> can
>> >>>>> come and go in the background without any issues. The issue
on this
>> >>>>> ticket
>> >>>>> is to do with the OsgiServiceRegistry in camel. When camel tries
to
>> >>>>> lookup
>> >>>>> a component it goes to its registry. This is typically a composite
>> >>>>> registry
>> >>>>> which looks up a chain of other registries. When using camel
through
>> >>>>> blueprint the chain is:
>> >>>>>
>> >>>>> OsgiServiceRegistry -> BlueprintContainerRegistry
>> >>>>>
>> >>>>> The OsgiServiceRegistry does not use blueprint in any way and
looks
>> up
>> >>>>> services in the actual OSGi registry using
>> BundleContext.getService().
>> >>>>> It
>> >>>>> uses the 'name' as the interface to lookup. As the camel
>> >>>>> OsgiServiceRegistry is first in the chain it will always be
checked
>> >>>>> first.
>> >>>>> If it can't get the service, it will return null and the blueprint
>> >>>>> registry
>> >>>>> will be called. The examples below describe the behaviour:
>> >>>>>
>> >>>>> For each scenario I have exported an OSGI service with the interface
>> >>>>> 'com.test.camel.test.Hello'.
>> >>>>>
>> >>>>> <b>Scenario 1</b>
>> >>>>> If I use the following blueprint, the blueprint registry is
used
>> and the
>> >>>>> service is therefore a proxy:
>> >>>>> <raw>
>> >>>>> <reference id="helloBean" interface="com.test.camel.test.Hello"
/>
>> >>>>>
>> >>>>> <camelContext id="blueprintContext" trace="false"
>> >>>>> xmlns="http://camel.apache.org/schema/blueprint">
>> >>>>> <route id="timerToLog">
>> >>>>> <from uri="timer:foo?period=1000" />
>> >>>>> <setBody>
>> >>>>> <method ref="helloBean" method="hello" />
>> >>>>> </setBody>
>> >>>>> <log loggingLevel="INFO" message="The message contains ${body}"
/>
>> >>>>> </route>
>> >>>>> </camelContext>
>> >>>>> </raw>
>> >>>>>
>> >>>>> <b>Scenario 2</b>
>> >>>>> If I use the following route the OSGi registry is used and a
direct
>> >>>>> reference to the bean in the OSGI registry is obtained via the
>> >>>>> OSGIServiceRegistry in camel.
>> >>>>> <raw>
>> >>>>> <camelContext id="blueprintContext" trace="false"
>> >>>>> xmlns="http://camel.apache.org/schema/blueprint">
>> >>>>> <route id="timerToLog">
>> >>>>> <from uri="timer:foo?period=1000" />
>> >>>>> <setBody>
>> >>>>> <method ref="com.test.camel.test.Hello" method="hello" />
>> >>>>> </setBody>
>> >>>>> <log loggingLevel="INFO" message="The message contains ${body}"
/>
>> >>>>> </route>
>> >>>>> </camelContext>
>> >>>>> </raw>
>> >>>>>
>> >>>>> <b>Scenario 3</b>
>> >>>>> If I lookup up a bean name that is available in both registries
>> then I
>> >>>>> will
>> >>>>> use the OsgiServiceRegistry, and I will not get a blueprint
proxy.
>> >>>>> <raw>
>> >>>>>
>> >>>>> <reference id="com.test.camel.test.Hello"
>> >>>>> interface="com.test.camel.test.Hello" />
>> >>>>>
>> >>>>> <camelContext id="blueprintContext" trace="false"
>> >>>>> xmlns="http://camel.apache.org/schema/blueprint">
>> >>>>> <route id="timerToLog">
>> >>>>> <from uri="timer:foo?period=1000" />
>> >>>>> <setBody>
>> >>>>> <method ref="com.test.camel.test.Hello" method="hello" />
>> >>>>> </setBody>
>> >>>>> <log loggingLevel="INFO" message="The message contains ${body}"
/>
>> >>>>> </route>
>> >>>>> </camelContext>
>> >>>>>
>> >>>>> </raw>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> The OsgiServiceRegistry currently caches the service object
so if
>> the
>> >>>>> bundle exporting com.test.camel.test.Hello restarts, then I
think
>> the
>> >>>>> route
>> >>>>> will fail, but I have not tested this.
>> >>>>>
>> >>>>> So I think there are two potential issues:
>> >>>>> 1. The OsgiServiceRegistry needs to track services.
>> >>>>> 2. I think the BlueprintContainerRegistry should be first in
the
>> chain
>> >>>>> before the OsgiServiceRegistry. This will mean if the service
/
>> bean is
>> >>>>> present in blueprint it will always take predence over the bean
in
>> the
>> >>>>> OsgiServiceRegistry.
>> >>>>>
>> >>>>> On Wed, Feb 10, 2016 at 8:01 AM, Christian Schneider <
>> >>>>> chris@die-schneider.net> wrote:
>> >>>>>
>> >>>>> If you inject a blueprint reference to a service into a RouteBuilder
>> >>>>> class
>> >>>>>
>> >>>>>> then I would expect that the camel registry is not involved
at all
>> >>>>>> and you would be able to use the service proxy injected
by
>> blueprint
>> >>>>>> inside the route.
>> >>>>>>
>> >>>>>> When the service disappears the blueprint proxy should run
into
>> >>>>>> ServiceUnavailableException.
>> >>>>>>
>> >>>>>> @Claus: Can you confirm this or am I overlooking something?
>> >>>>>> This is related to this issue
>> >>>>>> https://issues.apache.org/jira/browse/CAMEL-9570
>> >>>>>>
>> >>>>>> Christian
>> >>>>>>
>> >>>>>>
>> >>>>>> On 09.02.2016 20:32, Quinn Stevenson wrote:
>> >>>>>>
>> >>>>>> In reference to the Blueprint proxy - if I use the Camel
Bean
>> component
>> >>>>>>
>> >>>>>>> to call the service (i.e. to( “bean://my-bean” ),
and I do NOT
>> inject
>> >>>>>>> the
>> >>>>>>> service reference into the route builder, I get the
dynamic swap
>> of
>> >>>>>>> the
>> >>>>>>> service implementation.  That (along with reading the
Blueprint
>> specs)
>> >>>>>>> lead
>> >>>>>>> to me to believe that the service proxy isn’t swapped
- just the
>> >>>>>>> underlying
>> >>>>>>> service reference.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>>
>> >>>>>> Christian Schneider
>> >>>>>> http://www.liquid-reality.de
>> >>>>>>
>> >>>>>> Open Source Architect
>> >>>>>> http://www.talend.com
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>> Christian Schneider
>> >>>> http://www.liquid-reality.de
>> >>>>
>> >>>> Open Source Architect
>> >>>> http://www.talend.com
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >> --
>> >> Christian Schneider
>> >> http://www.liquid-reality.de
>> >>
>> >> Open Source Architect
>> >> http://www.talend.com
>> >>
>> >>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message