tried testing with r3132 (1.9.16-SNAPSHOT) - no change
/i
On May 4, 2009, at 1:47 PM, Jeanfrancois Arcand wrote:
> Salut,
>
> actually I did commit:
>
>> Modified: trunk/code/modules/http/src/main/java/com/sun/grizzly/
>> http/SocketChannelOutputBuffer.java
>> Url: https://grizzly.dev.java.net/source/browse/grizzly/trunk/code/modules/http/src/main/java/com/sun/grizzly/http/SocketChannelOutputBuffer.java?view=diff&rev=3126&p1=trunk/code/modules/http/src/main/java/com/sun/grizzly/http/SocketChannelOutputBuffer.java&p2=trunk/code/modules/http/src/main/java/com/sun/grizzly/http/SocketChannelOutputBuffer.java&r1=3125&r2=3126
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>> --- trunk/code/modules/http/src/main/java/com/sun/grizzly/http/
>> SocketChannelOutputBuffer.java (original)
>> +++ trunk/code/modules/http/src/main/java/com/sun/grizzly/http/
>> SocketChannelOutputBuffer.java 2009-05-04 15:29:39+0000
>> @@ -565,6 +565,11 @@
>> * Stop buffering bytes, discard any upcoming writes.
>> */
>> public void discardUpstreamBytes(){
>> + try{
>> + flush();
>> + } catch (IOException ex){
>> + logger.log(Level.WARNING,"",ex);
>> + }
>> discardBytes = true;
>> }
>
> Can you do a quick test?
>
> Thanks!
>
> -- Jeanfrancois
>
>
>
> Igor Minar wrote:
>> Hi there,
>> I tried testing with grizzly r3126 but it didn't help.
>> This is not a huge issue for me and can be fixed in a later version
>> of grizzly if you need to cut 1.9.15 now.
>> 548 (now fixed) was a lot more important and I'm grateful for the
>> fix.
>> /i
>> On May 4, 2009, at 7:28 AM, Jeanfrancois Arcand wrote:
>>> Salut,
>>>
>>> Igor Minar wrote:
>>>> I have a good news: r3122 resolved the problem
>>>> and a bad news: the solution suffers from a concurrency bug.
>>>> My code looks like this:
>>>> try {
>>>> response.flushHeaders();
>>>> } catch (IOException ex) {
>>>> logger.log(Level.INFO, "Failed to send headers", ex);
>>>> }
>>>> response.discardUpstreamWrites();
>>>> When testing this code under load (50-100 concurrent requests),
>>>> grizzly never sends the headers to the clients, so clients think
>>>> that the response was a HTTP 0.9 response without headers.
>>>
>>> Hum I'm surprised it is related to a concurrency issue. The header
>>> bytes never gets written? Can you add, in SocketChannelOuputBuffer
>>>
>>> Index: http/src/main/java/com/sun/grizzly/http/
>>> SocketChannelOutputBuffer.java
>>> ===================================================================
>>> --- http/src/main/java/com/sun/grizzly/http/
>>> SocketChannelOutputBuffer.java (revision 3124)
>>> +++ http/src/main/java/com/sun/grizzly/http/
>>> SocketChannelOutputBuffer.java (working copy)
>>> @@ -565,6 +565,11 @@
>>> * Stop buffering bytes, discard any upcoming writes.
>>> */
>>> public void discardUpstreamBytes(){
>>> + try{
>>> + flushBuffer();
>>> + } catch (IOException ex){
>>> + logger.log(Level.WARNING,"",ex);
>>> + }
>>> discardBytes = true;
>>> }
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>> We are almost there :)
>>>> /i
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>