November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1316) code cleanup - final fields and params

by Tim Fox (JIRA)

code cleanup - final fields and params -------------------------------------- Key: JBMESSAGING-1316 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1316 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta Make sure final fields and properties are used where appropriate. Also static inner classes are used, and fields made private. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1090) Add appropriate Exception handling when hitting MaxSize

by Jay Howell (JIRA)

Add appropriate Exception handling when hitting MaxSize ------------------------------------------------------- Key: JBMESSAGING-1090 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1090 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.GA Reporter: Jay Howell Assigned To: Tim Fox When using MaxSize for a queue and topic the following behaviors exist Queue - When a queue hits MaxSize, the delivery returned in Channel Support is null. This triggers a very generic JMSException to be thrown by looking at the delivery and seeing if it's null in the ServerConnectionEndpoint. Topic - When a subscription hits the MaxSize(defined in the topic), the delivery returned will be null, but no check is done and no JMSException is thrown in the ServerConnectionEndpoint. What this means is that anyone who wants to put hooks in to gather the messages dropped can't. Either because the exception is too generic or because one is not thrown at all. I would purpose that we put proper exception handling down in the ChannelSupport where MaxSize is checked for both queues and subscriptions. We would need to Change the The two methods in channel support for send and sendInternal to throw a JMSException. Then we throw a checked Exception in ChannelSupport for MaxSize violations(make a new exception derived from MessagingJMSException). Adding proper exception handling to these would allow users to add aspects and notifications when messages are dropped due to MaxSize. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

4
17
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1424) Provider strict message ordering via "ordering groups"

by Tim Fox (JIRA)

Provider strict message ordering via "ordering groups" ------------------------------------------------------ Key: JBMESSAGING-1424 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1424 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assignee: Tim Fox Fix For: 2.0.0 Beta See linked task -- 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

15 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1149) Singleton consumer on queue/topic

by Tim Fox (JIRA)

Singleton consumer on queue/topic --------------------------------- Key: JBMESSAGING-1149 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1149 Project: JBoss Messaging Issue Type: Feature Request Affects Versions: 1.4.0.SP1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.SP2 A last minute requirement came up from the AS team (Carlo and Bill DeCoste). JBoss MQ uses HA singleton to provide a singleton consumer on a queue/topic. If that node fails, the consumer should failover onto another single node. Currently this isn't supported in JBM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1400) Allow users to configure a system wide maximum connection limit

by Jay Howell (JIRA)

Allow users to configure a system wide maximum connection limit --------------------------------------------------------------- Key: JBMESSAGING-1400 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1400 Project: JBoss Messaging Issue Type: Feature Request Reporter: Jay Howell Assignee: Tim Fox Fix For: 2.0.0. GA Many users are complaining of errors that say "Too many open files", which comes from the number of sockets open during jms processing. It's currently possible to run the system out of resources. We currently only have control of this through the remoting/netty/mina layer. We should have a setting in JBM that limits the number of connections systemwide, that is independent of the remoting protocol/package. This way users wouldn't have to keep learning a new package/configuration setting each time the communications package changes in jbm. -- 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

15 years, 5 months

3
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1375) Validate if the journal directory is ext3 or ext2

by Clebert Suconic (JIRA)

Validate if the journal directory is ext3 or ext2 ------------------------------------------------- Key: JBMESSAGING-1375 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1375 Project: JBoss Messaging Issue Type: Feature Request Affects Versions: 2.0.0 Alpha Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 2.0.0 Beta If the journal dir is anything different than ext2 or ext3, we should use NIO instead. This includes SMB or Network mount points. a SAN should work fine as long as you use ext2 or 3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1432) ReceiveImmediate on consumer should check the server for messages

by Andy Taylor (JIRA)

ReceiveImmediate on consumer should check the server for messages ----------------------------------------------------------------- Key: JBMESSAGING-1432 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1432 Project: JBoss Messaging Issue Type: Task Components: Messaging Core Reporter: Andy Taylor Assignee: Tim Fox Priority: Minor Fix For: 2.0.0. GA When receiveImmediate() is called on a client consumer it only checks its internal buffer. It should also check with the server to make sure there are no messages in transit or waiting to be delivered. Once this is done the Queue Browser can be changed to use this instead of a timeout receive. -- 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

15 years, 5 months

3
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1325) Provide means for clustered server to be brought up and down cleanly

by Tim Fox (JIRA)

Provide means for clustered server to be brought up and down cleanly -------------------------------------------------------------------- Key: JBMESSAGING-1325 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1325 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta Should be able to bring up and shutdown a clustered server, and for it to auto-negotiate a backup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
4
0 / 0

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

by Jay Howell (JIRA)

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. GA 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

15 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-753) Similar to JBC/JGroups, add an ant-dist folder and build.bat/build.sh

by Galder Zamarreno (JIRA)

Similar to JBC/JGroups, add an ant-dist folder and build.bat/build.sh --------------------------------------------------------------------- Key: JBMESSAGING-753 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-753 Project: JBoss Messaging Issue Type: Feature Request Components: Build System Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Priority: Minor Fix For: 1.2.1 Add to source and make messaging add it to the binary distribution under util directory. That should speed up patching AS for customers and would guarantee that they use the Ant version that we want them to use. This is currently implemented in JBC and JGroups and I find it very useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

6
13
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008