Create safe mode where session concurrent access is checked
-----------------------------------------------------------
Key: JBMESSAGING-752
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-752
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 1.2.1
As per JMS spec, a JMS session is supposed to be only accessed from one thread at a time.
This is so the implementor does not have to synchronize access which might degrade performance.
However, users are often unaware of this and use the session concurrent by multiple threads, resulting in subtle or hard to identify bugs.
We should create a "safeMode", where if enabled, concurrent access is checked.
safeMode should be turned on for development and off for production, so no performance penalty is incurred in production.
--
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
Improve order preservation checking
-----------------------------------
Key: JBMESSAGING-1002
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1002
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Priority: Minor
Fix For: 2.0.0 Beta 1
The current version of order preservation involves preventing messages being sucked from one queue to another more than once.
This could be improved by encoding the nodeid/counter for each node sucked from in a header.
The counter would be reset every time all consumers are closed on a particular node.
A message won't be sucked to a node if its node id is encoded in the header and the distributor's current counter value matches the value in the header.
--
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
Merge after lost of network connectivity between cluster members (handle the split-brain situation)
---------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1173
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1173
Project: JBoss Messaging
Issue Type: Feature Request
Components: JMS Clustering
Affects Versions: 1.4.0.SP2
Environment: Any clustered
Reporter: Mike Clark
Assigned To: Tim Fox
JBM does not currently support the merging of cluster segments that have gotten into the "split-brain" situation. This occurs when network connectivity is lost between subsets of a cluster. Each subset assumes the other is gone and acts appropriately. When the network connectivity is restore, they do not merge back into a single cluster but remain as independent clusters (the spit-brain).
This feature request is to add cluster merging to prevent the split-brain situation.
--
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
JMS Inbound Resource Adapter does not support JMS1.1
----------------------------------------------------
Key: JBAS-4498
URL: http://jira.jboss.com/jira/browse/JBAS-4498
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.2.0.GA
Reporter: Adrian Brock
Fix For: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta3
The JMS inbound resource adapter's server session pool
does not support old JMS1.0.2b connections.
The issue is with JmsServerSession::setup() that only uses the 1.1 api to create sessions.
--
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
Synch up with the ide team on use of the VDF
--------------------------------------------
Key: JBAS-3774
URL: http://jira.jboss.com/jira/browse/JBAS-3774
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Deployment services
Reporter: Scott M Stark
Assigned To: Dimitris Andreadis
Fix For: JBossAS-5.0.0.Beta
Part of fleshing out the VDF should be the jbosside integration usecase.
--
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
Edit Messages inside Destination
--------------------------------
Key: JBMESSAGING-1046
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1046
Project: JBoss Messaging
Issue Type: Feature Request
Components: JMS Destination Manager
Reporter: Hendra Sasmita
Assigned To: Tim Fox
Priority: Optional
For administrative purpose, operators may want to change the message's content and/or properties.
As example, change all message that has content X, with content Y
--
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
Store the reference to the object instead of serializing object upon JBossObjectMessage.setObject.
--------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1167
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1167
Project: JBoss Messaging
Issue Type: Feature Request
Affects Versions: 1.4.0.SP1
Reporter: Jay Howell
Assigned To: Tim Fox
Object Serialization happens in the JBossObjectMessage.setObject and then the reference to the object is set to null. This means that if you are delivering messages within the same JVM, the objects still have to go through serialization. This request is to delay serialization until it needs to be sent across the wire.
This is a performance optimization aimed at preventing unnecessary serialization.
--
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
Discard consumer messages
-------------------------
Key: JBMESSAGING-1214
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1214
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 2.0.0 Beta
Some message data e.g. stock prices is transitory, if the consumer is slow, we don't want many messages for the consumer to build up in its subscription.
We should allow for the max number of messages to keep over and above the prefetch buffer to be specified.
Older messages are removed.
--
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