August 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1463) Possible Orphaned Files On LargeMessages

by Clebert Suconic (JIRA)

Possible Orphaned Files On LargeMessages ---------------------------------------- Key: JBMESSAGING-1463 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1463 Project: JBoss Messaging Issue Type: Task Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.0.0 Beta If the server crash after the .tmp file is renamed, and before it is added to Journal or Paging, it may be orphaned. The possible fix would probably be to inspect the Page and Journal Files and find out what files are orphaned. Maybe we could delay the verification until an user with admin privileges request to identify orphaned files through management. -- 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, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1330) Allow maxSize (etc) to be specified when creating a queue using core API

by Tim Fox (JIRA)

Allow maxSize (etc) to be specified when creating a queue using core API ------------------------------------------------------------------------ Key: JBMESSAGING-1330 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1330 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox 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: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1645) Multi-threaded replication

by Tim Fox (JIRA)

Multi-threaded replication -------------------------- Key: JBMESSAGING-1645 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1645 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assignee: Tim Fox Fix For: 2.0.0.GA Currently replication between live and backup node is done on a single thread. The operation is replicated, executed on backup, and when the result is returned to live, it is executed on live before the result is returned to the client (if applicable). This ensures the same ordering of state changes on live and backup but effectively makes all operation single threaded, thus reducing throughput in a clustered set-up. Instead we should implement multi-threaded replication. If replicated operations are being executed concurrently on backup it is more tricky to ensure that state changes on any object occur in the same order as on live but it is possible. This is how we can do it. For the following types of objects it is important that their state changes occur in the same order on live and backup 1) Sessions (S) 2) Queues (Q) 3) Post offices. (P) Operations that occur on the live node are either a) Initiated externally - e.g. an operation like send message or acknowledge coming from a client b) Initiated internally - e.g. an asynchronous delivery, a depage, or an asynchronous message expiry from the reaper As any of these operations are being executed they may affect the state of one or more stateful objects, e.g. a send operation might affect the state of S1, Q1, Q2, S2, and S3 (as a sent message is routed to Q1 and Q2 and immediately delivered to S2 and S3). When the operation is replicated to the backup we must ensure that the state changes on any affected stateful objects must occur in the same order as they did on live. To do this as the operation is executed and the state changes occur, each stateful object is locked in turn, and a sequence number is obtained from the stateful object which tells us we're the nth stateful operation on that object. So a send operation might end up with a set of state sequences numbers: S1(12), Q1(102), Q2(32), S2 (74), S3 (1038) Which tells us the operation cause the 12th state change on object S1, followed by the 102nd state change on object Q1 etc. The list of sequence numbers can be stored in a thread local as the operation is executed on live. When the operation is executed on live we delay sending back any data to the client until we have replicate the operation to the backup and got a response that the replication has been processed. To ensure the state changes occur in the same order on backup, when we replicate the operation we also replicate the list state sequence numbers. When the operation is executed on the backup we attempt to obtain the locks on the stateful objects. Say we try to get the lock on object Q1, but the current sequence number of the object Q1 on the backup is 100, the attempt to get the lock will block until the 101st state change is executed since we require that operation is the 102nd state change. By using such a technique we can ensure that state changes are obtained in the same order on live and backup but are not limited to a single thread. In many cases the objects will be in the expected or similar sequence numbers so the replications can occur in parallel. In case of failure of the live node, operations may block indefinitely on the backup waiting for replications to arrive for missing state changes. For this we can timeout on the lock and reverse state changes. -- 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, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1315) Implement client "freeze" test

by Tim Fox (JIRA)

Implement client "freeze" test ------------------------------ Key: JBMESSAGING-1315 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1315 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta Implement a test which freezes (hangs) a client, and makes sure the server disconnects it without the server freezing or delivery getting blocked. -- 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, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1583) Fix message redistribution with replication

by Tim Fox (JIRA)

Fix message redistribution with replication ------------------------------------------- Key: JBMESSAGING-1583 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1583 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assignee: Tim Fox Fix For: 2.0.0.CR1 Message redistribution in a replicated cluster is currently broken. Needs to be fixed and thoroughly tested. -- 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, 9 months

2
3
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-152) Refactor exception handling

by Tim Fox (JIRA)

[ https://jira.jboss.org/jira/browse/JBMESSAGING-152?page=com.atlassian.jir... ] Tim Fox updated JBMESSAGING-152: -------------------------------- Fix Version/s: 2.0.0.beta5-tmp (was: 2.0.0.beta5) > Refactor exception handling > --------------------------- > > Key: JBMESSAGING-152 > URL: https://jira.jboss.org/jira/browse/JBMESSAGING-152 > Project: JBoss Messaging > Issue Type: Task > Components: JMS Facade > Reporter: Tim Fox > Assignee: Tim Fox > Priority: Minor > Fix For: 2.0.0 > > Original Estimate: 1 day, 4 hours > Remaining Estimate: 1 day, 4 hours > > We should audit the exception handling. > In some areas it is quite sloppy including anti-patterns such as: > 1. Logging errors when they're not being handled > 2. Rethrowing with less information. E.g. losing the message or original exception. > 3. Too much usage of "throws Throwable" or "throws Exception" where probably unnecessary. > 4. Swallowing exceptions. > We need to go through the whole of the code, auditing and changing as necessary. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1609) Provide Destination deploying through Beans

by Clebert Suconic (JIRA)

Provide Destination deploying through Beans ------------------------------------------- Key: JBMESSAGING-1609 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1609 Project: JBoss Messaging Issue Type: Feature Request Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.0.0.CR1 This should be very simple to implement. An user may choose to deploy a destination using Beans, so he could hot-deploy queues with his applications in a way it would work with MDBs. -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1433) Enable replication for browsers

by Tim Fox (JIRA)

Enable replication for browsers ------------------------------- Key: JBMESSAGING-1433 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1433 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assignee: Tim Fox Fix For: 2.0.0 Beta Making a copy of the queue for a browser consumer doesn't work well with replication since When replicating the create consumer (browser) to the backup, when executed on the backup the backup may have different messages in its queue since been added on different threads. So when replicating deliveries they may not be found. Uncomment MultiThreadRandomFailoverTest::testM when this is complete. -- 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, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1587) Add trace logging

by Tim Fox (JIRA)

Add trace logging ----------------- Key: JBMESSAGING-1587 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1587 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assignee: Tim Fox Fix For: 2.0.0.CR1 Add trace logging throughout, will aid in diagnosing issues in a production environment. -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1626) The backup queue could get out of order after Depage

by Clebert Suconic (JIRA)

The backup queue could get out of order after Depage ---------------------------------------------------- Key: JBMESSAGING-1626 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1626 Project: JBoss Messaging Issue Type: Bug Affects Versions: 2.0.0 Beta Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.0.0 Beta In an edge case scenario, where there are too many subscriptions during page/depage the backup node queue could get out of order what would cause issues with replicateDelivery. similar to what happened on JBMESSAGING-1558 -- 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, 9 months

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