August 2009 - jboss-jira - Jboss List Archives

[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

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

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

16 years, 11 months

3
2
0 / 0

[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

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

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

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

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

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

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

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