November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBTM-162) Move TS generic text from JTS guides

by Mark Little (JIRA)

Move TS generic text from JTS guides ------------------------------------ Key: JBTM-162 URL: http://jira.jboss.com/jira/browse/JBTM-162 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.2.1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.6 Such as TxStats references. -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBTM-111) Check QA into CVS

by Mark Little (JIRA)

Check QA into CVS ----------------- Key: JBTM-111 URL: http://jira.jboss.com/jira/browse/JBTM-111 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Testing Affects Versions: 4.2 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.4 -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-161) Update Web site for EE5/JDK5 support

by Mark Little (JIRA)

Update Web site for EE5/JDK5 support ------------------------------------ Key: JBTM-161 URL: http://jira.jboss.com/jira/browse/JBTM-161 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Release Affects Versions: 4.2.1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.4 http://labs.jboss.com/portal/jbosstm/resources/product_overview/features.... -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-160) Make supported platforms clearer on web site.

by Mark Little (JIRA)

Make supported platforms clearer on web site. --------------------------------------------- Key: JBTM-160 URL: http://jira.jboss.com/jira/browse/JBTM-160 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Release Affects Versions: 4.2.1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.4 -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-169) Support multiple one-phase resources

by Mark Little (JIRA)

Support multiple one-phase resources ------------------------------------ Key: JBTM-169 URL: http://jira.jboss.com/jira/browse/JBTM-169 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Documentation, JTA Implementation Affects Versions: 4.2.2 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.4 JBossTM allowed multiple one-phase only resources to be enlisted with the same JTA transaction. JBossTS supports the LRCO, which only allows a single one-phase resource to be enlisted. This difference may cause problems for some people migrating from JBossTM to JBossTS. However, it is an unsafe mode of operation and we should discourage people from using transactions in this way: it can lead to inconsistent/corrupted data in the presence of failures. We will add a switch to enable this capability. It will be disabled by default. People must actively enable this capability and in the process of doing so will be refered to the documentation which will outline the problems they may face by doing so. Furthermore, when a JTA transaction sees more than one 1-phase resource, it will issue a warning. -- 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, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-445) Update user documentation with clustering-related details

by Ovidiu Feodorov (JIRA)

Update user documentation with clustering-related details --------------------------------------------------------- Key: JBMESSAGING-445 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-445 Project: JBoss Messaging Issue Type: Task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.CR1 -- 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, 5 months

2
9
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-447) Release 1.2.0 GA after waiting for a week for feedback on the latest CR

by Ovidiu Feodorov (JIRA)

Release 1.2.0 GA after waiting for a week for feedback on the latest CR ----------------------------------------------------------------------- Key: JBMESSAGING-447 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-447 Project: JBoss Messaging Issue Type: Task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2 -- 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, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3414) Port EJBDeployer

by Scott M Stark (JIRA)

Port EJBDeployer ---------------- Key: JBAS-3414 URL: http://jira.jboss.com/jira/browse/JBAS-3414 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Deployment services, EJB2 Reporter: Scott M Stark Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta The EJBDeployer needs to be ported to the new VDF and interaction with the EJB3 deployer defined -- 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, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-710) Cleanup E-EJB3 package/code/logging

by Christian Bauer (JIRA)

Cleanup E-EJB3 package/code/logging ----------------------------------- Key: EJBTHREE-710 URL: http://jira.jboss.com/jira/browse/EJBTHREE-710 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - FD Reporter: Christian Bauer Priority: Blocker This is E-EJB3 RC9. The following issues are not minor, they would make me feel uneasy if I was a user: 1. The bundled embedded-jboss-beans.xml uses xmlns="urn:jboss:bean-deployer" and everybody gets a nice WARN on startup that xmlns="urn:jboss:bean-deployer:2.0" should be used. Change that in the distributed configuration file. 2. [java] 13:40:10,676 WARN Ejb3Configuration:104 - Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null. It's OK to warn users that something is not right, but if something is not right in our distribution there should be a note in the README or something that tells me as a user that this is OK for the moment. Like a link to a JIRA issue. 3. [java] 13:44:59,381 WARN JBossTimerServiceFactory:112 - TIMER SERVICE IS NOT INSTALLED -- Uh, yes, because I don't want it. Find a way for users to disable this warning. I don't see any way to disable the timer service in embedded-jboss-beans.xml and I don't want the .rar and .jar in my libs. 4. In RC9 there is code that prints debugging stuff on STDOUT: [java] lookup [java] UserTransaction: org.jboss.ejb3.embedded.UserTransactionImpl [java] MessageHandlerBean: org.jnp.interfaces.NamingContext This is triggered by EJB3StandaloneBootstrap.scanClasspath("helloworld-ejb3/build"), please remove from code... -- 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, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-814) Concurrency issue with passivation

by Brian Stansberry (JIRA)

Concurrency issue with passivation ---------------------------------- Key: JBCACHE-814 URL: http://jira.jboss.com/jira/browse/JBCACHE-814 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0.SP1 Reporter: Brian Stansberry Assigned To: Manik Surtani If the eviction thread attempts to passivate a node roughly concurrently with a get() call, it is quite easy for the get() to return null even though the passivated node has data. Test org.jboss.cache.passivation.ConcurrentPassivationTest shows the problem. I believe the problem results from having the PessimisticLockInterceptor in the chain after the Activation and Passivation interceptors. Potential cause is a race to the PessimisticLockInterceptor between the eviction thread and an application thread doing a get(). 1) Eviction thread wins race, acquires a WL on a node. 2) Application thread is trailing in the race but proceeds through the Activation/Passivation interceptors w/o loading data, because the desired node is still in the cache. 3) Application thread blocks waiting for eviction thread's WL to be released. 4) Eviction thread removes the node from the tree structure. 5) Eviction thread releases the WL. Application thread acquires a RL (it already had a ref to the node). 6) Application thread gets to the cache _get method, which can't find the node in the tree structure, and thus returns null. Another variation on the same theme: 1) Eviction thread wins race, acquires a WL on a node. 2) Application thread is trailing in the race but proceeds through the Activation/Passivation interceptors w/o loading data, because the desired node is still in the cache. 3) Eviction thread removes the node from the tree structure. 4) Application thread gets to PessimisticLockInterceptor, which can't find the node. No need to acquire lock on non-existent node, so thread proceeds. 5) Application thread gets to the cache _get method, which can't find the node in the tree structure, and thus returns null. -- 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, 5 months

3
7
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 November 2006