September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBAS-1891) Allow chunking of message during recovery

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1891?page=all ] Adrian Brock closed JBAS-1891. ------------------------------ Fix Version/s: JBossAS-4.0.4.GA Resolution: Done This was already done in 4.0.4, see RecoveryMessagesChunk here: http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQJDBC2Persistence > Allow chunking of message during recovery > ----------------------------------------- > > Key: JBAS-1891 > URL: http://jira.jboss.com/jira/browse/JBAS-1891 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.1 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-3.2.7 Final > Reporter: Adrian Brock > Priority: Minor > Fix For: JBossAS-4.0.4.GA > > > Allow messages to be loaded in "chunks" during the recovery process. > Need to discuss/understand how this can be done where it requires vendor specific processing, > e.g. see the top level problem for the MySQL issue. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1348) Message Selector Performance

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1348?page=all ] Adrian Brock closed JBAS-1348. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Message Selector Performance > ---------------------------- > > Key: JBAS-1348 > URL: http://jira.jboss.com/jira/browse/JBAS-1348 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > Reporter: Adrian Brock > Priority: Minor > > Improving Message Selector Performance > It is a common anti-pattern for users to set up a contested queue > where multiple receivers try to take messages based on a message selector. > In most circumstances a Topic is what they should be using. > But there is a circumstance where a Topic does not work as required, > that is when a message matches many of the receiver's selector but you > only want one receiver to process the message (it doesn't matter which). > The problem is that when a receiver does not match a message towards > the top of a large Queue (or none at all). The operation to find a message > or discover there are no messages is very expensive. It is read and skip. > This can be even worse when the bottom of the queue has been moved out > to disk by the MessageCache. > The solution is to provide "an index" over a particular property, > e.g. > <mbean code="org.jboss.mq.server.jmx.Queue" > name="jboss.mq.destination:service=Queue,name=A"> > <optimized-selector>JMSMessageID</optimized-selector> > <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends> > </mbean> > This configuration should be passed via the BasicQueueParameters to the BasicQueue. > NOTE: This is irrevelent for Topics. Topics run their selector before the message is added > to the subscription, anything not matching the selector is dropped. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1300) Non-Remote JMS HA

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1300?page=all ] Adrian Brock closed JBAS-1300. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Non-Remote JMS HA > ----------------- > > Key: JBAS-1300 > URL: http://jira.jboss.com/jira/browse/JBAS-1300 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final > Reporter: Andrew Oliver > Priority: Minor > Original Estimate: 1 week > Remaining Estimate: 1 week > > It should be possible to use JMS on all servers in a cluster with HA enabled. Meaning: > 1. Database as a store. Everyone node uses shared DB. > 2. JMS_MESSAGES table includes node name > 3. In the event of group membership changes another node picks up the old node's messages > 4. JMS Client proxy autofails to another node -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1349) Message Bridge

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1349?page=all ] Adrian Brock closed JBAS-1349. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Message Bridge > -------------- > > Key: JBAS-1349 > URL: http://jira.jboss.com/jira/browse/JBAS-1349 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > Reporter: Adrian Brock > Priority: Minor > > Implementation of a MessageBridge. > ---------------------------------- > This is a proxy that allows messages to be sent to one JMS server > and then forwarded to the real destination. > To the senders this looks like a plain queue or topic. > This is the simplist implementation, more performant implementations are possible: > 1) Implement the bridge as a new destination type within JBossMQ > 2) It will behave similarly to a Queue but will not accept external receivers. > 3) On a background thread (inside a JTA transaction) > take some messages from the queue and send them to the real destination. > 4) The background thread should automatically recover from a failed connection > and retry at configurable intervals. Similarly it should keep retrying if > the connection cannot be instantiated at initial startup. > This is similar to what the MDB does. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1345) Clustered Invocation Layer

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1345?page=all ] Adrian Brock closed JBAS-1345. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Clustered Invocation Layer > -------------------------- > > Key: JBAS-1345 > URL: http://jira.jboss.com/jira/browse/JBAS-1345 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > Reporter: Adrian Brock > Priority: Minor > > Clustered Invocation Layer > 1) Transportation of the cluster view to the client. > 2) Persistent connections that allows the server to recover the client's state after a failure. > Both these together will mean the client can transparently failover after a server failure. > The persistent connections could be used without clustering where the client waits for server recovery. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1342) Message Serialization

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1342?page=all ] Adrian Brock closed JBAS-1342. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Message Serialization > --------------------- > > Key: JBAS-1342 > URL: http://jira.jboss.com/jira/browse/JBAS-1342 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > Reporter: Adrian Brock > Fix For: JBossAS-4.0.6.CR1 > > Attachments: JBAS-1342-SpyTextMessage.zip > > > The message body does not need to be deserialized on the server. > It could just be retained as byte[] > This will avoid unnecessary Object serialiation at the transport and persistent layer > inside the server. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBAS-2583) Potential for runaway allocation of Connection objects

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2583?page=all ] Adrian Brock reopened JBAS-2583: -------------------------------- > Potential for runaway allocation of Connection objects > ------------------------------------------------------ > > Key: JBAS-2583 > URL: http://jira.jboss.com/jira/browse/JBAS-2583 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Natalia Kowalczyk > > org.jboss.mq.Connection class uses a singleton EDU.oswego.cs.dl.util.concurrent.ClockDaemon to handle pinging of open connections. When connection is opened a ping task is scheduled by inserting into EDU.oswego.cs.dl.util.concurrent.Heap structure maintained internally by ClockDaemon. When connection is closed, its ping task is marked as canceled and subsequently extracted from the Heap by a single thread maintained internally by ClockDaemon. > Inserting into Heap structure can be performed by many threads (as part of opening a connection) but extracting is only done by a single thread (in ClockDeamon). As Heap.extract() is a little slower then Heap.insert(), under sufficient system load, ClockDeamon thread may fall behind in its job of removing canceled ping tasks (corresponding to closed connections). If the load on a system persists sufficiently long, JVM will run out of memory because of the canceled ping tasks that ClockDaemon can't extract fast enough. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2464) Support JMSX properties

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2464?page=all ] Adrian Brock closed JBAS-2464. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Support JMSX properties > ----------------------- > > Key: JBAS-2464 > URL: http://jira.jboss.com/jira/browse/JBAS-2464 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Adrian Brock > Fix For: JBossAS-4.0.6.CR1 > > > Look at supporting other JMSX properties in JBossMQ -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2583) Potential for runaway allocation of Connection objects

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2583?page=all ] Adrian Brock closed JBAS-2583. ------------------------------ Resolution: Deferred > Potential for runaway allocation of Connection objects > ------------------------------------------------------ > > Key: JBAS-2583 > URL: http://jira.jboss.com/jira/browse/JBAS-2583 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Natalia Kowalczyk > > org.jboss.mq.Connection class uses a singleton EDU.oswego.cs.dl.util.concurrent.ClockDaemon to handle pinging of open connections. When connection is opened a ping task is scheduled by inserting into EDU.oswego.cs.dl.util.concurrent.Heap structure maintained internally by ClockDaemon. When connection is closed, its ping task is marked as canceled and subsequently extracted from the Heap by a single thread maintained internally by ClockDaemon. > Inserting into Heap structure can be performed by many threads (as part of opening a connection) but extracting is only done by a single thread (in ClockDeamon). As Heap.extract() is a little slower then Heap.insert(), under sufficient system load, ClockDeamon thread may fall behind in its job of removing canceled ping tasks (corresponding to closed connections). If the load on a system persists sufficiently long, JVM will run out of memory because of the canceled ping tasks that ClockDaemon can't extract fast enough. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2583) Potential for runaway allocation of Connection objects

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2583?page=all ] Adrian Brock closed JBAS-2583. ------------------------------ Resolution: Done Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Potential for runaway allocation of Connection objects > ------------------------------------------------------ > > Key: JBAS-2583 > URL: http://jira.jboss.com/jira/browse/JBAS-2583 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Natalia Kowalczyk > > org.jboss.mq.Connection class uses a singleton EDU.oswego.cs.dl.util.concurrent.ClockDaemon to handle pinging of open connections. When connection is opened a ping task is scheduled by inserting into EDU.oswego.cs.dl.util.concurrent.Heap structure maintained internally by ClockDaemon. When connection is closed, its ping task is marked as canceled and subsequently extracted from the Heap by a single thread maintained internally by ClockDaemon. > Inserting into Heap structure can be performed by many threads (as part of opening a connection) but extracting is only done by a single thread (in ClockDeamon). As Heap.extract() is a little slower then Heap.insert(), under sufficient system load, ClockDeamon thread may fall behind in its job of removing canceled ping tasks (corresponding to closed connections). If the load on a system persists sufficiently long, JVM will run out of memory because of the canceled ping tasks that ClockDaemon can't extract fast enough. -- 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

19 years, 10 months

1
0
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 September 2006