[jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1399) Allow users to configure a system wide maximum session limit

[Tim Fox (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1399:
---------------------------------

    Fix Version/s: 2.0.0.CR1
                       (was: 2.0.0.GA)


> Allow users to configure a system wide maximum session limit
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1399
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1399
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>             Fix For: 2.0.0.CR1
>
>
> Goal: keep external/internal clients from running the system out of resources(threads/memory).
> We currently have a problem where there is no limit to the number of sessions that can be created in the system.  It would be theoretically possible to have an external client create 1 million sessions in one connection and run the sever out of resources.   It's also possible to set the number of max sessions for an mdb high enough to run the system out of resources(threads/memory).  We need to be able to set a limit for the number of sessions for the system. 
> I've looked at other Messaging systems, like IBM MQ and it seems that other systems have the same setting. 
> We've had users naively suggest that we could implement this by using a bounded thread pool.  This seems too intrusive and too dangerous to do.  This can be done by limiting the number of sessions in the system, which seems like a much better suggestion.  This is much better than using a bounded thread pool for many reasons.  A couple of the reasons is..
> 1.  It doesn't expose the internal workings of JBM to the management console(leaky abstraction).  
> 2.  Users can understand a session limit easier than having to understand the internal thread pool implementation.
> 3.  Doesn't incur deadlocks
> 4.  Allows All clients to get back a message that says some thing like "Session limit reached".
> JBM 2.0 uses an unbounded thread pool for threads, which addresses any concern any performance difficulties with creating and destroying threads.  So now we can address the max number of threads in the system by configuring max sessions in the system.
> Setting a session limit seems to be a more reasonable approach than the bounded thread pool

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira