You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Alexander Broekhuis <a....@gmail.com> on 2009/12/07 14:01:55 UTC
[DOSGi] Nullpointer with 1.1 and discovery
Hi all,
When using the 1.1 release, I get a nullpointer if discovery is used:
*ERROR* {org.osgi.service.cm.
ManagedService}={service.pid=org.apache.cxf.dosgi.discovery.zookeeper,
zookeeper.port=2181, zookeeper.timeout=3000, service.id=38}: Unexpected
problem updating configuration
java.lang.NullPointerException
at
org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
at
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:959)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
I used the 1.1 snapshot before, and never had this problem with discovery.
Is there something I forgot?
I am using the singlebundle release with the latest (3.2.1) zookeeper.
--
Met vriendelijke groet,
Alexander Broekhuis
Re: [DOSGi] Nullpointer with 1.1 and discovery
Posted by David Bosschaert <da...@gmail.com>.
Hi Alex,
Thanks for testing it out.
I've committed the fix to trunk.
BTW I was also using the single bundle distro when testing this out...
Best regards,
David
2009/12/9 Alexander Broekhuis <a....@gmail.com>:
> Hi,
>
> Thx for the patch. This fixes my problem.
>
> Can it be that the problems does not occur when using the multi bundle
> distribution? I am using the singlebundle version.
> Not sure why I don't see it with the snapshot version. Can it be because of
> the two jar files (dosgi and discovery) vs one file now?
>
> Anyway, looking at the OSGi javadoc, the condition seems to be expected.
>
> Again, thanx for the quick fix!
>
> On Wed, Dec 9, 2009 at 12:16 PM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
>> Hi Alexander,
>>
>> I tried to reproduce your issue on both Windows XP and Linux (Ubuntu
>> 9.10) with JDK 1.6 but wasn't able to.
>>
>> As an experiment I modified the start and updated methods to be
>> synchronized in the Activator. I've attached source and .class files
>> in a zip.
>> Would you mind modifying your
>> cxf-dosgi-ri-discovery-distributed-1.1.jar file with the attached
>> Activator and see if that fixes it for you?
>>
>> BTW this file didn't change since early July so there shouldn't really
>> be any difference between 1.1 and the 1.1-SNAPSHOT that you had been
>> using before.
>>
>> Thanks,
>>
>> David
>>
>> 2009/12/9 Alexander Broekhuis <a....@gmail.com>:
>> > David,
>> >
>> > I tested with the discovery demo. On equinox as well as felix. It fails,
>> but
>> > not always. I can get it to always work, if I add the zookeeper.cfg to
>> the
>> > load directory after starting all services. But as soon as the cfg is in
>> the
>> > cache, a restart fails again.
>> >
>> > I looked at the source, and the only thing I can see is indeed a race
>> > condition at the updated callback. I guess services are registered before
>> > the register method is completely done and returned. So the config
>> manager
>> > already starts updating the managed services which leads to the
>> nullpointer.
>> >
>> > After reading the OSGi javadoc I think the start method has to be
>> > synchronized. From
>> >
>> http://www.osgi.org/javadoc/r2/org/osgi/service/cm/ManagedService.html#updated%28java.util.Dictionary%29
>> > :
>> > - The Configuration Admin service must call this method on a thread other
>> > than the thread which initiated the callback. This implies that
>> implementors
>> > of Managed Service can be assured that the callback will not take place
>> > during registration when they execute the registration in a synchronized
>> > method.
>> >
>> > While the stop is synchronized, the start isn't. Can this be the problem?
>> >
>> > Thanx in advance!
>> >
>> >
>> > On Mon, Dec 7, 2009 at 4:47 PM, David Bosschaert <
>> david.bosschaert@gmail.com
>> >> wrote:
>> >
>> >> Hi Alexander,
>> >>
>> >> I just walked through the Discovery Demo as described here:
>> >> http://cxf.apache.org/dosgi-discovery-demo-page.html
>> >> and it works fine for me.
>> >>
>> >> Looking at the source code where you get the exception:
>> >> > java.lang.NullPointerException
>> >> > at
>> >> >
>> >>
>> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
>> >>
>> >> to me it seems like the updated() callback is made before the
>> >> bundle.start() has returned. Hmmm, there might be a race condition
>> >> here ...
>> >>
>> >> Is it possible for you to provide a test case that consistently fails?
>> >> Otherwise, did you walk through the Discovery Demot page mentioned
>> >> above? Does that work for you?
>> >>
>> >> Thanks,
>> >>
>> >> David
>> >>
>> >> 2009/12/7 Alexander Broekhuis <a....@gmail.com>:
>> >> > Hi all,
>> >> >
>> >> > When using the 1.1 release, I get a nullpointer if discovery is used:
>> >> >
>> >> > *ERROR* {org.osgi.service.cm.
>> >> > ManagedService}={service.pid=org.apache.cxf.dosgi.discovery.zookeeper,
>> >> > zookeeper.port=2181, zookeeper.timeout=3000, service.id=38}:
>> Unexpected
>> >> > problem updating configuration
>> >> > java.lang.NullPointerException
>> >> > at
>> >> >
>> >>
>> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
>> >> > at
>> >> >
>> >>
>> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:959)
>> >> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>> >> >
>> >> > I used the 1.1 snapshot before, and never had this problem with
>> >> discovery.
>> >> > Is there something I forgot?
>> >> >
>> >> > I am using the singlebundle release with the latest (3.2.1) zookeeper.
>> >> >
>> >> > --
>> >> > Met vriendelijke groet,
>> >> >
>> >> > Alexander Broekhuis
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Met vriendelijke groet,
>> >
>> > Alexander Broekhuis
>> >
>>
>
>
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>
Re: [DOSGi] Nullpointer with 1.1 and discovery
Posted by Alexander Broekhuis <a....@gmail.com>.
Hi,
Thx for the patch. This fixes my problem.
Can it be that the problems does not occur when using the multi bundle
distribution? I am using the singlebundle version.
Not sure why I don't see it with the snapshot version. Can it be because of
the two jar files (dosgi and discovery) vs one file now?
Anyway, looking at the OSGi javadoc, the condition seems to be expected.
Again, thanx for the quick fix!
On Wed, Dec 9, 2009 at 12:16 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:
> Hi Alexander,
>
> I tried to reproduce your issue on both Windows XP and Linux (Ubuntu
> 9.10) with JDK 1.6 but wasn't able to.
>
> As an experiment I modified the start and updated methods to be
> synchronized in the Activator. I've attached source and .class files
> in a zip.
> Would you mind modifying your
> cxf-dosgi-ri-discovery-distributed-1.1.jar file with the attached
> Activator and see if that fixes it for you?
>
> BTW this file didn't change since early July so there shouldn't really
> be any difference between 1.1 and the 1.1-SNAPSHOT that you had been
> using before.
>
> Thanks,
>
> David
>
> 2009/12/9 Alexander Broekhuis <a....@gmail.com>:
> > David,
> >
> > I tested with the discovery demo. On equinox as well as felix. It fails,
> but
> > not always. I can get it to always work, if I add the zookeeper.cfg to
> the
> > load directory after starting all services. But as soon as the cfg is in
> the
> > cache, a restart fails again.
> >
> > I looked at the source, and the only thing I can see is indeed a race
> > condition at the updated callback. I guess services are registered before
> > the register method is completely done and returned. So the config
> manager
> > already starts updating the managed services which leads to the
> nullpointer.
> >
> > After reading the OSGi javadoc I think the start method has to be
> > synchronized. From
> >
> http://www.osgi.org/javadoc/r2/org/osgi/service/cm/ManagedService.html#updated%28java.util.Dictionary%29
> > :
> > - The Configuration Admin service must call this method on a thread other
> > than the thread which initiated the callback. This implies that
> implementors
> > of Managed Service can be assured that the callback will not take place
> > during registration when they execute the registration in a synchronized
> > method.
> >
> > While the stop is synchronized, the start isn't. Can this be the problem?
> >
> > Thanx in advance!
> >
> >
> > On Mon, Dec 7, 2009 at 4:47 PM, David Bosschaert <
> david.bosschaert@gmail.com
> >> wrote:
> >
> >> Hi Alexander,
> >>
> >> I just walked through the Discovery Demo as described here:
> >> http://cxf.apache.org/dosgi-discovery-demo-page.html
> >> and it works fine for me.
> >>
> >> Looking at the source code where you get the exception:
> >> > java.lang.NullPointerException
> >> > at
> >> >
> >>
> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
> >>
> >> to me it seems like the updated() callback is made before the
> >> bundle.start() has returned. Hmmm, there might be a race condition
> >> here ...
> >>
> >> Is it possible for you to provide a test case that consistently fails?
> >> Otherwise, did you walk through the Discovery Demot page mentioned
> >> above? Does that work for you?
> >>
> >> Thanks,
> >>
> >> David
> >>
> >> 2009/12/7 Alexander Broekhuis <a....@gmail.com>:
> >> > Hi all,
> >> >
> >> > When using the 1.1 release, I get a nullpointer if discovery is used:
> >> >
> >> > *ERROR* {org.osgi.service.cm.
> >> > ManagedService}={service.pid=org.apache.cxf.dosgi.discovery.zookeeper,
> >> > zookeeper.port=2181, zookeeper.timeout=3000, service.id=38}:
> Unexpected
> >> > problem updating configuration
> >> > java.lang.NullPointerException
> >> > at
> >> >
> >>
> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
> >> > at
> >> >
> >>
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:959)
> >> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> >> >
> >> > I used the 1.1 snapshot before, and never had this problem with
> >> discovery.
> >> > Is there something I forgot?
> >> >
> >> > I am using the singlebundle release with the latest (3.2.1) zookeeper.
> >> >
> >> > --
> >> > Met vriendelijke groet,
> >> >
> >> > Alexander Broekhuis
> >> >
> >>
> >
> >
> >
> > --
> > Met vriendelijke groet,
> >
> > Alexander Broekhuis
> >
>
--
Met vriendelijke groet,
Alexander Broekhuis
Re: [DOSGi] Nullpointer with 1.1 and discovery
Posted by David Bosschaert <da...@gmail.com>.
Hi Alexander,
I tried to reproduce your issue on both Windows XP and Linux (Ubuntu
9.10) with JDK 1.6 but wasn't able to.
As an experiment I modified the start and updated methods to be
synchronized in the Activator. I've attached source and .class files
in a zip.
Would you mind modifying your
cxf-dosgi-ri-discovery-distributed-1.1.jar file with the attached
Activator and see if that fixes it for you?
BTW this file didn't change since early July so there shouldn't really
be any difference between 1.1 and the 1.1-SNAPSHOT that you had been
using before.
Thanks,
David
2009/12/9 Alexander Broekhuis <a....@gmail.com>:
> David,
>
> I tested with the discovery demo. On equinox as well as felix. It fails, but
> not always. I can get it to always work, if I add the zookeeper.cfg to the
> load directory after starting all services. But as soon as the cfg is in the
> cache, a restart fails again.
>
> I looked at the source, and the only thing I can see is indeed a race
> condition at the updated callback. I guess services are registered before
> the register method is completely done and returned. So the config manager
> already starts updating the managed services which leads to the nullpointer.
>
> After reading the OSGi javadoc I think the start method has to be
> synchronized. From
> http://www.osgi.org/javadoc/r2/org/osgi/service/cm/ManagedService.html#updated%28java.util.Dictionary%29
> :
> - The Configuration Admin service must call this method on a thread other
> than the thread which initiated the callback. This implies that implementors
> of Managed Service can be assured that the callback will not take place
> during registration when they execute the registration in a synchronized
> method.
>
> While the stop is synchronized, the start isn't. Can this be the problem?
>
> Thanx in advance!
>
>
> On Mon, Dec 7, 2009 at 4:47 PM, David Bosschaert <david.bosschaert@gmail.com
>> wrote:
>
>> Hi Alexander,
>>
>> I just walked through the Discovery Demo as described here:
>> http://cxf.apache.org/dosgi-discovery-demo-page.html
>> and it works fine for me.
>>
>> Looking at the source code where you get the exception:
>> > java.lang.NullPointerException
>> > at
>> >
>> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
>>
>> to me it seems like the updated() callback is made before the
>> bundle.start() has returned. Hmmm, there might be a race condition
>> here ...
>>
>> Is it possible for you to provide a test case that consistently fails?
>> Otherwise, did you walk through the Discovery Demot page mentioned
>> above? Does that work for you?
>>
>> Thanks,
>>
>> David
>>
>> 2009/12/7 Alexander Broekhuis <a....@gmail.com>:
>> > Hi all,
>> >
>> > When using the 1.1 release, I get a nullpointer if discovery is used:
>> >
>> > *ERROR* {org.osgi.service.cm.
>> > ManagedService}={service.pid=org.apache.cxf.dosgi.discovery.zookeeper,
>> > zookeeper.port=2181, zookeeper.timeout=3000, service.id=38}: Unexpected
>> > problem updating configuration
>> > java.lang.NullPointerException
>> > at
>> >
>> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
>> > at
>> >
>> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:959)
>> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>> >
>> > I used the 1.1 snapshot before, and never had this problem with
>> discovery.
>> > Is there something I forgot?
>> >
>> > I am using the singlebundle release with the latest (3.2.1) zookeeper.
>> >
>> > --
>> > Met vriendelijke groet,
>> >
>> > Alexander Broekhuis
>> >
>>
>
>
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>
Re: [DOSGi] Nullpointer with 1.1 and discovery
Posted by Alexander Broekhuis <a....@gmail.com>.
David,
I tested with the discovery demo. On equinox as well as felix. It fails, but
not always. I can get it to always work, if I add the zookeeper.cfg to the
load directory after starting all services. But as soon as the cfg is in the
cache, a restart fails again.
I looked at the source, and the only thing I can see is indeed a race
condition at the updated callback. I guess services are registered before
the register method is completely done and returned. So the config manager
already starts updating the managed services which leads to the nullpointer.
After reading the OSGi javadoc I think the start method has to be
synchronized. From
http://www.osgi.org/javadoc/r2/org/osgi/service/cm/ManagedService.html#updated%28java.util.Dictionary%29
:
- The Configuration Admin service must call this method on a thread other
than the thread which initiated the callback. This implies that implementors
of Managed Service can be assured that the callback will not take place
during registration when they execute the registration in a synchronized
method.
While the stop is synchronized, the start isn't. Can this be the problem?
Thanx in advance!
On Mon, Dec 7, 2009 at 4:47 PM, David Bosschaert <david.bosschaert@gmail.com
> wrote:
> Hi Alexander,
>
> I just walked through the Discovery Demo as described here:
> http://cxf.apache.org/dosgi-discovery-demo-page.html
> and it works fine for me.
>
> Looking at the source code where you get the exception:
> > java.lang.NullPointerException
> > at
> >
> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
>
> to me it seems like the updated() callback is made before the
> bundle.start() has returned. Hmmm, there might be a race condition
> here ...
>
> Is it possible for you to provide a test case that consistently fails?
> Otherwise, did you walk through the Discovery Demot page mentioned
> above? Does that work for you?
>
> Thanks,
>
> David
>
> 2009/12/7 Alexander Broekhuis <a....@gmail.com>:
> > Hi all,
> >
> > When using the 1.1 release, I get a nullpointer if discovery is used:
> >
> > *ERROR* {org.osgi.service.cm.
> > ManagedService}={service.pid=org.apache.cxf.dosgi.discovery.zookeeper,
> > zookeeper.port=2181, zookeeper.timeout=3000, service.id=38}: Unexpected
> > problem updating configuration
> > java.lang.NullPointerException
> > at
> >
> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
> > at
> >
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:959)
> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> >
> > I used the 1.1 snapshot before, and never had this problem with
> discovery.
> > Is there something I forgot?
> >
> > I am using the singlebundle release with the latest (3.2.1) zookeeper.
> >
> > --
> > Met vriendelijke groet,
> >
> > Alexander Broekhuis
> >
>
--
Met vriendelijke groet,
Alexander Broekhuis
Re: [DOSGi] Nullpointer with 1.1 and discovery
Posted by David Bosschaert <da...@gmail.com>.
Hi Alexander,
I just walked through the Discovery Demo as described here:
http://cxf.apache.org/dosgi-discovery-demo-page.html
and it works fine for me.
Looking at the source code where you get the exception:
> java.lang.NullPointerException
> at
> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
to me it seems like the updated() callback is made before the
bundle.start() has returned. Hmmm, there might be a race condition
here ...
Is it possible for you to provide a test case that consistently fails?
Otherwise, did you walk through the Discovery Demot page mentioned
above? Does that work for you?
Thanks,
David
2009/12/7 Alexander Broekhuis <a....@gmail.com>:
> Hi all,
>
> When using the 1.1 release, I get a nullpointer if discovery is used:
>
> *ERROR* {org.osgi.service.cm.
> ManagedService}={service.pid=org.apache.cxf.dosgi.discovery.zookeeper,
> zookeeper.port=2181, zookeeper.timeout=3000, service.id=38}: Unexpected
> problem updating configuration
> java.lang.NullPointerException
> at
> org.apache.cxf.dosgi.discovery.zookeeper.Activator.updated(Activator.java:60)
> at
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:959)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>
> I used the 1.1 snapshot before, and never had this problem with discovery.
> Is there something I forgot?
>
> I am using the singlebundle release with the latest (3.2.1) zookeeper.
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>