Scott Oaks wrote:
> 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?
Indeed. I think it could be unset inside ProcessorTask when we start
parsing the request. I will go ahead an work on this as soon as I finish
the GF v3 monitoring nightmare :-)
A+
-- Jeanfrancois
>
> -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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>