On 09/29/09 13:50, Jeanfrancois Arcand wrote:
> Salut,
>
> Scott Oaks wrote:
>> When java.net is responsive (sigh...), I will file this issue:
>
> Good luck :-)
>
>>
>> When I make a single request to a servlet, the
>> com.sun.grizzly.rcp.Request and Response objects are recycled twice:
>> once from
>> com.sun.grizzly.tcp.http11.InternalInputBuffer.nextRequest(), and once
>> from com.sun.grizzly.rcp.StaticResourcesAdapter.afterService().
>>
>> I'm not yet sure of the impact of this. Profiles tell me that the time
>> spent recycling is 2x in v3 compared to v2, and that's about 2% of
>> total time (so a 1% regression from v2). Though I commented out one of
>> the recycle calls and didn't see an improvement -- so I likely have a
>> bottleneck somewhere else, or I didn't understand the code path
>> enough. It might be that other processing in nextRequest and
>> afterService is also duplicated?
>
> Hum they were also recycled twice in v2, first when IIB.nextBuffer(),
> and then when the ProcessorTask.recycle() was called from the
> DefaultReadTask.
That would also explain why my fix didn't improve things; I guess the
profile sampling is just off in this case.
Still, I'll file it as a P4 just so we know...I don't suppose there's a
way to know if the object has been used since the last recycle? We could
set a flag in recycle, but when would it unset?
-Scott
>
> The fix is not that trivial as the nextBuffer() may not get invoked if
> there is an IOException. But it worth doing some analysis.
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>>
>> -Scott
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>