Richard, how much of a performance hit do you think it would be to do a
look up of the service via a tracker? Since I live in I/O bound
environments that sort of hit is usually acceptable as long as it isn't too
extreme. That's especially true if it brings better stability and dynamic
class handling. If I'm understanding the proposed mechanics this would
make the hot swapping and service references more stable. When
Camel/blueprint/OSGi proxy and interface to a concrete implementation and a
hot swap happens, does it create a new proxy or does it swap the
implementation that the proxy holds? The latter would be a preferred
mechanism I'd think. The bundle holding the reference to a proxied service
then doesn't ever lose the reference since it is just pointing to the
proxy. But the internal implementation might be set to a different class
e.g. switching from a test stub bundle to an implementation bundle.
If we are going to change any of the classloader mechanics please put
guards around the classloaders in blueprint so that we can have a setting
to short circuit some of the slop bucket classloading that goes on there.
>From the comments in the code it was put in place to accommodate JBI but it
has resulted in some unpredictable behavior when loading
classes/services. That should be relatively easy and painless to put in
place. I've put a Jira ticket in for that as well. But if there is going
to be some work on the blueprint/osgi classloaders now would be a good time
to address that as well. A simple boolean with a strict OSGi mode that,
when set to true, disallows SU classloader mechanics but would be false by
default.
Does OSGi manage the other registries? In other words, when I fire up a
context and it creates a simple registry in Camel is that simple registry
managed by the OSGi registry? Should it be? I haven't wandered into that
section of code.
On Tue, Feb 9, 2016 at 9:53 AM, Quinn Stevenson <qu...@pronoia-solutions.com
> wrote:
> That sounds good to me - I rely pretty heavily on the
> ServiceUnavailableException after the proxy times-out, so I didn’t want
> this behavior to change (or at least I need to know if it’s going to
> change).
>
> Is looking-up the service in the OSGi Registry expensive? I thought the
> OSGi internals cached those services for us.
>
>
> > On Feb 9, 2016, at 8:15 AM, Richard Davidson <
> richard.davidson...@gmail.com> wrote:
> >
> > I am not sure what the order the registries are chained together. I need
> to
> > test whether the blueprint or the OSGI registry is first, From looking at
> > the code:
> > {code}
> >
> > public static Registry wrapRegistry(CamelContext camelContext,
> Registry
> > registry, BundleContext bundleContext) {
> >
> > ObjectHelper.notNull(bundleContext, "BundleContext");
> >
> > LOG.debug("Setting up OSGi ServiceRegistry");
> >
> > OsgiServiceRegistry osgiServiceRegistry = new OsgiServiceRegistry(
> > bundleContext);
> >
> > // Need to clean up the OSGi service when camel context is closed.
> >
> > camelContext.addLifecycleStrategy(osgiServiceRegistry);
> >
> > CompositeRegistry compositeRegistry = new CompositeRegistry();
> >
> > compositeRegistry.addRegistry(osgiServiceRegistry);
> >
> > compositeRegistry.addRegistry(registry);
> >
> > return compositeRegistry;
> >
> > }
> > {code}
> >
> > I think the OSGI registry would be first in the chain as it is first in
> the
> > composite registry. If this is true then the the OSGI registry would be
> > checked first, and if it didn't exist in the OSGI registry then it would
> > try blueprint. I think this is wrong and the OSGI registry should be
> added
> > to the end of the chain, so blueprint etc is tried first. However making
> > this change would change existing functionality and could cause issues
> for
> > existing deployments.
> >
> > Another point to note is that the service tracker change only works of
> the
> > processor looks up the registry every-time to get the service. If it
> holds
> > on to the service reference and the service goes away, requests will
> fail.
> >
> > In my view adding service trackers to OsgiServiceRegistry is an
> improvement
> > on what exists today, but I would still strongly advise using blueprint
> > proxies instead, as the reference to the service can be cached in the
> > processor.
> >
> >
> >
> >
> > On Tue, Feb 9, 2016 at 2:55 PM, Quinn Stevenson <
> qu...@pronoia-solutions.com
> >> wrote:
> >
> >> I normally use Blueprint to use OSGi Services. In that case, I should
> >> wind up with a Blueprint service proxy. Would using a ServiceTracker
> with
> >> a Blueprint proxy be necessary? I think the Blueprint proxy already
> does
> >> that for me.
> >>
> >>
> >>> On Feb 9, 2016, at 2:31 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> >>>
> >>> On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
> >>> <richard.davidson...@gmail.com <mailto:richard.davidson...@gmail.com>>
> >> wrote:
> >>>> Hi,
> >>>>
> >>>> Instead of the cache containing the actual service objects it could it
> >>>> contain a org.osgi.util.tracker.ServiceTracker. This would then cache
> >> and
> >>>> track the service internally. Each time the service is requested via
> the
> >>>> registry, #ServiceTracker.getService() could be called. Let me know
> >> your
> >>>> thoughts, and if people agree I could try to create a patch.
> >>>>
> >>>
> >>> Yeah we use service tracker to track components and whatnot.
> >>>
> >>> I have said it many times, we love contributions
> >>> http://camel.apache.org/contributing <
> >> http://camel.apache.org/contributing>
> >>>
> >>>>
> >>>> On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <claus.ib...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Hi
> >>>>>
> >>>>> Yeah it was created that way - i guess maybe the though was that osgi
> >>>>> reference lookup is expensive?
> >>>>>
> >>>>> I guess we can reach out to the OSGi folks and see what they say. It
> >>>>> would make the code simpler without a local cache.
> >>>>>
> >>>>>
> >>>>> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <t...@mccarthy.co.nz>
> wrote:
> >>>>>> I have looked at the code in
> >>>>> org.apache.camel.core.osgi.OsgiServiceRegistry
> >>>>>> (camel-core-osgi-2.15.4) and it appears to cache the service
> >> references.
> >>>>>> This means that if I uninstall/install the bundle supplying the
> >> service
> >>>>> it
> >>>>>> wont automagically 'pick up' the new service.
> >>>>>>
> >>>>>> For what reason(s) are the service references cached?
> >>>>>>
> >>>>>> Note - after modifying OsgiServiceRegistry and removing the cache a
> >> new
> >>>>>> service is picked up and behaves more like I would expect in a
> dynamic
> >>>>> OSGi
> >>>>>> environment.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>
> >>
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
> >>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Claus Ibsen
> >>>>> -----------------
> >>>>> http://davsclaus.com @davsclaus
> >>>>> Camel in Action 2: https://www.manning.com/ibsen2
> >>>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Claus Ibsen
> >>> -----------------
> >>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> >>> Camel in Action 2: https://www.manning.com/ibsen2 <
> >> https://www.manning.com/ibsen2>
> >>
>
>
