On Thu, May 14, 2009 at 11:26 AM, Jeanfrancois Arcand <
Jeanfrancois.Arcand_at_sun.com> wrote:
> Salut,
>
> John Franey wrote:
>
>>
>> I have a change request for the interface of DefaultThreadPool. Should I
>> post as issue?
>>
>
> yes. Attach a svn diff -u if you have something you want us to look at.
>
>
>> I would like to use a different BlockingQueue than what is currently
>> hardwired and unchangeable (LInkedBlockingQueue).
>>
>
> Should we change the queue directly inside that class?
>
I'm not clear in the above. DefaultThreadPool supplies LinkedBlockingQueue
to ThreadPoolExecutor. Id like to use a different BlockingQueue.
DefaultThreadPool is currently implemented in a way that prevents me from
using a different BlockingQueue.
So, the code change would be either 1) a constructor that takes a
BlockingQueue, or 2) genericise DefaultThreadPool, like in
DefaultThreadPool<? extends BlockingQueue>. Unfortunately,
ThreadPoolExecutor does not allow the queue to be changed after it has been
constructed.
>
>> My main reason is to reduce memory allocation rate. A
>> LinkedBlockingQueue$Node object is allocated for every entry in the
>> LinkedBlockingQueue. I'd like to use an ArrayBlockingQueue instead, to
>> avoid allocating the Node objects.
>>
>
> I need to look a the code, but I suspect the queue needs to be synchronized
> IMO. Again, I need to look :-)
>
>
>> SelectorHandlerRunner cancels the key on unexpected exceptions, which
>> seems to be the right thing for the case when the thread pool's execute
>> throws a RejectedExecutionRejection, basically shutting down connections for
>> which there isn't capacity.
>>
>
> Can you elaborate? You think switching the queue will reduce the memory
> allocation under that specific scenario?
>
No. This statement means only that I checked that a
RejectedRuntimeException would be reasonably handled by grizzly.
This is my thinking for wanting to switch the queue type: An RTP receiver
receives a high rate datagrams per second per connections. As far as I can
tell by the code, in almost all cases (except if ConnectionHandlerDescriptor
is properly implemented to return false for 'useSeparateThread'),
NioContext.execute will enqueue a Runnable to the thread pools's executor.
In a case where there are 50 datagrams per second over 500 connections:
25K datagrams per second would be received. This results in 25K
LinkedBlockingQueue$Node per second for the garbage collector to reclaim.
An ArrayBlockingQueue does not allocate objects at this rate.
Maybe with the fast garbage collectors these days I should not be worried so
much. However, RTP is sensitive to the GC pauses. So, any steps that can
shorten a pause or the GC cycle are valuable.
Regards,
John
> Thanks!
>
> --Jeanfrancois
>
>
>
>> Regards,
>> John
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>