John Franey wrote:
>
>
> On Thu, May 14, 2009 at 11:26 AM, Jeanfrancois Arcand
> <Jeanfrancois.Arcand_at_sun.com <mailto: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.
I agree with your explanation. Can I ask you to sumit a patch? At least
file an issue so we don't forget. I think we should target 1.9.16.
A+
-- Jeanfrancois
>
> Regards,
> John
>
>
> Thanks!
>
> --Jeanfrancois
>
>
>
> Regards,
> John
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> <mailto:users-help_at_grizzly.dev.java.net>
>
>