dev@grizzly.java.net

Re: Question about DefaultThreadPool

From: Minoru Nitta <minoru.nitta_at_jp.fujitsu.com>
Date: Fri, 26 Jun 2009 10:34:34 +0900

Hi Alexey,


 Thank you very much! I've filed the issue.

https://grizzly.dev.java.net/issues/show_bug.cgi?id=686

Minoru


> Hi Minoru,
>
> I've fixed that. Now RejectedExecutionException is being thrown, when
> task could not be added to the thread pool queue.
> Can I ask you to file the issue?
>
> Thank you.
>
> WBR,
> Alexey.
>
> On Jun 25, 2009, at 6:40 , Minoru Nitta wrote:
>
> > Salut,
> >
> >
> > I have a question about current DefaultThreadPool. DefaultThreadPool
> > has 4 constructors now, and one of them can allow a user to specify
> > any queues that implements BlockingQueue interface.
> >
> > This is good for me, because I can specify ArrayBlockingQueue, and
> > a similar issue was filed before.
> >
> > https://grizzly.dev.java.net/issues/show_bug.cgi?id=602
> >
> >
> > The problem occurs when the user specify a queue of limited capacity,
> > because current execute method ignores a return value of
> > BlockingQueue.offer
> > method. So, if the queue is full, the task that is specified as
> > a parameter of DefaultThreadPool.exeucte, will be discarded, and
> > will never be executed.
> >
> > I should not specifiy a limited capacity of BlockingQueue?
> > Or DefaultThreadPool.execute method should return the value,
> > which indicates task was queued or not (i.e. return value
> > of BlockingQueue.offer)?
> >
> > Thanks.
> >
> >
> > Minoru
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net