Lock instances since CXF 3.3.0

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Lock instances since CXF 3.3.0

Cocorossello
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
Reply | Threaded
Open this post in threaded view
|

Re: Lock instances since CXF 3.3.0

Daniel  Kulp
Administrator


> On Feb 11, 2019, at 6:13 AM, Cocorossello <[hidden email]> 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
[hidden email] <mailto:[hidden email]> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>
Reply | Threaded
Open this post in threaded view
|

Re: Lock instances since CXF 3.3.0

Cocorossello
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
Reply | Threaded
Open this post in threaded view
|

Re: Lock instances since CXF 3.3.0

James Carman
Is this just impacting folks that use JAXB or is this more pervasive?

On Thu, Feb 14, 2019 at 8:02 AM Cocorossello <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Lock instances since CXF 3.3.0

Daniel  Kulp
Administrator


> On Feb 14, 2019, at 3:42 PM, James Carman <[hidden email]> 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 <[hidden email]> 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
[hidden email] <mailto:[hidden email]> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>
Reply | Threaded
Open this post in threaded view
|

Re: Lock instances since CXF 3.3.0

James Carman
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 <[hidden email]> wrote:

>
>
> On Feb 14, 2019, at 3:42 PM, James Carman <[hidden email]>
> 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 <[hidden email]>
> 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
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://talend.com <http://coders.talend.com>
>
>