September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-3183) Integration with WebSphere MQ 5.x

by Weston Price (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3183?page=all ] Weston Price updated JBAS-3183: ------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.GA) Moving to 4.0.6 > Integration with WebSphere MQ 5.x > --------------------------------- > > Key: JBAS-3183 > URL: http://jira.jboss.com/jira/browse/JBAS-3183 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Environment: WebSphereMQ 5.3 with Extended TX client > Reporter: Luc Texier > Assigned To: Weston Price > Priority: Critical > Fix For: JBossAS-4.0.6.CR1 > > Attachments: mq-trace.jar, mq-xa.zip > > > http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingWebSphereMQSeriesWithJBossA... > we need to make some changes to StdServerSession and StdServerSessionPool to integrate two workarounds in order to properly integrate with WSMQ 5.x and support their XA resource implementation and transaction handling -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-3071) MemoryLeak (redeployment) on EJB3

by Emmanuel Bernard (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3071?page=all ] Emmanuel Bernard reassigned JBAS-3071: -------------------------------------- Assignee: Bill Burke (was: Emmanuel Bernard) I'm removing my assignment. My part has been fixed but I see things on the Timer and the ThreadLocal, reassigning to Bill so that he can dispatch to someone else. > MemoryLeak (redeployment) on EJB3 > --------------------------------- > > Key: JBAS-3071 > URL: http://jira.jboss.com/jira/browse/JBAS-3071 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB3 > Affects Versions: JBossAS-4.0.4.CR2 > Reporter: Clebert Suconic > Assigned To: Bill Burke > Priority: Critical > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA > > > This might be caused by JBAS-3016: > But I'm seeing this strong reference: > org.jboss.mx.loading.UnifiedClassLoader3@33411906 > !--- org.jboss.ejb3.stateless.StatelessContainer@29610827 > We should make sure EJB3 packages are not leaking. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-132) Incorrect Uid values used in JTA/JTS XAResourceRecord

by Kevin Conner (JIRA)

Incorrect Uid values used in JTA/JTS XAResourceRecord ----------------------------------------------------- Key: JBTM-132 URL: http://jira.jboss.com/jira/browse/JBTM-132 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation Affects Versions: 4.2.1 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.2.2 Both versions of XAResourceRecord support an interface for indiciating that a resource should be the first or last to be called. This is achieved by assigning a specific Uid to those resources but the one used for the first resource is incorrect. The values used by both is 0:0:0:1 which was never the lowest Uid. These values should also be handled directly by the Uid class so that they can remain consistent. -- 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, 8 months

1
3
0 / 0

[JBoss JIRA] Assigned: (JBAS-3071) MemoryLeak (redeployment) on EJB3

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3071?page=all ] Dimitris Andreadis reassigned JBAS-3071: ---------------------------------------- Assignee: Emmanuel Bernard (was: Bill Burke) > MemoryLeak (redeployment) on EJB3 > --------------------------------- > > Key: JBAS-3071 > URL: http://jira.jboss.com/jira/browse/JBAS-3071 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB3 > Affects Versions: JBossAS-4.0.4.CR2 > Reporter: Clebert Suconic > Assigned To: Emmanuel Bernard > Priority: Critical > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA > > > This might be caused by JBAS-3016: > But I'm seeing this strong reference: > org.jboss.mx.loading.UnifiedClassLoader3@33411906 > !--- org.jboss.ejb3.stateless.StatelessContainer@29610827 > We should make sure EJB3 packages are not leaking. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-131) XidImple requires serialVersionUID

by Kevin Conner (JIRA)

XidImple requires serialVersionUID ---------------------------------- Key: JBTM-131 URL: http://jira.jboss.com/jira/browse/JBTM-131 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Kevin Conner Assigned To: Mark Little The change for JBTM-84 changed the serialVersionUID for the Xid implementation. The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version. -- 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, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (JBTM-130) Validation of timeout values before calling the reaper

