You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Julien Vermillard (JIRA)" <ji...@apache.org> on 2010/01/19 14:33:54 UTC

[jira] Updated: (DIRMINA-723) OrderedThreadPoolExecutor behavior: configurable queue size, corePoolSize, maximumPoolSize

     [ https://issues.apache.org/jira/browse/DIRMINA-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julien Vermillard updated DIRMINA-723:
--------------------------------------

    Fix Version/s: 3.0.0-M1

> OrderedThreadPoolExecutor behavior: configurable queue size, corePoolSize, maximumPoolSize
> ------------------------------------------------------------------------------------------
>
>                 Key: DIRMINA-723
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-723
>             Project: MINA
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.0.0-M6
>         Environment: Ubuntu Linux, kernel 2.6.x
>            Reporter: Victor N
>            Priority: Minor
>             Fix For: 3.0.0-M1
>
>
> The problem was discussed with Emmanuel Lecharny in mail lists:
> http://www.nabble.com/OrderedThreadPoolExecutor%3A-limited-workQueue-td24275973.html
> If you compare OrderedThreadPoolExecutor and standard ThreadPoolExecutor, you can see that ThreadPoolExecutor has useful params:
> - core pool size
> - maximum pool size
> - work queue size
> If you use unbounded thread pools and queues with mina Acceptor or Connector, you may get OutOfMemoryError under critical load because Java creates too many threads.
> With ThreadPoolExecutor you may limit the number of threads (maximumPoolSize) and use a bounded queue (ex. LinkedBlockingQueue of limited capacity).
> Unfortunately, this does not work with OrderedThreadPoolExecutor -both  "waitingSessions" and  "sessionTasksQueue" do not allow to configure their size nor pass a different queue implementation.
> Even though OrderedThreadPoolExecutor extends ThreadPoolExecutor, it overrides the behavior significantly - seems that its meaning of "corePoolSize" and "maximumPoolSize" is different.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.