August 2009 - jboss-jira - Jboss List Archives

[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

16 years, 11 months

2
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1675) add netty servlet firewall support when available.

by Andy Taylor (JIRA)

add netty servlet firewall support when available. -------------------------------------------------- Key: JBMESSAGING-1675 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1675 Project: JBoss Messaging Issue Type: Task Affects Versions: 2.0.0.beta3 Reporter: Andy Taylor Assignee: Andy Taylor Fix For: 2.0.0 -- 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

16 years, 11 months

3
2
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

16 years, 11 months

3
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1686) Add more transactional options for the JCA adapter

by Clebert Suconic (JIRA)

Add more transactional options for the JCA adapter -------------------------------------------------- Key: JBMESSAGING-1686 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1686 Project: JBoss Messaging Issue Type: Feature Request Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.0.0 It should be possible to configure transactions for MDBs in a better fashion. Like receiving messages non-transactionally, or batching a number of transactions, even if this would mean non-compliant but activated by the user's choice. We already have: - Local Transaction - XA Transaction The options I'm thinking: We should add: - Batching transactions (commit on every X records... like most users do when processing a high number of messages outside the application server) - NonTransactional (messages being received non transactionally.. what should be good for Non Persistent Messages) -- 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

16 years, 11 months

2
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

16 years, 11 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

16 years, 11 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

16 years, 11 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

16 years, 11 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

16 years, 11 months

6
13
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1569) Add test for failing onto backup, then copying backup dir

by Tim Fox (JIRA)

Add test for failing onto backup, then copying backup dir --------------------------------------------------------- Key: JBMESSAGING-1569 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1569 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assignee: Tim Fox Fix For: 2.0.0.CR1 Add a test for server failing over to backup doing some work, closing both down, then copying over data directory from backup to live and restarting -- 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

16 years, 11 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2009