You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Cocorossello <Co...@gmail.com> on 2019/02/11 11:13:13 UTC
Lock instances since CXF 3.3.0
Hi,
I've been checking my app with JFR. I can see a new important lock since CXF
3.3.0 coming from ProviderFactory.tryCreateInstance that changed, the
commit is
https://github.com/apache/cxf/commit/791461c6f957ebd466b432c354c15e91500cf463#diff-556a2e3b0d567e80dbcc125b0c19da8a
Is it a problem? Here is a screenshot of the JFR report that I extracted by
recording 120 seconds in production (don't mind the IndirectList lock, I
know why it happens, it's "ok"). https://imgur.com/J4xuGjb
Thank you,
Vicente.
--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
Re: Lock instances since CXF 3.3.0
Posted by James Carman <ja...@carmanconsulting.com>.
Ouch. Thanks, Dan. We are rolling out 3.3.0 at work. Should I hold off
until 3.3.1? Do we think this has a high likelihood to cause performance
issues?
On Fri, Feb 15, 2019 at 9:17 AM Daniel Kulp <dk...@apache.org> wrote:
>
>
> On Feb 14, 2019, at 3:42 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
>
> Is this just impacting folks that use JAXB or is this more pervasive?
>
>
> Actually, the reverse is likely more of an issue, but it's pervasive no
> matter what. If you do have jaxb and all the other related things
> (activation, etc..) classes, the Class.forName calls should be quicker as
> the first time it’s called the class would get loaded and it should return
> relatively quick.
>
> The big issue is if the class.forName fails, we will keep calling it every
> request. On some class loaders (OSGi for example), class.forName is very
> expensive for classes it cannot find as it searches major hierarchies of
> class loaders trying to find it. And it does this over and over and over
> for each request.
>
> Dan
>
>
>
>
> On Thu, Feb 14, 2019 at 8:02 AM Cocorossello <Co...@gmail.com>
> wrote:
>
>
> Hi,
>
> Thanks for the patch. I've tried in dev and I can see no major locks.
> Although I haven't tested in production, I'll try to push a build with cxf
> 3.3.0 and this class patched, but I can't promess anything.
>
> Best regards,
> Vicente.
>
>
>
> --
> Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://talend.com <http://coders.talend.com>
>
>
Re: Lock instances since CXF 3.3.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Feb 14, 2019, at 3:42 PM, James Carman <ja...@carmanconsulting.com> wrote:
>
> Is this just impacting folks that use JAXB or is this more pervasive?
Actually, the reverse is likely more of an issue, but it's pervasive no matter what. If you do have jaxb and all the other related things (activation, etc..) classes, the Class.forName calls should be quicker as the first time it’s called the class would get loaded and it should return relatively quick.
The big issue is if the class.forName fails, we will keep calling it every request. On some class loaders (OSGi for example), class.forName is very expensive for classes it cannot find as it searches major hierarchies of class loaders trying to find it. And it does this over and over and over for each request.
Dan
>
> On Thu, Feb 14, 2019 at 8:02 AM Cocorossello <Co...@gmail.com> wrote:
>>
>> Hi,
>>
>> Thanks for the patch. I've tried in dev and I can see no major locks.
>> Although I haven't tested in production, I'll try to push a build with cxf
>> 3.3.0 and this class patched, but I can't promess anything.
>>
>> Best regards,
>> Vicente.
>>
>>
>>
>> --
>> Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: Lock instances since CXF 3.3.0
Posted by James Carman <ja...@carmanconsulting.com>.
Is this just impacting folks that use JAXB or is this more pervasive?
On Thu, Feb 14, 2019 at 8:02 AM Cocorossello <Co...@gmail.com> wrote:
>
> Hi,
>
> Thanks for the patch. I've tried in dev and I can see no major locks.
> Although I haven't tested in production, I'll try to push a build with cxf
> 3.3.0 and this class patched, but I can't promess anything.
>
> Best regards,
> Vicente.
>
>
>
> --
> Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
Re: Lock instances since CXF 3.3.0
Posted by Cocorossello <Co...@gmail.com>.
Hi,
Thanks for the patch. I've tried in dev and I can see no major locks.
Although I haven't tested in production, I'll try to push a build with cxf
3.3.0 and this class patched, but I can't promess anything.
Best regards,
Vicente.
--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
Re: Lock instances since CXF 3.3.0
Posted by Daniel Kulp <dk...@apache.org>.
> On Feb 11, 2019, at 6:13 AM, Cocorossello <Co...@gmail.com> wrote:
> I've been checking my app with JFR. I can see a new important lock since CXF
> 3.3.0 coming from ProviderFactory.tryCreateInstance that changed, the
> commit is
> https://github.com/apache/cxf/commit/791461c6f957ebd466b432c354c15e91500cf463#diff-556a2e3b0d567e80dbcc125b0c19da8a
>
> Is it a problem? Here is a screenshot of the JFR report that I extracted by
> recording 120 seconds in production (don't mind the IndirectList lock, I
> know why it happens, it's "ok"). https://imgur.com/J4xuGjb
Yea… I consider it a problem. You may be able to limit it by adding the various classes that are needed by the providers so that the class loader itself can actually cache the class objects (instead of repeated class not found issues), but it’s still calling into synchronized methods which would cause contention.
I’ve just pushed a change to master (3.3.1-SNAPSHOT) that I hope will resolve this by caching the Class objects (or the fact that the class objects are null if they cannot be loaded). That should eliminate this problem. It would be great if you could give it a try.
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>