ServiceFactory, ungetService, and what to do with cached obsolete instances

[Christopher BROWN <br...@reflexe.fr>]

Hi,

I've encountered a problem and don't see what the correct solution is, if
there is any.

Some clients are requesting a service implemented as a ServiceFactory.  The
getService() method returns a proxy, and the ungetService() method disposes
of the resources used by the proxy (connections, files, etc).  The proxy is
therefore associated with the client bundle.  This works fine for clients
that get a reference and an instance in their BundleActivator's start()
method and release it in the stop() method.

However, some clients don't necessarily retain the reference, they get the
instance for a specific operation, then release it immediately (in nice
try...finally blocks).  When they release it, the usage count goes to zero,
and ungetService() is called on the ServiceFactory, which duly performs
cleanup.  This is where the trouble starts, because then the client
requests it again at some later point, and as per the JavaDocs for
ServiceFactory, it's the original cached proxy instance (the one that's
already been cleaned up) that gets returned, without the ServiceFactory's
getService() method being called.

So I can't reactivate it, I can't provide a new proxy, and the client gets
an obsolete instance.

What should I do?  I did try doing stuff like calling unregister() on the
ServiceRegistration passed to ungetService() but that didn't seem to help.

Thanks in advance,
Christopher Brown

Re: ServiceFactory, ungetService, and what to do with cached obsolete instances

[Christopher BROWN <br...@reflexe.fr>]

Hi,

The problem turned out to be some non-null ServiceReferences never being
used to get the service object, but the unget() always being called in the
"finally" block.  So, everything seems fine, sorry for the noise...

Thanks
Christopher



On 16 October 2012 04:13, Richard S. Hall <he...@ungoverned.org> wrote:

> On 10/15/12 17:34 , Christopher BROWN wrote:
>
>> Hi,
>>
>> I've encountered a problem and don't see what the correct solution is, if
>> there is any.
>>
>> Some clients are requesting a service implemented as a ServiceFactory.
>>  The
>> getService() method returns a proxy, and the ungetService() method
>> disposes
>> of the resources used by the proxy (connections, files, etc).  The proxy
>> is
>> therefore associated with the client bundle.  This works fine for clients
>> that get a reference and an instance in their BundleActivator's start()
>> method and release it in the stop() method.
>>
>> However, some clients don't necessarily retain the reference, they get the
>> instance for a specific operation, then release it immediately (in nice
>> try...finally blocks).  When they release it, the usage count goes to
>> zero,
>> and ungetService() is called on the ServiceFactory, which duly performs
>> cleanup.  This is where the trouble starts, because then the client
>> requests it again at some later point, and as per the JavaDocs for
>> ServiceFactory, it's the original cached proxy instance (the one that's
>> already been cleaned up) that gets returned, without the ServiceFactory's
>> getService() method being called.
>>
>> So I can't reactivate it, I can't provide a new proxy, and the client gets
>> an obsolete instance.
>>
>
> Either (1) this is a bug in the framework or (2) you are not seeing what
> you think you are seeing. If you look in the source code of the framework
> in ServiceRegistry.ungetService() you can see that it definitely at least
> attempts to flush the cache when the usage count reaches zero.
>
> If this is not happening, then create an issue in JIRA and attach an
> example to demonstrate. Thanks.
>
> -> richard
>
>
>
>> What should I do?  I did try doing stuff like calling unregister() on the
>> ServiceRegistration passed to ungetService() but that didn't seem to help.
>>
>> Thanks in advance,
>> Christopher Brown
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Re: ServiceFactory, ungetService, and what to do with cached obsolete instances

["Richard S. Hall" <he...@ungoverned.org>]

On 10/15/12 17:34 , Christopher BROWN wrote:
> Hi,
>
> I've encountered a problem and don't see what the correct solution is, if
> there is any.
>
> Some clients are requesting a service implemented as a ServiceFactory.  The
> getService() method returns a proxy, and the ungetService() method disposes
> of the resources used by the proxy (connections, files, etc).  The proxy is
> therefore associated with the client bundle.  This works fine for clients
> that get a reference and an instance in their BundleActivator's start()
> method and release it in the stop() method.
>
> However, some clients don't necessarily retain the reference, they get the
> instance for a specific operation, then release it immediately (in nice
> try...finally blocks).  When they release it, the usage count goes to zero,
> and ungetService() is called on the ServiceFactory, which duly performs
> cleanup.  This is where the trouble starts, because then the client
> requests it again at some later point, and as per the JavaDocs for
> ServiceFactory, it's the original cached proxy instance (the one that's
> already been cleaned up) that gets returned, without the ServiceFactory's
> getService() method being called.
>
> So I can't reactivate it, I can't provide a new proxy, and the client gets
> an obsolete instance.

Either (1) this is a bug in the framework or (2) you are not seeing what 
you think you are seeing. If you look in the source code of the 
framework in ServiceRegistry.ungetService() you can see that it 
definitely at least attempts to flush the cache when the usage count 
reaches zero.

If this is not happening, then create an issue in JIRA and attach an 
example to demonstrate. Thanks.

-> richard

>
> What should I do?  I did try doing stuff like calling unregister() on the
> ServiceRegistration passed to ungetService() but that didn't seem to help.
>
> Thanks in advance,
> Christopher Brown
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org