Hi Rama,
as for the first block:
I think it's really some ThreadPoolExecutor internal synchronization
it does to distribute tasks among threads. And IMHO we can not avoid
that.
As for second group:
it's not clear for me, but again I would say it's normal.
In general I think we should reduce locks where it's possible, cause
they are quite expensive, but now I don't see any redundant
synchronization. If you'll find one - we will definitely fix that.
Thanks.
WBR,
Alexey.
On Mar 6, 2009, at 16:09 , rama.rama_at_tiscali.it wrote:
>>
>> 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/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>