August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBMESSAGING-200) Complete XA transaction recovery

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-200?page=all ] Tim Fox updated JBMESSAGING-200: -------------------------------- Fix Version/s: 1.0.2 (was: 1.0.4) Priority: Critical (was: Major) > Complete XA transaction recovery > -------------------------------- > > Key: JBMESSAGING-200 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-200 > Project: JBoss Messaging > Issue Type: Task > Components: JMS Facade > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Critical > Fix For: 1.0.2 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Complete XA transaction recovery. > Most of the work is already in place for this. > The remaining pars mainly revolve around integrating with Transaction Managers e.g. Arjuna (and maybe others!) so they can obtain a handle to the XAResource in order to carry out recovery. > The mechanism for this is not specified and so will vary from Transaction Manager to transaction manager. We need to supply wrappers for each popular Transaction Manager. > We also need to complete the tests for this. (Perhaps Arjuna already has some tests we can re-use?) -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-326) Improve synchronization on queue

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-326?page=comments#action_12... ] Tim Fox commented on JBMESSAGING-326: ------------------------------------- There is problem not much (nothing?) to do here now since I have refactored the channel for a fully "push" model > Improve synchronization on queue > -------------------------------- > > Key: JBMESSAGING-326 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-326 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.0.4 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > For even better throughput we can remove lock contention between adds and removes on the channel state (when there are more than a few nodes on the linked list). This can be done by using fine grained locking on individual nodes of the linked list. > We need to be very careful here to make sure paging semantics are preserved. -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-275) Move Selector processing IN the Channel

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-275?page=all ] Tim Fox updated JBMESSAGING-275: -------------------------------- Priority: Critical (was: Major) The way to do this is as follows: The PrioritizedDeque has an iterator (untested) that I recently added. Currently a Receiver returns null when it doesn't want to accept a reference, therefore there is currently no way of distinguishing that it doesn't want to accept the ref because it doesn't match a selector, or for some other reason (e.g. it's full). We need to know this extra information, so we should change the contract of handle() so it returns an enum value rather than null 0=closed, 1=on match on selector etc. Once we know this information, since now we push messages to receivers until no more or accepted, instead if we push a message and all receivers return "no match on selector" then the router should return this information to the channel in it's return value, then the channel can use PrioritizedDeque iterator to work backwards from the first item on the queue, trying them one by one until there are no more messages in memory. Initially I recommend we do not consider references paged to disc since this is a significant complication and we also do not use indexes as yet. > Move Selector processing IN the Channel > --------------------------------------- > > Key: JBMESSAGING-275 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-275 > Project: JBoss Messaging > Issue Type: Task > Components: Messaging Core > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Priority: Critical > Fix For: 1.0.2 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Currently, a consumer "arrests" a message that is being handled to it and doesn't match the Selector. That means it returns an active Delivery for it, but it doesn't forward the message to the client. This is because the consumer needs to be able to receiver further messages coming after the non-matching message, and that may potentially match the selector. > This is a poor solution that doesn't scale. We may end up with lots of non-matching messages being "arrested" by a consumer, while they could just be simply returned to the channel and forwarded to other potential consumers. > A possible (right) approach is to move selector processing in the Channel, so the message is not even handled to the non-accepting cosumer. Review this and refactor. -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBREM-452) Send the pre-release jar to the messaging team for testing

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-452?page=all ] Tom Elrod resolved JBREM-452. ------------------------------ Resolution: Done Have sent the latest jboss-remoting.jar for review by jms team. > Send the pre-release jar to the messaging team for testing > ---------------------------------------------------------- > > Key: JBREM-452 > URL: http://jira.jboss.com/jira/browse/JBREM-452 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Fix For: 2.0.0.CR1 (Boon) > > -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-412) Remoting Guide lacks left margin

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-412?page=all ] Tom Elrod updated JBREM-412: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.0.0.CR1 (Boon)) > Remoting Guide lacks left margin > -------------------------------- > > Key: JBREM-412 > URL: http://jira.jboss.com/jira/browse/JBREM-412 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.4.1 final > Reporter: Jerry Gauthier > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta1 (Bluto) > > > The pdf version of JBoss Remoting Guide version 1.4.1 lacks a left margin. This makes it difficult to use the documentation in a binder. -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-412) Remoting Guide lacks left margin

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-412?page=all ] Tom Elrod updated JBREM-412: ----------------------------- Tried to figure out how to change the conversion config for pdf formatting and failed quite profoundly. Have created jira issue for doc team to look into (JBDOCS-248) > Remoting Guide lacks left margin > -------------------------------- > > Key: JBREM-412 > URL: http://jira.jboss.com/jira/browse/JBREM-412 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.4.1 final > Reporter: Jerry Gauthier > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta1 (Bluto) > > > The pdf version of JBoss Remoting Guide version 1.4.1 lacks a left margin. This makes it difficult to use the documentation in a binder. -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-975) bug in management portlet during page refresh

by Boleslaw Dawidowicz (JIRA)

bug in management portlet during page refresh --------------------------------------------- Key: JBPORTAL-975 URL: http://jira.jboss.com/jira/browse/JBPORTAL-975 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4 Final Reporter: Boleslaw Dawidowicz when refreshing page with management portlets you get error like this : Client-id : jbp15f0ce3b_id234 is duplicated in the faces tree. -- 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

18 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (BPEL-199) BPEL reader does not contain logic to parse 1.1 fault handlers.

by Jiehuan Li (JIRA)

BPEL reader does not contain logic to parse 1.1 fault handlers. --------------------------------------------------------------- Key: BPEL-199 URL: http://jira.jboss.com/jira/browse/BPEL-199 Project: JBoss jBPM BPEL Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM BPEL 1.1 beta 1 Environment: JBoss 4.0.4 GA patch 1 on windows. Reporter: Jiehuan Li Assigned To: Alejandro Guizar >From Alex: I just reviewed the BPEL reader and it does not contain logic to parse 1.1 fault handlers, even tough the execution logic deals with them property. Please open a JIRA 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

18 years, 5 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2006