camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Johnson <brad.john...@mediadriver.com>
Subject Re: OsgiServiceRegistry caching service references, why?
Date Thu, 11 Feb 2016 01:14:22 GMT
Richard,

I ran into similar issues recently when I was using services with route
builders.  I'd see non-proxied hard classes showing up.  Restarts on ;the
bundle(s) would then cause failures because the service class was being
referenced.  It makes sense now that I'm following the discussion since I
was unaware of the difference in the proxying mechanics going on between
OSGi (which I guess are non-existent) and the Blueprint.  I also
inadvertently ran into a similar issue with this when I misconfigured
something and the package scanner in the route builder jumped the tracks
and used the SU classloader. I'm not sure if that's what contribute to some
of the other bugs that Quinn has noticed as well.

https://issues.apache.org/jira/browse/CAMEL-9562

It certainly does seem to be a loophole that needs to be closed or at least
closeable.

The only real solution I've found to any of this is to fall back to using
blueprint almost exclusively and to stay away from route builders,
annotations and the Java DSL in general.  That's unfortunate as I'd prefer
to work in the Java DSL as would my clients but keeping the stars and moons
aligned is too difficult.

On Wed, Feb 10, 2016 at 6:10 PM, Richard Davidson <
richard.davidson.uk@gmail.com> wrote:

> 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