subject:"\[osgi\-dev\] Intermittent failure to getService"

Re: [osgi-dev] Intermittent failure to getService

2020-03-11 Thread Mark Hoffmann via osgi-dev


Hi Alain,

Am 11.03.20 um 15:29 schrieb Alain Picard:

Mark,

Thanks for the info. Just as a side note we are using EMF with CDO 
here and I'll double check but I believe we have this correctly 
managed, but I'm aware of some CME issues that can sometimes happen, 
even in a normal RCP application when dealing with itemProviders for 
example.


Exact, that comes, when certain operations, like adding items are not 
done in the UIThread in the RCP. If loading of instance is done in a 
different thread, you have to use the pattern Display#syncExec for those 
operations.


The same applies to OSGi. CDO is also not thread safe, it just ships 
around such problems using transactional commands.


The general problem with the CME aare that especiall in DS it may be 
possible that you dont expect them in e.g. activate callbacks.


Mark



Cheers,
Alain


On Wed, Mar 11, 2020 at 10:18 AM Mark Hoffmann via osgi-dev 
mailto:osgi-dev@mail.osgi.org>> wrote:


Hi Alain,

a little bit late but maybe some side notes to EMF and OSGi. EMF
is not thread-safe. May it be possible that you share one
ResourceSet/Resource over many Prototype instances?

This is in general not a good idea. In case you use EMF with
Equinox, you should give each prototype instance an own
ResourceSet instance. Otherwise you will sooner or later run into
ConcurrentModificationException when adding/removing Resources
to/from a ResourceSet. In any case sharing a ResourceSet over
Prototype instance will also lead to memory leaking over the time,
if you do not remove/cleanup the Resources after using them.

Using EObjects in a detached state can be helpful, but is not
useful for some use-cases e.g. Validation / Compare, because you
have to attach the objects before doing something.

You can also take look at our GeckoEMF. We have ResourceSets as a
service, also as PROTOTYPE scoped. So you can get an own
ResourceSet instance injected. We also have a ResourceSetFactory,
that can create ResourceSets. This solves many problems using EMF
in pure OSGi. There is also a Thread-safe ResourceSet
implementation regarding the usage of Resources

https://gitlab.com/gecko.io/geckoEMF

Mark

Am 11.03.20 um 13:26 schrieb Alain Picard via osgi-dev:

Peter and Tim,

Thanks for the pointers. The error was caused by some invalid use
of a disposed object. This was using factory components and I
switched all of it to use prototype components instead which IMHO
are easier to manage.

And Peter to your question about using prototype scope, those
objects contain state and it is my understanding that prototype
scope is required in those cases.

Thanks
Alain


On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens
mailto:peter.kri...@aqute.biz>> wrote:

Some remarks:

* Yes, it is thread safe. In OSGi we mark all thread safe
types with the @ThreadSafe annotation.
* The error message is not in the log you listed. Since the
log contains a deactivation message, I hope you're handling
the case corrected that you're being called after
deactivation? Seems too simple, but anyway ... :-)

* And for something completely different, is there any reason
you use the prototype scope? You real code might need it but
for this code it just looks like making it accidentally complex?
* And last but not least, you seem to be using slf4j? Did you
wire up the OSGi log to it? I've seen cases where the
information was in the OSGi log but those messages were
discarded.

Kind regards,

Peter Kriens



On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Question: The method getDiagnosticForEObject can be called
by different threads. Can this be the source of the issue? I
see that ComponentServiceObject is tagged as ThreadSafe, but?

Alain


On Mon, Mar 2, 2020 at 5:47 AM Alain Picard
mailto:pic...@castortech.com>> wrote:

Tim,

