August 2009 - jboss-jira - Jboss List Archives

[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

14 years, 8 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

14 years, 8 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

14 years, 8 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

14 years, 8 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

14 years, 8 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

14 years, 8 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

14 years, 8 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-357) Update design documentation

by Tim Fox (JIRA)

[ https://jira.jboss.org/jira/browse/JBMESSAGING-357?page=com.atlassian.jir... ] Tim Fox updated JBMESSAGING-357: -------------------------------- Fix Version/s: 2.0.0.beta5-tmp (was: 2.0.0.beta5) > Update design documentation > --------------------------- > > Key: JBMESSAGING-357 > URL: https://jira.jboss.org/jira/browse/JBMESSAGING-357 > Project: JBoss Messaging > Issue Type: Task > Components: Documentation and Training > Reporter: Ovidiu Feodorov > Fix For: 2.0.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Make sure design documentation for JBM 2 exists and is up to date. > All areas of design should be documentated. -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1542) Add more failover tests for paging

by Clebert Suconic (JIRA)

Add more failover tests for paging ---------------------------------- Key: JBMESSAGING-1542 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1542 Project: JBoss Messaging Issue Type: Task Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.0.0 Beta -- 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

14 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1649) redesign management replication

by Jeff Mesnil (JIRA)

redesign management replication ------------------------------- Key: JBMESSAGING-1649 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1649 Project: JBoss Messaging Issue Type: Task Affects Versions: 2.0.0 Beta Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 2.0.0 In order for management operation using JMX to be replicated, the MBeans are translating the management operation to a management messages which is sent to the management address using Core API. This allows for management messages to be properly replicated. However this allow forces the server to have an acceptor and a connector to talk to *itelsf* which is configusing and clutter the server configuration. The management code should be redesigned to be plugged directly on the server-side. The management service'd no longer send a Core message using the Core API. Instead it'd call directly the ServerSessionPacketHandler (or equivalent) to handle a packet corresponding to the management message. It'll work since the handler will then replicate the packet correctly. -- 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

14 years, 8 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2009