dev@grizzly.java.net

Re: Regression: trunk broken...hold on commit

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Mon, 30 Mar 2009 15:22:01 -0400

Salut,

Jeanfrancois Arcand wrote:
> Salut,
>
> I've filled
>
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=502

OK I've jumped a little high...the issue was only with ab and http 1.0.
Still I re-worked the file cache to make ab happy.

A+

-- Jeanfrancois



>
> Note that the current build fail to build:
>
>> -------------------------------------------------------
>> T E S T S
>> -------------------------------------------------------
>> Running com.sun.grizzly.comet.BasicCometTest
>> testOnInterruptExpirationDelay - will wait 5 seconds
>> -> onInitialize Handler:32926975
>> -> onInterrupt Handler:32926975
>> testClientCloseConnection
>> GET /OnClientCloseConnection HTTP/1.1
>> Host: localhost:18892
>>
>>
>> -> onInitialize Handler:9740137
>> testOnEvent - will wait 5 seconds
>> -> onInitialize Handler:5218268
>> -> onEvent Handler:5218268
>> testOnTerminate - will wait 5 seconds
>> -> onInitialize Handler:24562387
>> -> onTerminate Handler:24562387
>> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 23.538
>> sec <<< FAILURE!
>> Running com.sun.grizzly.comet.CometUnitTest
>> JVM: Sun Microsystems Inc. Java HotSpot(TM) Server VM 10.0-b19 params: []
>> 30-Mar-2009 1:26:11 PM com.sun.grizzly.http.SelectorThread
>> displayConfiguration
>> INFO: Grizzly configuration for port 19000
>> Thread Pool: StatsThreadPool[name=http, priority=10,
>> min-threads=5, max-threads=5, max-queue-size=4096,
>> initial-byte-buffer-size=8192, byte-buffer-type=HEAP_VIEW,
>> is-shutdown=false, port=19000]
>> ByteBuffer size: 8192
>> maxHttpHeaderSize: 8192
>> maxKeepAliveRequests: 256
>> keepAliveTimeoutInSeconds: 30
>> Static File Cache enabled: true
>> Static resources directory:
>> /home/jfarcand/workspace/grizzly/trunk/modules/comet
>> Adapter : com.sun.grizzly.comet.CometTestAdapter
>> Asynchronous Request Processing enabled: true
>> STREAMING-
>> events/sec : 275889 comethandlers: 4 cometWorkqueue: 36566
>> events/sec : 385312 comethandlers: 4 cometWorkqueue: 79042
>> events/sec : 251710 comethandlers: 4 cometWorkqueue: 75225
>> events/sec : 296051 comethandlers: 4 cometWorkqueue: 73105
>> events/sec : 234023 comethandlers: 4 cometWorkqueue: 67335
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 23.03 sec
>>
>> Results :
>>
>> Failed tests:
>> testClientCloseConnection(com.sun.grizzly.comet.BasicCometTest)
>>
>> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0
>>
>> [INFO]
>> ------------------------------------------------------------------------
>
> Anyway trunk open buy we must fix the test regression.
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>
> Jeanfrancois Arcand wrote:
>> Salut,
>>
>> the current trunk is showing the exception as well so I would like to
>> ask anybody to hold on on commit until I figure out what's happening.
>> Issuing:
>>
>> ab -c2 -n 10 http://localhost:8080/index.html
>>
>> is showing the issue.
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>> Jeanfrancois Arcand wrote:
>>> Salut,
>>>
>>> rama wrote:
>>>> probably this is of no-use, but is quite strange.
>>>>
>>>> using 1.9.10 release, i was testing the statistics with the sample
>>>> class as, related to
>>>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=376 issue.
>>>>
>>>> So, i have simply execute the class, using a directory that actually
>>>> exist.
>>>>
>>>> After that, with firefox, i have get the index.html just to be sure
>>>> that it's working well.
>>>> On firefox i get the correct output, of a simple html page.
>>>
>>> What kind of corruption? Half a page or something like that?
>>>
>>>
>>>>
>>>> After that i have do
>>>> ab -c 10 -n 1000 http://localhost:8080/index.html
>>>>
>>>> Concurrency Level: 10
>>>> Time taken for tests: 0.491 seconds
>>>> Complete requests: 1000
>>>> Failed requests: 0
>>>> Broken pipe errors: 0
>>>> Total transferred: 1534533 bytes
>>>> HTML transferred: 1411410 bytes
>>>> Requests per second: 2036.66 [#/sec] (mean)
>>>> Time per request: 4.91 [ms] (mean)
>>>> Time per request: 0.49 [ms] (mean, across all concurrent
>>>> requests)
>>>> Transfer rate: 3125.32 [Kbytes/sec] received
>>>>
>>>> This, for me, means that all the request was completed correctly.
>>>> (boken pipe is 0, and failed is 0, also html transferred is correct)
>>>>
>>>> At the end of AB, the console show this stack trace.
>>>
>>> Yes this is expected. ab close the connection before the server has
>>> the time to write the last "chunk". I think we should increase the
>>> log level to prevent confusion.
>>>
>>>>
>>>> Since i am doing this test (for statistics) in the same way of
>>>> always (i wasn't able to use stats, this is way i always try it)
>>>> and, this is the 1st time that i get this stack trace, maybe will be
>>>> useful to report it to community!
>>>>
>>>>
>>>
>>> This is great report. Can you file an issue? On my side I will take a
>>> look!
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> GRAVE: HTTP Processing error
>>>> _java.io.IOException_: Broken pipe
>>>> at sun.nio.ch.FileDispatcher.write0(_Native Method_)
>>>> at sun.nio.ch.SocketDispatcher.write(_SocketDispatcher.java:29_)
>>>> at sun.nio.ch.IOUtil.writeFromNativeBuffer(_IOUtil.java:104_)
>>>> at sun.nio.ch.IOUtil.write(_IOUtil.java:60_)
>>>> at sun.nio.ch.SocketChannelImpl.write(_SocketChannelImpl.java:302_)
>>>> at
>>>> sun.nio.ch.FileChannelImpl.transferToTrustedChannel(_FileChannelImpl.java:450_)
>>>>
>>>> at sun.nio.ch.FileChannelImpl.transferTo(_FileChannelImpl.java:521_)
>>>> at
>>>> com.sun.grizzly.http.SocketChannelOutputBuffer.sendFile(_SocketChannelOutputBuffer.java:341_)
>>>>
>>>> at
>>>> com.sun.grizzly.tcp.StaticResourcesAdapter.service(_StaticResourcesAdapter.java:217_)
>>>>
>>>> at
>>>> com.sun.grizzly.tcp.StaticResourcesAdapter.service(_StaticResourcesAdapter.java:139_)
>>>>
>>>> at
>>>> com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(_GrizzlyAdapter.java:123_)
>>>>
>>>> at
>>>> com.sun.grizzly.http.ProcessorTask.invokeAdapter(_ProcessorTask.java:726_)
>>>>
>>>> at
>>>> com.sun.grizzly.http.ProcessorTask.doProcess(_ProcessorTask.java:615_)
>>>> at com.sun.grizzly.http.ProcessorTask.process(_ProcessorTask.java:895_)
>>>> at
>>>> com.sun.grizzly.http.DefaultProtocolFilter.execute(_DefaultProtocolFilter.java:162_)
>>>>
>>>> at
>>>> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(_DefaultProtocolChain.java:136_)
>>>>
>>>> at
>>>> com.sun.grizzly.DefaultProtocolChain.execute(_DefaultProtocolChain.java:103_)
>>>>
>>>> at
>>>> com.sun.grizzly.DefaultProtocolChain.execute(_DefaultProtocolChain.java:89_)
>>>>
>>>> at
>>>> com.sun.grizzly.http.HttpProtocolChain.execute(_HttpProtocolChain.java:76_)
>>>>
>>>> at
>>>> com.sun.grizzly.ProtocolChainContextTask.doCall(_ProtocolChainContextTask.java:67_)
>>>>
>>>> at
>>>> com.sun.grizzly.SelectionKeyContextTask.call(_SelectionKeyContextTask.java:57_)
>>>>
>>>> at java.util.concurrent.FutureTask$Sync.innerRun(_FutureTask.java:269_)
>>>> at java.util.concurrent.FutureTask.run(_FutureTask.java:123_)
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(_ThreadPoolExecutor.java:650_)
>>>>
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(_ThreadPoolExecutor.java:675_)
>>>>
>>>> at java.lang.Thread.run(_Thread.java:613_)
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>