I don't think so. BaValidationManagerExt is used in only
1 place and it is instantiated in activate and released
in deactivate:
@Component(
factory = ValidationManager.CONFIG_FACTORY,
service = ValidationManager.class
)
public final class CoreValidationManager extends
CDODefaultTransactionHandler1 implements ValidationManager,
CDOTransactionHandler2 {
...
@Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
private ComponentServiceObjects
extenderFactory;
private ValidationManagerExt extender;

@Activate
private void activate() {
log.trace("Activating {}", getClass()); //$NON-NLS-1$

extender =

Re: [osgi-dev] Intermittent failure to getService

2020-03-11 Thread Alain Picard via osgi-dev

Mark,

Thanks for the info. Just as a side note we are using EMF with CDO here and
I'll double check but I believe we have this correctly managed, but I'm
aware of some CME issues that can sometimes happen, even in a normal RCP
application when dealing with itemProviders for example.

Cheers,
Alain


On Wed, Mar 11, 2020 at 10:18 AM Mark Hoffmann via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi Alain,
>
> a little bit late but maybe some side notes to EMF and OSGi. EMF is not
> thread-safe. May it be possible that you share one ResourceSet/Resource
> over many Prototype instances?
>
> This is in general not a good idea. In case you use EMF with Equinox, you
> should give each prototype instance an own ResourceSet instance. Otherwise
> you will sooner or later run into ConcurrentModificationException when
> adding/removing Resources to/from a ResourceSet. In any case sharing a
> ResourceSet over Prototype instance will also lead to memory leaking over
> the time, if you do not remove/cleanup the Resources after using them.
>
> Using EObjects in a detached state can be helpful, but is not useful for
> some use-cases e.g. Validation / Compare, because you have to attach the
> objects before doing something.
>
> You can also take look at our GeckoEMF. We have ResourceSets as a service,
> also as PROTOTYPE scoped. So you can get an own ResourceSet instance
> injected. We also have a ResourceSetFactory, that can create ResourceSets.
> This solves many problems using EMF in pure OSGi. There is also a
> Thread-safe ResourceSet implementation regarding the usage of Resources
>
> https://gitlab.com/gecko.io/geckoEMF
>
> Mark
> Am 11.03.20 um 13:26 schrieb Alain Picard via osgi-dev:
>
> Peter and Tim,
>
> Thanks for the pointers. The error was caused by some invalid use of a
> disposed object. This was using factory components and I switched all of it
> to use prototype components instead which IMHO are easier to manage.
>
> And Peter to your question about using prototype scope, those objects
> contain state and it is my understanding that prototype scope is required
> in those cases.
>
> Thanks
> Alain
>
>
> On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens 
> wrote:
>
>> Some remarks:
>>
>> * Yes, it is thread safe. In OSGi we mark all thread safe types with the
>> @ThreadSafe annotation.
>> * The error message is not in the log you listed. Since the log contains
>> a deactivation message, I hope you're handling the case corrected that
>> you're being called after deactivation? Seems too simple, but anyway ... :-)
>>
>> * And for something completely different, is there any reason you use the
>> prototype scope? You real code might need it but for this code it just
>> looks like making it accidentally complex?
>> * And last but not least, you seem to be using slf4j? Did you wire up the
>> OSGi log to it? I've seen cases where the information was in the OSGi log
>> but those messages were discarded.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>> Question: The method getDiagnosticForEObject can be called by different
>> threads. Can this be the source of the issue? I see that
>> ComponentServiceObject is tagged as ThreadSafe, but?
>>
>> Alain
>>
>>
>> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard 
>> wrote:
>>
>>> Tim,
>>>
>>> I don't think so. BaValidationManagerExt is used in only 1 place and it
>>> is instantiated in activate and released in deactivate:
>>> @Component(
>>> factory = ValidationManager.CONFIG_FACTORY,
>>> service = ValidationManager.class
>>> )
>>> public final class CoreValidationManager extends
>>> CDODefaultTransactionHandler1 implements ValidationManager,
>>> CDOTransactionHandler2 {
>>> ...
>>> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
>>> private ComponentServiceObjects extenderFactory;
>>> private ValidationManagerExt extender;
>>>
>>> @Activate
>>> private void activate() {
>>> log.trace("Activating {}", getClass()); //$NON-NLS-1$
>>>
>>> extender = extenderFactory.getService();
>>> }
>>>
>>> @Deactivate
>>> private void deactivate() {
>>> log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
>>> extenderFactory.ungetService(extender);
>>> }
>>>
>>> Cheers,
>>> Alain
>>>
>>> Alain Picard
>>> Chief Strategy Officer
>>> Castor Technologies Inc
>>> o:514-360-7208
>>> m:813-787-3424
>>>
>>> pic...@castortech.com
>>> www.castortech.com
>>>
>>>
>>> On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  wrote:
>>>
 Hi Alain,

 Is it possible that someone has a reference to a BaValidationManagerExt
 service instance that they aren’t releasing after ungetting it (or that
 they’re holding onto after it has been unregistered)? It might be an SCR
 bug, but it’s more likely to be some code holding onto a component instance
 that it shouldn’t.

 Best Regards,

 Tim

 On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev <
 osgi-dev@mail.osgi.org> wrote:

Re: [osgi-dev] Intermittent failure to getService

2020-03-11 Thread Mark Hoffmann via osgi-dev


Hi Alain,

a little bit late but maybe some side notes to EMF and OSGi. EMF is not 
thread-safe. May it be possible that you share one ResourceSet/Resource 
over many Prototype instances?


This is in general not a good idea. In case you use EMF with Equinox, 
you should give each prototype instance an own ResourceSet instance. 
Otherwise you will sooner or later run into 
ConcurrentModificationException when adding/removing Resources to/from a 
ResourceSet. In any case sharing a ResourceSet over Prototype instance 
will also lead to memory leaking over the time, if you do not 
remove/cleanup the Resources after using them.


Using EObjects in a detached state can be helpful, but is not useful for 
some use-cases e.g. Validation / Compare, because you have to attach the 
objects before doing something.


You can also take look at our GeckoEMF. We have ResourceSets as a 
service, also as PROTOTYPE scoped. So you can get an own ResourceSet 
instance injected. We also have a ResourceSetFactory, that can create 
ResourceSets. This solves many problems using EMF in pure OSGi. There is 
also a Thread-safe ResourceSet implementation regarding the usage of 
Resources


https://gitlab.com/gecko.io/geckoEMF

Mark

Am 11.03.20 um 13:26 schrieb Alain Picard via osgi-dev:

Peter and Tim,

Thanks for the pointers. The error was caused by some invalid use of a 
disposed object. This was using factory components and I switched all 
of it to use prototype components instead which IMHO are easier to manage.


And Peter to your question about using prototype scope, those objects 
contain state and it is my understanding that prototype scope is 
required in those cases.


Thanks
Alain


On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens > wrote:


Some remarks:

* Yes, it is thread safe. In OSGi we mark all thread safe types
with the @ThreadSafe annotation.
* The error message is not in the log you listed. Since the log
contains a deactivation message, I hope you're handling the case
corrected that you're being called after deactivation? Seems too
simple, but anyway ... :-)

* And for something completely different, is there any reason you
use the prototype scope? You real code might need it but for this
code it just looks like making it accidentally complex?
* And last but not least, you seem to be using slf4j? Did you wire
up the OSGi log to it? I've seen cases where the information was
in the OSGi log but those messages were discarded.

Kind regards,

Peter Kriens



On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Question: The method getDiagnosticForEObject can be called by
different threads. Can this be the source of the issue? I see
that ComponentServiceObject is tagged as ThreadSafe, but?

Alain


On Mon, Mar 2, 2020 at 5:47 AM Alain Picard
mailto:pic...@castortech.com>> wrote:

Tim,

I don't think so. BaValidationManagerExt is used in only 1
place and it is instantiated in activate and released in
deactivate:
@Component(
factory = ValidationManager.CONFIG_FACTORY,
service = ValidationManager.class
)
public final class CoreValidationManager extends
CDODefaultTransactionHandler1 implements ValidationManager,
CDOTransactionHandler2 {
...
@Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
private ComponentServiceObjects
extenderFactory;
private ValidationManagerExt extender;

@Activate
private void activate() {
log.trace("Activating {}", getClass()); //$NON-NLS-1$

extender = extenderFactory.getService();
}

@Deactivate
private void deactivate() {
log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
extenderFactory.ungetService(extender);
}

Cheers,
Alain

Alain Picard
Chief Strategy Officer
Castor Technologies Inc
o:514-360-7208
m:813-787-3424

pic...@castortech.com 
www.castortech.com 


On Mon, Mar 2, 2020 at 3:40 AM Tim Ward mailto:tim.w...@paremus.com>> wrote:

Hi Alain,

Is it possible that someone has a reference to a
BaValidationManagerExt service instance that they aren’t
releasing after ungetting it (or that they’re holding
onto after it has been unregistered)? It might be an SCR
bug, but it’s more likely to be some code holding onto a
component instance that it shouldn’t.

Best Regards,

Tim


On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev
mailto:osgi-dev@mail.osgi.org>>
wrote:

Hi

I am having a very intermittent issue with getService on

Re: [osgi-dev] Intermittent failure to getService

2020-03-11 Thread Raymond Auge via osgi-dev

On Wed, Mar 11, 2020 at 10:02 AM Raymond Auge 
wrote:

> Prototype scope is super important. It's true we don't have a huge number
> of uses (it may be less than 1% of all services), but where you need them
> they are incredibly useful, particularly in modelling behaviours defined
> outside the realm of OSGi.
>
> For instance, JAX-RS expects resources to be instantiated per request
> (where it can do it's own internal form of injection) so publishing a
> resource as a service really should be done as prototype scope otherwise
> you will surely mess up your state.
>
> CDI expects (Portable) Extensions to be instantiated exactly one time (and
> can have their own state since they are also injected as beans) and so,
> since the OSGi CDI bundle
>

read "CDI container within a CDI bundle can be restarted"


> can be restarted AND in order to support legacy Extension implementations
> you have to pretty much assure that these are provided as prototype scope
> services so that you never reuse the instances.
>
> So these have many real uses where otherwise you'd be forced to use a
> non-osgi factory model.
>
> - Ray
>
>
>
> On Wed, Mar 11, 2020 at 9:30 AM Peter Kriens via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> It all depends ... In general state can be managed in many different
>> ways. Prototype scope is too much in your face, too much boilerplate, that
>> is why I avoid it. It works nicely behind the scenes though like DS and
>> CDI. I do not think I've ever used them so far. (Which is a self
>> perpetuating truth, I know.)
>>
>> PK
>>
>>
>>
>> On 11 Mar 2020, at 13:26, Alain Picard  wrote:
>>
>> Peter and Tim,
>>
>> Thanks for the pointers. The error was caused by some invalid use of a
>> disposed object. This was using factory components and I switched all of it
>> to use prototype components instead which IMHO are easier to manage.
>>
>> And Peter to your question about using prototype scope, those objects
>> contain state and it is my understanding that prototype scope is required
>> in those cases.
>>
>> Thanks
>> Alain
>>
>>
>> On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens 
>> wrote:
>>
>>> Some remarks:
>>>
>>> * Yes, it is thread safe. In OSGi we mark all thread safe types with the
>>> @ThreadSafe annotation.
>>> * The error message is not in the log you listed. Since the log contains
>>> a deactivation message, I hope you're handling the case corrected that
>>> you're being called after deactivation? Seems too simple, but anyway ... :-)
>>>
>>> * And for something completely different, is there any reason you use
>>> the prototype scope? You real code might need it but for this code it just
>>> looks like making it accidentally complex?
>>> * And last but not least, you seem to be using slf4j? Did you wire up
>>> the OSGi log to it? I've seen cases where the information was in the OSGi
>>> log but those messages were discarded.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
>>> Question: The method getDiagnosticForEObject can be called by different
>>> threads. Can this be the source of the issue? I see that
>>> ComponentServiceObject is tagged as ThreadSafe, but?
>>>
>>> Alain
>>>
>>>
>>> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard 
>>> wrote:
>>>
 Tim,

 I don't think so. BaValidationManagerExt is used in only 1 place and it
 is instantiated in activate and released in deactivate:
 @Component(
 factory = ValidationManager.CONFIG_FACTORY,
 service = ValidationManager.class
 )
 public final class CoreValidationManager extends
 CDODefaultTransactionHandler1 implements ValidationManager,
 CDOTransactionHandler2 {
 ...
 @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
 private ComponentServiceObjects extenderFactory;
 private ValidationManagerExt extender;

 @Activate
 private void activate() {
 log.trace("Activating {}", getClass()); //$NON-NLS-1$

 extender = extenderFactory.getService();
 }

 @Deactivate
 private void deactivate() {
 log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
 extenderFactory.ungetService(extender);
 }

 Cheers,
 Alain

 Alain Picard
 Chief Strategy Officer
 Castor Technologies Inc
 o:514-360-7208
 m:813-787-3424

 pic...@castortech.com
 www.castortech.com


 On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  wrote:

> Hi Alain,
>
> Is it possible that someone has a reference to a
> BaValidationManagerExt service instance that they aren’t releasing after
> ungetting it (or that they’re holding onto after it has been 
> unregistered)?
> It might be an SCR bug, but it’s more likely to be some code holding onto 
> a
> component instance that it shouldn’t.
>
> Best Regards,
>
> Tim
>
> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev <
>

Re: [osgi-dev] Intermittent failure to getService

2020-03-11 Thread Raymond Auge via osgi-dev

Prototype scope is super important. It's true we don't have a huge number
of uses (it may be less than 1% of all services), but where you need them
they are incredibly useful, particularly in modelling behaviours defined
outside the realm of OSGi.

For instance, JAX-RS expects resources to be instantiated per request
(where it can do it's own internal form of injection) so publishing a
resource as a service really should be done as prototype scope otherwise
you will surely mess up your state.

CDI expects (Portable) Extensions to be instantiated exactly one time (and
can have their own state since they are also injected as beans) and so,
since the OSGi CDI bundle can be restarted AND in order to support legacy
Extension implementations you have to pretty much assure that these are
provided as prototype scope services so that you never reuse the instances.

So these have many real uses where otherwise you'd be forced to use a
non-osgi factory model.

- Ray

On Wed, Mar 11, 2020 at 9:30 AM Peter Kriens via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> It all depends ... In general state can be managed in many different ways.
> Prototype scope is too much in your face, too much boilerplate, that is why
> I avoid it. It works nicely behind the scenes though like DS and CDI. I do
> not think I've ever used them so far. (Which is a self perpetuating truth,
> I know.)
>
> PK
>
>
>
> On 11 Mar 2020, at 13:26, Alain Picard  wrote:
>
> Peter and Tim,
>
> Thanks for the pointers. The error was caused by some invalid use of a
> disposed object. This was using factory components and I switched all of it
> to use prototype components instead which IMHO are easier to manage.
>
> And Peter to your question about using prototype scope, those objects
> contain state and it is my understanding that prototype scope is required
> in those cases.
>
> Thanks
> Alain
>
>
> On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens 
> wrote:
>
>> Some remarks:
>>
>> * Yes, it is thread safe. In OSGi we mark all thread safe types with the
>> @ThreadSafe annotation.
>> * The error message is not in the log you listed. Since the log contains
>> a deactivation message, I hope you're handling the case corrected that
>> you're being called after deactivation? Seems too simple, but anyway ... :-)
>>
>> * And for something completely different, is there any reason you use the
>> prototype scope? You real code might need it but for this code it just
>> looks like making it accidentally complex?
>> * And last but not least, you seem to be using slf4j? Did you wire up the
>> OSGi log to it? I've seen cases where the information was in the OSGi log
>> but those messages were discarded.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>> Question: The method getDiagnosticForEObject can be called by different
>> threads. Can this be the source of the issue? I see that
>> ComponentServiceObject is tagged as ThreadSafe, but?
>>
>> Alain
>>
>>
>> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard 
>> wrote:
>>
>>> Tim,
>>>
>>> I don't think so. BaValidationManagerExt is used in only 1 place and it
>>> is instantiated in activate and released in deactivate:
>>> @Component(
>>> factory = ValidationManager.CONFIG_FACTORY,
>>> service = ValidationManager.class
>>> )
>>> public final class CoreValidationManager extends
>>> CDODefaultTransactionHandler1 implements ValidationManager,
>>> CDOTransactionHandler2 {
>>> ...
>>> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
>>> private ComponentServiceObjects extenderFactory;
>>> private ValidationManagerExt extender;
>>>
>>> @Activate
>>> private void activate() {
>>> log.trace("Activating {}", getClass()); //$NON-NLS-1$
>>>
>>> extender = extenderFactory.getService();
>>> }
>>>
>>> @Deactivate
>>> private void deactivate() {
>>> log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
>>> extenderFactory.ungetService(extender);
>>> }
>>>
>>> Cheers,
>>> Alain
>>>
>>> Alain Picard
>>> Chief Strategy Officer
>>> Castor Technologies Inc
>>> o:514-360-7208
>>> m:813-787-3424
>>>
>>> pic...@castortech.com
>>> www.castortech.com
>>>
>>>
>>> On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  wrote:
>>>
 Hi Alain,

 Is it possible that someone has a reference to a BaValidationManagerExt
 service instance that they aren’t releasing after ungetting it (or that
 they’re holding onto after it has been unregistered)? It might be an SCR
 bug, but it’s more likely to be some code holding onto a component instance
 that it shouldn’t.

 Best Regards,

 Tim

 On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev <
 osgi-dev@mail.osgi.org> wrote:

 Hi

 I am having a very intermittent issue with getService on a prototype
 component. This is called hundreds of times and I put a breakpoint a few
 weeks ago and have now gotten the error.

 I have this class:

Re: [osgi-dev] Intermittent failure to getService

2020-03-11 Thread Peter Kriens via osgi-dev

It all depends ... In general state can be managed in many different ways. 
Prototype scope is too much in your face, too much boilerplate, that is why I 
avoid it. It works nicely behind the scenes though like DS and CDI. I do not 
think I've ever used them so far. (Which is a self perpetuating truth, I know.)

PK



> On 11 Mar 2020, at 13:26, Alain Picard  wrote:
> 
> Peter and Tim,
> 
> Thanks for the pointers. The error was caused by some invalid use of a 
> disposed object. This was using factory components and I switched all of it 
> to use prototype components instead which IMHO are easier to manage.
> 
> And Peter to your question about using prototype scope, those objects contain 
> state and it is my understanding that prototype scope is required in those 
> cases.
> 
> Thanks
> Alain
> 
> 
> On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens  > wrote:
> Some remarks:
> 
> * Yes, it is thread safe. In OSGi we mark all thread safe types with the 
> @ThreadSafe annotation.
> * The error message is not in the log you listed. Since the log contains a 
> deactivation message, I hope you're handling the case corrected that you're 
> being called after deactivation? Seems too simple, but anyway ... :-)
> 
> * And for something completely different, is there any reason you use the 
> prototype scope? You real code might need it but for this code it just looks 
> like making it accidentally complex?
> * And last but not least, you seem to be using slf4j? Did you wire up the 
> OSGi log to it? I've seen cases where the information was in the OSGi log but 
> those messages were discarded.
> 
> Kind regards,
> 
>   Peter Kriens
> 
> 
>> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev > > wrote:
>> 
>> Question: The method getDiagnosticForEObject can be called by different 
>> threads. Can this be the source of the issue? I see that 
>> ComponentServiceObject is tagged as ThreadSafe, but?
>> 
>> Alain
>> 
>> 
>> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard > > wrote:
>> Tim,
>> 
>> I don't think so. BaValidationManagerExt is used in only 1 place and it is 
>> instantiated in activate and released in deactivate:
>> @Component(
>> factory = ValidationManager.CONFIG_FACTORY, 
>> service = ValidationManager.class
>> )
>> public final class CoreValidationManager extends 
>> CDODefaultTransactionHandler1 implements ValidationManager, 
>> CDOTransactionHandler2 {
>> ...
>> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
>> private ComponentServiceObjects extenderFactory;
>> private ValidationManagerExt extender;
>> 
>> @Activate
>> private void activate() {
>> log.trace("Activating {}", getClass()); //$NON-NLS-1$
>> 
>> extender = extenderFactory.getService();
>> }
>> 
>> @Deactivate
>> private void deactivate() {
>> log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
>> extenderFactory.ungetService(extender);
>> }
>> 
>> Cheers,
>> Alain
>> 
>> Alain Picard
>> Chief Strategy Officer
>> Castor Technologies Inc
>> o:514-360-7208
>> m:813-787-3424
>> 
>> pic...@castortech.com 
>> www.castortech.com 
>> 
>> On Mon, Mar 2, 2020 at 3:40 AM Tim Ward > > wrote:
>> Hi Alain,
>> 
>> Is it possible that someone has a reference to a BaValidationManagerExt 
>> service instance that they aren’t releasing after ungetting it (or that 
>> they’re holding onto after it has been unregistered)? It might be an SCR 
>> bug, but it’s more likely to be some code holding onto a component instance 
>> that it shouldn’t.
>> 
>> Best Regards,
>> 
>> Tim
>> 
>>> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev >> > wrote:
>>> 
>>> Hi
>>> 
>>> I am having a very intermittent issue with getService on a prototype 
>>> component. This is called hundreds of times and I put a breakpoint a few 
>>> weeks ago and have now gotten the error.
>>> 
>>> I have this class:
>>> @Component(scope=ServiceScope.PROTOTYPE,
>>> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
>>> )
>>> public final class BaValidationManagerExt implements ValidationManagerExt {
>>> private final Logger log = LoggerFactory.getLogger(getClass());
>>> 
>>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
>>> private ComponentServiceObjects validatorFactory;
>>> 
>>> @Activate
>>> private void activate() {
>>> log.trace("Activating {}/{}", getClass(), System.identityHashCode(this)); 
>>> //$NON-NLS-1$
>>> }
>>> 
>>> @Deactivate
>>> private void deactivate() {
>>> log.trace("Deactivating {}/{}", getClass(), System.identityHashCode(this)); 
>>> //$NON-NLS-1$
>>> }
>>> 
>>> @Override
>>> public Diagnostic getDiagnosticForEObject(EObject eObj) {
>>> log.trace("Getting diagnostic for {}", eObj); //$NON-NLS-1$
>>> Validator validator = validatorFactory.getService();
>>> 
>>> if (validator != null) {
>>> try {
>>> return

Re: [osgi-dev] Intermittent failure to getService

2020-03-11 Thread Alain Picard via osgi-dev

Peter and Tim,

Thanks for the pointers. The error was caused by some invalid use of a
disposed object. This was using factory components and I switched all of it
to use prototype components instead which IMHO are easier to manage.

And Peter to your question about using prototype scope, those objects
contain state and it is my understanding that prototype scope is required
in those cases.

Thanks
Alain


On Mon, Mar 2, 2020 at 9:39 AM Peter Kriens  wrote:

> Some remarks:
>
> * Yes, it is thread safe. In OSGi we mark all thread safe types with the
> @ThreadSafe annotation.
> * The error message is not in the log you listed. Since the log contains a
> deactivation message, I hope you're handling the case corrected that you're
> being called after deactivation? Seems too simple, but anyway ... :-)
>
> * And for something completely different, is there any reason you use the
> prototype scope? You real code might need it but for this code it just
> looks like making it accidentally complex?
> * And last but not least, you seem to be using slf4j? Did you wire up the
> OSGi log to it? I've seen cases where the information was in the OSGi log
> but those messages were discarded.
>
> Kind regards,
>
> Peter Kriens
>
>
> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev 
> wrote:
>
> Question: The method getDiagnosticForEObject can be called by different
> threads. Can this be the source of the issue? I see that
> ComponentServiceObject is tagged as ThreadSafe, but?
>
> Alain
>
>
> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard  wrote:
>
>> Tim,
>>
>> I don't think so. BaValidationManagerExt is used in only 1 place and it
>> is instantiated in activate and released in deactivate:
>> @Component(
>> factory = ValidationManager.CONFIG_FACTORY,
>> service = ValidationManager.class
>> )
>> public final class CoreValidationManager extends
>> CDODefaultTransactionHandler1 implements ValidationManager,
>> CDOTransactionHandler2 {
>> ...
>> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
>> private ComponentServiceObjects extenderFactory;
>> private ValidationManagerExt extender;
>>
>> @Activate
>> private void activate() {
>> log.trace("Activating {}", getClass()); //$NON-NLS-1$
>>
>> extender = extenderFactory.getService();
>> }
>>
>> @Deactivate
>> private void deactivate() {
>> log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
>> extenderFactory.ungetService(extender);
>> }
>>
>> Cheers,
>> Alain
>>
>> Alain Picard
>> Chief Strategy Officer
>> Castor Technologies Inc
>> o:514-360-7208
>> m:813-787-3424
>>
>> pic...@castortech.com
>> www.castortech.com
>>
>>
>> On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  wrote:
>>
>>> Hi Alain,
>>>
>>> Is it possible that someone has a reference to a BaValidationManagerExt
>>> service instance that they aren’t releasing after ungetting it (or that
>>> they’re holding onto after it has been unregistered)? It might be an SCR
>>> bug, but it’s more likely to be some code holding onto a component instance
>>> that it shouldn’t.
>>>
>>> Best Regards,
>>>
>>> Tim
>>>
>>> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
>>> Hi
>>>
>>> I am having a very intermittent issue with getService on a prototype
>>> component. This is called hundreds of times and I put a breakpoint a few
>>> weeks ago and have now gotten the error.
>>>
>>> I have this class:
>>> @Component(scope=ServiceScope.PROTOTYPE,
>>> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
>>> )
>>> public final class BaValidationManagerExt implements
>>> ValidationManagerExt {
>>> private final Logger log = LoggerFactory.getLogger(getClass());
>>>
>>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
>>> private ComponentServiceObjects validatorFactory;
>>>
>>> @Activate
>>> private void activate() {
>>> log.trace("Activating {}/{}", getClass(),
>>> System.identityHashCode(this)); //$NON-NLS-1$
>>> }
>>>
>>> @Deactivate
>>> private void deactivate() {
>>> log.trace("Deactivating {}/{}", getClass(),
>>> System.identityHashCode(this)); //$NON-NLS-1$
>>> }
>>> 
>>> @Override
>>> public Diagnostic getDiagnosticForEObject(EObject eObj) {
>>> log.trace("Getting diagnostic for {}", eObj); //$NON-NLS-1$
>>> Validator validator = validatorFactory.getService();
>>>
>>> if (validator != null) {
>>> try {
>>> return validator.runValidation(false, Collections.singletonMap(eObj, new
>>> HashSet<>()),
>>> new NullProgressMonitor()).getB();
>>> }
>>> finally {
>>> validatorFactory.ungetService(validator);
>>> }
>>> }
>>> else {
>>> log.error("Validator Service not found for {}", eObj, new Throwable());
>>> //$NON-NLS-1$
>>> return Diagnostic.CANCEL_INSTANCE;
>>> }
>>> }
>>> }
>>>
>>> and the validator:
>>> @Component(
>>> scope = ServiceScope.PROTOTYPE,
>>> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
>>> )
>>> public final class BaValidator implements Validator {
>>> private final Logger log = LoggerFactory.getLogger(getClass());
>>>
>>> private

Re: [osgi-dev] Intermittent failure to getService

2020-03-02 Thread Peter Kriens via osgi-dev

Some remarks:

* Yes, it is thread safe. In OSGi we mark all thread safe types with the 
@ThreadSafe annotation.
* The error message is not in the log you listed. Since the log contains a 
deactivation message, I hope you're handling the case corrected that you're 
being called after deactivation? Seems too simple, but anyway ... :-)

* And for something completely different, is there any reason you use the 
prototype scope? You real code might need it but for this code it just looks 
like making it accidentally complex?
* And last but not least, you seem to be using slf4j? Did you wire up the OSGi 
log to it? I've seen cases where the information was in the OSGi log but those 
messages were discarded.

Kind regards,

Peter Kriens


> On 2 Mar 2020, at 12:03, Alain Picard via osgi-dev  
> wrote:
> 
> Question: The method getDiagnosticForEObject can be called by different 
> threads. Can this be the source of the issue? I see that 
> ComponentServiceObject is tagged as ThreadSafe, but?
> 
> Alain
> 
> 
> On Mon, Mar 2, 2020 at 5:47 AM Alain Picard  > wrote:
> Tim,
> 
> I don't think so. BaValidationManagerExt is used in only 1 place and it is 
> instantiated in activate and released in deactivate:
> @Component(
> factory = ValidationManager.CONFIG_FACTORY, 
> service = ValidationManager.class
> )
> public final class CoreValidationManager extends 
> CDODefaultTransactionHandler1 implements ValidationManager, 
> CDOTransactionHandler2 {
> ...
> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
> private ComponentServiceObjects extenderFactory;
> private ValidationManagerExt extender;
> 
> @Activate
> private void activate() {
> log.trace("Activating {}", getClass()); //$NON-NLS-1$
> 
> extender = extenderFactory.getService();
> }
> 
> @Deactivate
> private void deactivate() {
> log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
> extenderFactory.ungetService(extender);
> }
> 
> Cheers,
> Alain
> 
> Alain Picard
> Chief Strategy Officer
> Castor Technologies Inc
> o:514-360-7208
> m:813-787-3424
> 
> pic...@castortech.com 
> www.castortech.com 
> 
> On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  > wrote:
> Hi Alain,
> 
> Is it possible that someone has a reference to a BaValidationManagerExt 
> service instance that they aren’t releasing after ungetting it (or that 
> they’re holding onto after it has been unregistered)? It might be an SCR bug, 
> but it’s more likely to be some code holding onto a component instance that 
> it shouldn’t.
> 
> Best Regards,
> 
> Tim
> 
>> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev > > wrote:
>> 
>> Hi
>> 
>> I am having a very intermittent issue with getService on a prototype 
>> component. This is called hundreds of times and I put a breakpoint a few 
>> weeks ago and have now gotten the error.
>> 
>> I have this class:
>> @Component(scope=ServiceScope.PROTOTYPE,
>> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
>> )
>> public final class BaValidationManagerExt implements ValidationManagerExt {
>> private final Logger log = LoggerFactory.getLogger(getClass());
>> 
>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
>> private ComponentServiceObjects validatorFactory;
>> 
>> @Activate
>> private void activate() {
>> log.trace("Activating {}/{}", getClass(), System.identityHashCode(this)); 
>> //$NON-NLS-1$
>> }
>> 
>> @Deactivate
>> private void deactivate() {
>> log.trace("Deactivating {}/{}", getClass(), System.identityHashCode(this)); 
>> //$NON-NLS-1$
>> }
>> 
>> @Override
>> public Diagnostic getDiagnosticForEObject(EObject eObj) {
>> log.trace("Getting diagnostic for {}", eObj); //$NON-NLS-1$
>> Validator validator = validatorFactory.getService();
>> 
>> if (validator != null) {
>> try {
>> return validator.runValidation(false, Collections.singletonMap(eObj, new 
>> HashSet<>()),
>> new NullProgressMonitor()).getB();
>> }
>> finally {
>> validatorFactory.ungetService(validator);
>> }
>> }
>> else {
>> log.error("Validator Service not found for {}", eObj, new Throwable()); 
>> //$NON-NLS-1$
>> return Diagnostic.CANCEL_INSTANCE;
>> }
>> }
>> }
>> 
>> and the validator:
>> @Component(
>> scope = ServiceScope.PROTOTYPE,
>> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
>> )
>> public final class BaValidator implements Validator {
>> private final Logger log = LoggerFactory.getLogger(getClass());
>> 
>> private Map> elementsToValidate;
>> private Set validated = Sets.newHashSet();
>> private boolean batch;
>> 
>> private EditingDomain domain;
>> private AdapterFactory adapterFactory;
>> 
>> @Reference
>> private volatile List validationProviders;  //NOSONAR as 
>> per OSGi 112.3.9.1 
>> 
>> @Reference
>> private ValidationUtils validationUtils;
>> 
>> @Activate
>> private void activate() {
>> log.trace("Activating {}/{}", getClass(),

Re: [osgi-dev] Intermittent failure to getService

2020-03-02 Thread Alain Picard via osgi-dev

Question: The method getDiagnosticForEObject can be called by different
threads. Can this be the source of the issue? I see that
ComponentServiceObject is tagged as ThreadSafe, but?

Alain


On Mon, Mar 2, 2020 at 5:47 AM Alain Picard  wrote:

> Tim,
>
> I don't think so. BaValidationManagerExt is used in only 1 place and it is
> instantiated in activate and released in deactivate:
> @Component(
> factory = ValidationManager.CONFIG_FACTORY,
> service = ValidationManager.class
> )
> public final class CoreValidationManager extends
> CDODefaultTransactionHandler1 implements ValidationManager,
> CDOTransactionHandler2 {
> ...
> @Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
> private ComponentServiceObjects extenderFactory;
> private ValidationManagerExt extender;
>
> @Activate
> private void activate() {
> log.trace("Activating {}", getClass()); //$NON-NLS-1$
>
> extender = extenderFactory.getService();
> }
>
> @Deactivate
> private void deactivate() {
> log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
> extenderFactory.ungetService(extender);
> }
>
> Cheers,
> Alain
>
> Alain Picard
> Chief Strategy Officer
> Castor Technologies Inc
> o:514-360-7208
> m:813-787-3424
>
> pic...@castortech.com
> www.castortech.com
>
>
> On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  wrote:
>
>> Hi Alain,
>>
>> Is it possible that someone has a reference to a BaValidationManagerExt
>> service instance that they aren’t releasing after ungetting it (or that
>> they’re holding onto after it has been unregistered)? It might be an SCR
>> bug, but it’s more likely to be some code holding onto a component instance
>> that it shouldn’t.
>>
>> Best Regards,
>>
>> Tim
>>
>> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>> Hi
>>
>> I am having a very intermittent issue with getService on a prototype
>> component. This is called hundreds of times and I put a breakpoint a few
>> weeks ago and have now gotten the error.
>>
>> I have this class:
>> @Component(scope=ServiceScope.PROTOTYPE,
>> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
>> )
>> public final class BaValidationManagerExt implements ValidationManagerExt
>> {
>> private final Logger log = LoggerFactory.getLogger(getClass());
>>
>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
>> private ComponentServiceObjects validatorFactory;
>>
>> @Activate
>> private void activate() {
>> log.trace("Activating {}/{}", getClass(), System.identityHashCode(this));
>> //$NON-NLS-1$
>> }
>>
>> @Deactivate
>> private void deactivate() {
>> log.trace("Deactivating {}/{}", getClass(),
>> System.identityHashCode(this)); //$NON-NLS-1$
>> }
>> 
>> @Override
>> public Diagnostic getDiagnosticForEObject(EObject eObj) {
>> log.trace("Getting diagnostic for {}", eObj); //$NON-NLS-1$
>> Validator validator = validatorFactory.getService();
>>
>> if (validator != null) {
>> try {
>> return validator.runValidation(false, Collections.singletonMap(eObj, new
>> HashSet<>()),
>> new NullProgressMonitor()).getB();
>> }
>> finally {
>> validatorFactory.ungetService(validator);
>> }
>> }
>> else {
>> log.error("Validator Service not found for {}", eObj, new Throwable());
>> //$NON-NLS-1$
>> return Diagnostic.CANCEL_INSTANCE;
>> }
>> }
>> }
>>
>> and the validator:
>> @Component(
>> scope = ServiceScope.PROTOTYPE,
>> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
>> )
>> public final class BaValidator implements Validator {
>> private final Logger log = LoggerFactory.getLogger(getClass());
>>
>> private Map> elementsToValidate;
>> private Set validated = Sets.newHashSet();
>> private boolean batch;
>>
>> private EditingDomain domain;
>> private AdapterFactory adapterFactory;
>>
>> @Reference
>> private volatile List validationProviders;  //NOSONAR
>> as per OSGi 112.3.9.1
>>
>> @Reference
>> private ValidationUtils validationUtils;
>>
>> @Activate
>> private void activate() {
>> log.trace("Activating {}/{}", getClass(), System.identityHashCode(this));
>> //$NON-NLS-1$
>> }
>>
>> @Deactivate
>> private void deactivate() {
>> log.trace("Deactivating {}/{}", getClass(),
>> System.identityHashCode(this)); //$NON-NLS-1$
>> }
>> ...
>> }
>>
>> The error is on the highlighted line, which happens since getService
>> returns null.
>>
>> As can be seen here, ValidatorFactory serviceObjects is null which seems
>> to be what makes it return null:
>> ComponentServiceObjectsImpl [instances=[], serviceObjects=null,
>> deactivated=false, hashCode=301166435]
>>
>> I am not seeing any special in the logs (tracing is on). Just before I
>> see a number of successful call to the same code with the last one being:
>> just before in the logs:
>> 08:00:45.854 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator -
>> Activating class
>> com.castortech.iris.validation.ba.provider.BaValidator/1297753057
>> 08:00:45.857 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator -
>> Notify 4 listeners with diagnostics ([Diagnostic OK

Re: [osgi-dev] Intermittent failure to getService

2020-03-02 Thread Alain Picard via osgi-dev

Tim,

I don't think so. BaValidationManagerExt is used in only 1 place and it is
instantiated in activate and released in deactivate:
@Component(
factory = ValidationManager.CONFIG_FACTORY,
service = ValidationManager.class
)
public final class CoreValidationManager extends
CDODefaultTransactionHandler1 implements ValidationManager,
CDOTransactionHandler2 {
...
@Reference(scope=ReferenceScope.PROTOTYPE_REQUIRED)
private ComponentServiceObjects extenderFactory;
private ValidationManagerExt extender;

@Activate
private void activate() {
log.trace("Activating {}", getClass()); //$NON-NLS-1$

extender = extenderFactory.getService();
}

@Deactivate
private void deactivate() {
log.trace("Deactivating {}", getClass()); //$NON-NLS-1$
extenderFactory.ungetService(extender);
}

Cheers,
Alain

Alain Picard
Chief Strategy Officer
Castor Technologies Inc
o:514-360-7208
m:813-787-3424

pic...@castortech.com
www.castortech.com


On Mon, Mar 2, 2020 at 3:40 AM Tim Ward  wrote:

> Hi Alain,
>
> Is it possible that someone has a reference to a BaValidationManagerExt
> service instance that they aren’t releasing after ungetting it (or that
> they’re holding onto after it has been unregistered)? It might be an SCR
> bug, but it’s more likely to be some code holding onto a component instance
> that it shouldn’t.
>
> Best Regards,
>
> Tim
>
> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Hi
>
> I am having a very intermittent issue with getService on a prototype
> component. This is called hundreds of times and I put a breakpoint a few
> weeks ago and have now gotten the error.
>
> I have this class:
> @Component(scope=ServiceScope.PROTOTYPE,
> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
> )
> public final class BaValidationManagerExt implements ValidationManagerExt {
> private final Logger log = LoggerFactory.getLogger(getClass());
>
> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
> private ComponentServiceObjects validatorFactory;
>
> @Activate
> private void activate() {
> log.trace("Activating {}/{}", getClass(), System.identityHashCode(this));
> //$NON-NLS-1$
> }
>
> @Deactivate
> private void deactivate() {
> log.trace("Deactivating {}/{}", getClass(),
> System.identityHashCode(this)); //$NON-NLS-1$
> }
> 
> @Override
> public Diagnostic getDiagnosticForEObject(EObject eObj) {
> log.trace("Getting diagnostic for {}", eObj); //$NON-NLS-1$
> Validator validator = validatorFactory.getService();
>
> if (validator != null) {
> try {
> return validator.runValidation(false, Collections.singletonMap(eObj, new
> HashSet<>()),
> new NullProgressMonitor()).getB();
> }
> finally {
> validatorFactory.ungetService(validator);
> }
> }
> else {
> log.error("Validator Service not found for {}", eObj, new Throwable());
> //$NON-NLS-1$
> return Diagnostic.CANCEL_INSTANCE;
> }
> }
> }
>
> and the validator:
> @Component(
> scope = ServiceScope.PROTOTYPE,
> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
> )
> public final class BaValidator implements Validator {
> private final Logger log = LoggerFactory.getLogger(getClass());
>
> private Map> elementsToValidate;
> private Set validated = Sets.newHashSet();
> private boolean batch;
>
> private EditingDomain domain;
> private AdapterFactory adapterFactory;
>
> @Reference
> private volatile List validationProviders;  //NOSONAR
> as per OSGi 112.3.9.1
>
> @Reference
> private ValidationUtils validationUtils;
>
> @Activate
> private void activate() {
> log.trace("Activating {}/{}", getClass(), System.identityHashCode(this));
> //$NON-NLS-1$
> }
>
> @Deactivate
> private void deactivate() {
> log.trace("Deactivating {}/{}", getClass(),
> System.identityHashCode(this)); //$NON-NLS-1$
> }
> ...
> }
>
> The error is on the highlighted line, which happens since getService
> returns null.
>
> As can be seen here, ValidatorFactory serviceObjects is null which seems
> to be what makes it return null:
> ComponentServiceObjectsImpl [instances=[], serviceObjects=null,
> deactivated=false, hashCode=301166435]
>
> I am not seeing any special in the logs (tracing is on). Just before I see
> a number of successful call to the same code with the last one being:
> just before in the logs:
> 08:00:45.854 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator -
> Activating class
> com.castortech.iris.validation.ba.provider.BaValidator/1297753057
> 08:00:45.857 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator -
> Notify 4 listeners with diagnostics ([Diagnostic OK
> source=com.castortech.iris.ba.validation code=0
>  data=[RadialDiagramImpl{[cdoID->6558b1f9-dbcf-4e9d-b7b8-73779b5ada8f]
> 08:00:45.858 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator -
> Deactivating class
> com.castortech.iris.validation.ba.provider.BaValidator/1297753057
>
>
> Has anyone seen this before or can provide some pointers to address and/or
> debug this.
>
> Thanks
> Alain
>
>

Re: [osgi-dev] Intermittent failure to getService

2020-03-02 Thread Tim Ward via osgi-dev

Hi Alain,

Is it possible that someone has a reference to a BaValidationManagerExt service 
instance that they aren’t releasing after ungetting it (or that they’re holding 
onto after it has been unregistered)? It might be an SCR bug, but it’s more 
likely to be some code holding onto a component instance that it shouldn’t.

Best Regards,

Tim

> On 29 Feb 2020, at 13:29, Alain Picard via osgi-dev  
> wrote:
> 
> Hi
> 
> I am having a very intermittent issue with getService on a prototype 
> component. This is called hundreds of times and I put a breakpoint a few 
> weeks ago and have now gotten the error.
> 
> I have this class:
> @Component(scope=ServiceScope.PROTOTYPE,
> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
> )
> public final class BaValidationManagerExt implements ValidationManagerExt {
> private final Logger log = LoggerFactory.getLogger(getClass());
> 
> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
> private ComponentServiceObjects validatorFactory;
> 
> @Activate
> private void activate() {
> log.trace("Activating {}/{}", getClass(), System.identityHashCode(this)); 
> //$NON-NLS-1$
> }
> 
> @Deactivate
> private void deactivate() {
> log.trace("Deactivating {}/{}", getClass(), System.identityHashCode(this)); 
> //$NON-NLS-1$
> }
> 
> @Override
> public Diagnostic getDiagnosticForEObject(EObject eObj) {
> log.trace("Getting diagnostic for {}", eObj); //$NON-NLS-1$
> Validator validator = validatorFactory.getService();
> 
> if (validator != null) {
> try {
> return validator.runValidation(false, Collections.singletonMap(eObj, new 
> HashSet<>()),
> new NullProgressMonitor()).getB();
> }
> finally {
> validatorFactory.ungetService(validator);
> }
> }
> else {
> log.error("Validator Service not found for {}", eObj, new Throwable()); 
> //$NON-NLS-1$
> return Diagnostic.CANCEL_INSTANCE;
> }
> }
> }
> 
> and the validator:
> @Component(
> scope = ServiceScope.PROTOTYPE,
> property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
> )
> public final class BaValidator implements Validator {
> private final Logger log = LoggerFactory.getLogger(getClass());
> 
> private Map> elementsToValidate;
> private Set validated = Sets.newHashSet();
> private boolean batch;
> 
> private EditingDomain domain;
> private AdapterFactory adapterFactory;
> 
> @Reference
> private volatile List validationProviders;  //NOSONAR as 
> per OSGi 112.3.9.1 
> 
> @Reference
> private ValidationUtils validationUtils;
> 
> @Activate
> private void activate() {
> log.trace("Activating {}/{}", getClass(), System.identityHashCode(this)); 
> //$NON-NLS-1$
> }
> 
> @Deactivate
> private void deactivate() {
> log.trace("Deactivating {}/{}", getClass(), System.identityHashCode(this)); 
> //$NON-NLS-1$
> }
> ...
> } 
> 
> The error is on the highlighted line, which happens since getService returns 
> null.
> 
> As can be seen here, ValidatorFactory serviceObjects is null which seems to 
> be what makes it return null:
> ComponentServiceObjectsImpl [instances=[], serviceObjects=null, 
> deactivated=false, hashCode=301166435]
> 
> I am not seeing any special in the logs (tracing is on). Just before I see a 
> number of successful call to the same code with the last one being:
> just before in the logs:
> 08:00:45.854 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator - 
> Activating class 
> com.castortech.iris.validation.ba.provider.BaValidator/1297753057
> 08:00:45.857 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator - 
> Notify 4 listeners with diagnostics ([Diagnostic OK 
> source=com.castortech.iris.ba.validation code=0  
> data=[RadialDiagramImpl{[cdoID->6558b1f9-dbcf-4e9d-b7b8-73779b5ada8f]
> 08:00:45.858 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator - 
> Deactivating class 
> com.castortech.iris.validation.ba.provider.BaValidator/1297753057
> 
> 
> Has anyone seen this before or can provide some pointers to address and/or 
> debug this.
> 
> Thanks
> Alain
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Intermittent failure to getService

2020-02-29 Thread Alain Picard via osgi-dev

Hi

I am having a very intermittent issue with getService on a prototype
component. This is called hundreds of times and I put a breakpoint a few
weeks ago and have now gotten the error.

I have this class:
@Component(scope=ServiceScope.PROTOTYPE,
property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
)
public final class BaValidationManagerExt implements ValidationManagerExt {
private final Logger log = LoggerFactory.getLogger(getClass());

@Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED)
private ComponentServiceObjects validatorFactory;

@Activate
private void activate() {
log.trace("Activating {}/{}", getClass(), System.identityHashCode(this));
//$NON-NLS-1$
}

@Deactivate
private void deactivate() {
log.trace("Deactivating {}/{}", getClass(), System.identityHashCode(this));
//$NON-NLS-1$
}

@Override
public Diagnostic getDiagnosticForEObject(EObject eObj) {
log.trace("Getting diagnostic for {}", eObj); //$NON-NLS-1$
Validator validator = validatorFactory.getService();

if (validator != null) {
try {
return validator.runValidation(false, Collections.singletonMap(eObj, new
HashSet<>()),
new NullProgressMonitor()).getB();
}
finally {
validatorFactory.ungetService(validator);
}
}
else {
log.error("Validator Service not found for {}", eObj, new Throwable());
//$NON-NLS-1$
return Diagnostic.CANCEL_INSTANCE;
}
}
}

and the validator:
@Component(
scope = ServiceScope.PROTOTYPE,
property= org.osgi.framework.Constants.SERVICE_RANKING + ":Integer=10"
)
public final class BaValidator implements Validator {
private final Logger log = LoggerFactory.getLogger(getClass());

private Map> elementsToValidate;
private Set validated = Sets.newHashSet();
private boolean batch;

private EditingDomain domain;
private AdapterFactory adapterFactory;

@Reference
private volatile List validationProviders;  //NOSONAR
as per OSGi 112.3.9.1

@Reference
private ValidationUtils validationUtils;

@Activate
private void activate() {
log.trace("Activating {}/{}", getClass(), System.identityHashCode(this));
//$NON-NLS-1$
}

@Deactivate
private void deactivate() {
log.trace("Deactivating {}/{}", getClass(), System.identityHashCode(this));
//$NON-NLS-1$
}
...
}

The error is on the highlighted line, which happens since getService
returns null.

As can be seen here, ValidatorFactory serviceObjects is null which seems to
be what makes it return null:
ComponentServiceObjectsImpl [instances=[], serviceObjects=null,
deactivated=false, hashCode=301166435]

I am not seeing any special in the logs (tracing is on). Just before I see
a number of successful call to the same code with the last one being:
just before in the logs:
08:00:45.854 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator -
Activating class
com.castortech.iris.validation.ba.provider.BaValidator/1297753057
08:00:45.857 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator -
Notify 4 listeners with diagnostics ([Diagnostic OK
source=com.castortech.iris.ba.validation code=0
 data=[RadialDiagramImpl{[cdoID->6558b1f9-dbcf-4e9d-b7b8-73779b5ada8f]
08:00:45.858 [Worker-1: Create Diagram] TRACE c.c.i.v.b.p.BaValidator -
Deactivating class
com.castortech.iris.validation.ba.provider.BaValidator/1297753057


Has anyone seen this before or can provide some pointers to address and/or
debug this.

Thanks
Alain
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

Re: [osgi-dev] Intermittent failure to getService

[osgi-dev] Intermittent failure to getService

12 matches

Site Navigation

Mail list logo

Footer information