by Kevin Conner (JIRA)

Validation of timeout values before calling the reaper ------------------------------------------------------ Key: JBTM-130 URL: http://jira.jboss.com/jira/browse/JBTM-130 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation Affects Versions: 4.2.1 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.2.2 There are a number of places which allow invalid values to be passed to the transaction reaper. We need to review all paths through to the reaper and tidy these up. -- 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, 8 months

1
3
0 / 0

[JBoss JIRA] Closed: (JBTM-81) Delay start of recovery manager

by Kevin Conner (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-81?page=all ] Kevin Conner closed JBTM-81. ---------------------------- > Delay start of recovery manager > ------------------------------- > > Key: JBTM-81 > URL: http://jira.jboss.com/jira/browse/JBTM-81 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation > Affects Versions: 4.2 > Reporter: Mark Little > Assigned To: Kevin Conner > Priority: Minor > Fix For: 4.2.2 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Currently the Recovery Manager begins working as soon as JBossAS starts. When the local JTA implementation is used and there is a transaction to recover, we get the following stack trace: > 10:52:35,529 WARN [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.restorestate] [com.arjuna.ats.interna\ > l.jta.resources.arjunacore.restorestate] Exception on attempting to restore XAResource > java.io.StreamCorruptedException: unexpected end of block data > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1321) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:879) > at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1410) > at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:711) > at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:673) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:60) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecovery\ > Module.java:178) > This is because the rest of the system isn't yet fully initialised. The next periodic run of recovery does not suffer this problem and recovery completes successfully. We should look at delaying the start of the Recovery Manager until JBossAS is fully initialised. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBTM-81) Delay start of recovery manager

by Kevin Conner (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-81?page=all ] Kevin Conner resolved JBTM-81. ------------------------------ Resolution: Done Fixed in revision 6408 > Delay start of recovery manager > ------------------------------- > > Key: JBTM-81 > URL: http://jira.jboss.com/jira/browse/JBTM-81 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation > Affects Versions: 4.2 > Reporter: Mark Little > Assigned To: Kevin Conner > Priority: Minor > Fix For: 4.2.2 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Currently the Recovery Manager begins working as soon as JBossAS starts. When the local JTA implementation is used and there is a transaction to recover, we get the following stack trace: > 10:52:35,529 WARN [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.restorestate] [com.arjuna.ats.interna\ > l.jta.resources.arjunacore.restorestate] Exception on attempting to restore XAResource > java.io.StreamCorruptedException: unexpected end of block data > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1321) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:879) > at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1410) > at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:711) > at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:673) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:60) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecovery\ > Module.java:178) > This is because the rest of the system isn't yet fully initialised. The next periodic run of recovery does not suffer this problem and recovery completes successfully. We should look at delaying the start of the Recovery Manager until JBossAS is fully initialised. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-116) setting of default timeout logic broken in mbean

by Mark Little (JIRA)

setting of default timeout logic broken in mbean ------------------------------------------------ Key: JBTM-116 URL: http://jira.jboss.com/jira/browse/JBTM-116 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2.2 The mbean code for setting the default timeout says: public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException { if (timeout > 0) { TxControl.setDefaultTimeout(timeout); } else throw new javax.transaction.SystemException("Transaction Timeout < 0"); } This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate. -- 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, 8 months

2
10
0 / 0

[JBoss JIRA] Closed: (JBTM-87) Put back LRCO JTA interface

by Kevin Conner (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-87?page=all ] Kevin Conner closed JBTM-87. ---------------------------- > Put back LRCO JTA interface > --------------------------- > > Key: JBTM-87 > URL: http://jira.jboss.com/jira/browse/JBTM-87 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation > Affects Versions: 4.2 > Reporter: Mark Little > Assigned To: Kevin Conner > Priority: Minor > Fix For: 4.2.2 > > > The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now. -- 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, 8 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