I'm seeing those 500 in my production monitoring. The test there is just
requesting "GET / HTTP/1.0 \nUser-Agent:LogicMonitor\nConnection: close\n\n"
After this implemented a small bash test: #!/bin/bash while [ 1 ]; do
d=$(date +'%Y-%m-%d-%H:%M:%S-%N') echo $d curl -o testin.txt
--connect-timeout 65 --max-time 60 "myhost?$d" if grep -q copyright
"testin.txt"; then date echo "Found" rm testin.txt else date echo "Not Found"
exit fi sleep 1 done This exits every couple of minutes with "Not Found".
With higher load this happens faster. On my testing platform I don't see this
issue. Btw.: I gave jetty a thread pool of 2000, but it's peeking only on 100
concrurrent threads, so load should no be the issue. I think both tests are
http 1.0. I have checked other request in the server.log there are more with
500 results wich should work, but the simple test should always work no
matter what the server is doing. Might this be a concurrency bug in grizzly,
im using a pool of java.util.concurrent.locks.ReentrantLock locks to
synchronize the concurrent request from one client. As said in jetty it works
as expected. Is there a fundamental difference between jetty 9 and grizzly in
gf4? Stephan
--
[Message sent by forum member 'iceandfire']
View Post: http://forums.java.net/node/897461