>
> I have a question for you :)
Sure :)
> <GROUP ONE>
> I am just
curious to understand what this
> problem can be.
> The waiting/owner
threads are blocked/waiting on
> threadpoolexecutor$worker.run();
> My
first idea was that some req went
> queued, but this is not true,
because i have put maxthread >
> test_concurrency
> (test_concurrency =
45, maxthread = 64) [you can see
> that the value are correctly
configured, because on
> the follow logs you
> will get some
workerthread with high id]
> The avg locking time as you
> can see is
more or less 400ms that is a lot for a ws (means that some
*May this
just shows that some threads are in idle state waiting for
*some job?
Nope, if threads are on idle, jprofiler will show "waiting" or "netio"
not blocking.
Blocking is only show for monitor syncronization stuff,
at least standing to their docs
> request required 400ms+<normal
elaboration time> to be executed)
> <GROUP TWO>
> blocked/waiting on
com.sun.
> grizzly.Controller.run()
> Same of above, i need some clue
to understand
> better what's up :)
> even there the locking time is
pretty high, with
> 450 of avg.
*This could be just state locker,
which we use to synchronize on state
*change, but it should be used
just on startup, shutdown.
Umm, i don't think so, cos the lock happen
time to time after the ws is on
*But these just guesses, can you pls.
provide more information on that
*tables? Can you pls. specify line
numbers, where locks are getting
*blocked?
Unfortunatly, linenumbers
isn't aviable on jprofiler, but i can try to give to you more info
<GROUP ONE>
duration (avg) 400ms
monitor id: 30 (useless i suppose)
monitor class: java.util.concurrent.locks.reentrantlock$nonfairsync
waiting thread: http2480-worker(X)
owning thread: http2480-worker(Y)
Stack trace of waiting thread:
java.util.concurrent.
threadpoolexecutor$worker.run();
stack trace of owning thread:
java.
util.concurrent.threadpoolexecutor$worker.run();
<GROUP TWO>
duration (avg) 500ms
monitor id: 31 (useless i suppose)
monitor class:
java.util.concurrent.locks.reentrantlock$nonfairsync
waiting thread:
grizzlyreadcontroller-(X)
owning thread: http2480-worker(Y)
Stack
trace of waiting thread:
com.sun.grizzly.controller.run();
stack trace
of owning thread:
java.util.concurrent.threadpoolexecutor$worker.run();
Please, notice that GROUP TWO can be inverted (in the meaning that
sometimes
the waiting thread is a worker, and the owning is a reader)
Probably this is just normal, but since sometimes there are this
"little lag" moment, i am wondering if i can tune it a bit better to
have better performance :)
*Thanks.
To you!
Con Tiscali Tutto Incluso telefoni e navighi senza limiti A SOLI €10 AL MESE FINO ALL’ESTATE. Attiva entro il 12/03/09!
http://abbonati.tiscali.it/promo/tuttoincluso/