Hi Kristoffer,
> You can find the implmentation of the queue and pool here:
>
> HTTP-queue:
> http://fisheye5.cenqua.com/browse/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/LinkedListPipeline.java?r=1.25
Yes, it's standard synchronized thread pool implementation, GFv3.1
will have more optimized implementation, which will be less
synchronized, it could slightly improve perf. numbers. But I don't
think this thread pool is the narrow place in your testing.
>
> JDBC Pool:
> http://fisheye5.cenqua.com/browse/glassfish/entity-persistence/src/java/oracle/toplink/essentials/threetier/ExternalConnectionPool.java?r=1.4
>
> I have also attached the thread dumps that show the contention..
I've checked the dump.
You have a lot of worker threads. which may cause redundant CPU
thrashing. Just out of curiosity, can you create similar test, which
doesn't access DB, but let's say runs some calculation logic instead,
and check if you'll be able to load CPUs. This way we will be able to
recognize if DB access is the narrow place or not.
WBR.
Alexey.
>
> Cheers,
> -Kristoffer
> [Message sent by forum member 'ekrisjo']
>
> http://forums.java.net/jive/thread.jspa?messageID=469554
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>