resteasy-users

[Resteasy-users] Performance issue resteasy+s-ramp

[Eric W. <eri...@re...>]

We're using RE to provide the Atom API in our jboss overlord s-ramp 
implementation.  Something we've run into is a performance problem 
iterating over certain Atom Feeds.  In some circumstances each Entry in 
the atom Feed can wrap an additional jaxb object.  We get access to this 
via Entry's getAnyOtherJAXBObject.

This all works great except that there is no JAXBContextFinder set on 
the Entry, so a new JAXBContext is created for each Entry.

I think the root of this problem is here:

https://github.com/resteasy/Resteasy/blob/master/jaxrs/providers/resteasy-atom/src/main/java/org/jboss/resteasy/plugins/providers/atom/AtomFeedProvider.java#L65-L68

Perhaps the finder should be set on the Entry either in all cases or 
maybe only when Entry:getAnyOtherElement() returns a non-null?

-Eric

Re: [Resteasy-users] Performance issue resteasy+s-ramp

[Bill B. <bb...@re...>]

So, it should use the jaxb context cache.

Log a jira?  Timeframe for fix?  I promised Mark I'd meet any of your 
requirements so you could get off of Jersey.

On 6/13/2014 10:12 AM, Eric Wittmann wrote:
> We're using RE to provide the Atom API in our jboss overlord s-ramp
> implementation.  Something we've run into is a performance problem
> iterating over certain Atom Feeds.  In some circumstances each Entry in
> the atom Feed can wrap an additional jaxb object.  We get access to this
> via Entry's getAnyOtherJAXBObject.
>
> This all works great except that there is no JAXBContextFinder set on
> the Entry, so a new JAXBContext is created for each Entry.
>
> I think the root of this problem is here:
>
> https://github.com/resteasy/Resteasy/blob/master/jaxrs/providers/resteasy-atom/src/main/java/org/jboss/resteasy/plugins/providers/atom/AtomFeedProvider.java#L65-L68
>
> Perhaps the finder should be set on the Entry either in all cases or
> maybe only when Entry:getAnyOtherElement() returns a non-null?
>
> -Eric
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-users] Performance issue resteasy+s-ramp

[Eric W. <eri...@re...>]

Sure thing:

https://issues.jboss.org/browse/RESTEASY-1074

I'm not sure about timeframe.  I have a workaround (see the jira for 
details) that should be sufficient unless running with a security 
manager.  The impact on our app is relatively low, as "any other jaxb 
object" is not used in the context of a Feed in too many use cases.

Also, you might have us confused with someone else - we're definitely 
not using Jersey.  :)

-Eric

On 6/13/2014 10:26 AM, Bill Burke wrote:
> So, it should use the jaxb context cache.
>
> Log a jira?  Timeframe for fix?  I promised Mark I'd meet any of your
> requirements so you could get off of Jersey.
>
> On 6/13/2014 10:12 AM, Eric Wittmann wrote:
>> We're using RE to provide the Atom API in our jboss overlord s-ramp
>> implementation.  Something we've run into is a performance problem
>> iterating over certain Atom Feeds.  In some circumstances each Entry in
>> the atom Feed can wrap an additional jaxb object.  We get access to this
>> via Entry's getAnyOtherJAXBObject.
>>
>> This all works great except that there is no JAXBContextFinder set on
>> the Entry, so a new JAXBContext is created for each Entry.
>>
>> I think the root of this problem is here:
>>
>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/providers/resteasy-atom/src/main/java/org/jboss/resteasy/plugins/providers/atom/AtomFeedProvider.java#L65-L68
>>
>> Perhaps the finder should be set on the Entry either in all cases or
>> maybe only when Entry:getAnyOtherElement() returns a non-null?
>>
>> -Eric
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>