December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-700) Delivery count is not updated for transactional sessions on close

by Tim Fox (JIRA)

Delivery count is not updated for transactional sessions on close ----------------------------------------------------------------- Key: JBMESSAGING-700 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-700 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta2 When closing a transactional session which still has uncomitted deliveries in it, then these end up being cancelled when the session closes on the server, therefore losing any delivery count information. Instead, we should explicitly cancel any messages in the transactional state as part of the close protocol, as we currently do with non transactional remaining deliveries. -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPM-817) ContextInstance.setVariable() behaves very inperformant

by Mirco Graf (JIRA)

ContextInstance.setVariable() behaves very inperformant ------------------------------------------------------- Key: JBPM-817 URL: http://jira.jboss.com/jira/browse/JBPM-817 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.2 Reporter: Mirco Graf Assigned To: Tom Baeyens When setting a process variable, jBPM tries to map the variable to a jBPM-internal data-type (StringVariable, LongVariable etc.). When comparing the given variable-value to existing jBPM-types, the Class org.jbpm.context.exe.JbpmType always performs an XML-parsing of the ressource "resource.varmapping" to get all available types without any caching. The types usually should be cached as the property "jbpm.types", but it seems like jbpm never uses the cache and always performs an XML-parsing. In the following method of Class org.jbpm.context.exe.JbpmType the else-case is *always* executed, seems like the property "jbpm.types" is not set correctly. public static List getJbpmTypes() { List jbpmTypes = null; if (JbpmConfiguration.Configs.hasObject("jbpm.types")) { jbpmTypes = (List) JbpmConfiguration.Configs.getObject("jbpm.types"); } else { jbpmTypes = getDefaultJbpmTypes(); } return jbpmTypes; } While profiling my app i realized that getJbpmTypes()-Operations took about 30% of the whole application-runtime, about 15ms in average. -- 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, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-3398) Non exploded sar containing war cannot undeploy the war file properly

by Julien Viet (JIRA)

Non exploded sar containing war cannot undeploy the war file properly --------------------------------------------------------------------- Key: JBAS-3398 URL: http://jira.jboss.com/jira/browse/JBAS-3398 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final Environment: JBoss-4.0.4.GA MacOSX Tiger Java 1.4.2 Reporter: Julien Viet Assigned To: Dimitris Andreadis Fix For: JBossAS-4.0.5.CR1, JBossAS-5.0.0.GA A sar file containing a war file non exploded is dropped in AS before startup. Start JBoss Shutdown JBoss The MainDeployer wants to stop() / destroy() the war file. The Web deployer is already gone and it produces an javax.management.InstanceNotFoundException when it tries to stop() / destroy() the war deployer Because the war is nested in a sar file, the web deployer is undeployed before the sar containing the war is undeployed. Note : this does not happen with exploded sar (like http invoker sar that contains the invoker.war) because the war is added to the MainDeployer.deploymentList list. This does not happen with non exploded because the war file is not in the local directory but rather in tmp and thus does not get added to the deployment list. Here are some field values : the string used to discriminate wether it's in local or tmp - file:/Users/julien/java/jboss-4.0.4.GA/server/default/tmp/deploy/ a war in non exploded sar - file:/Users/julien/java/jboss-4.0.4.GA/server/default/tmp/deploy/tmp51485jboss-portal.sar-contents/portal-core.war invoker.war in exploded sar - file:/Users/julien/java/jboss-4.0.4.GA/server/default/deploy/http-invoker.sar/invoker.war/ -- 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, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-3860) XAManagedConnection should implement LocalTransaction to clean up hanging LocalTransaction

by Weston Price (JIRA)

XAManagedConnection should implement LocalTransaction to clean up hanging LocalTransaction ------------------------------------------------------------------------------------------ Key: JBAS-3860 URL: http://jira.jboss.com/jira/browse/JBAS-3860 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Reporter: Weston Price Assigned To: Weston Price Fix For: JBossAS-4.2.0.CR1 Currently, XAManagedConnection does not implement the LocalTransaction interface. As a result the following conditions produces an error: @TransactionDemarcation(NotSupported) public void doSomething() { DataSource ds = ... (XADataSource) Connection c = ds.getConnection(); c.setAutoCommit(false); // NOT Managed transaction // do stuff throw EJBException("Container/JCA should rollback uncommitted transaction!"); } Because of the c.setAutoCommit(false), a LocalTransaction is started. When the EJBException is thrown, the transaction is left hanging. Typically this is handled in the TxConnectionEventListener for LocalManagedConnection. However, in the case of XAManagedConnection the get mc.getLocalTransaction() throws a ResourceException and the transaction is never rolled back. -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-706) Failover mop-up

by Ovidiu Feodorov (JIRA)

Failover mop-up --------------- Key: JBMESSAGING-706 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-706 Project: JBoss Messaging Issue Type: Task Components: JMS Clustering Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Beta2 A container for all failover mop up tasks that still have to be completed -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-888) Remove TreeCache.UNITIALIZED, add NodeSPI.get/setDataLoaded()

by Elias Ross (JIRA)

Remove TreeCache.UNITIALIZED, add NodeSPI.get/setDataLoaded() ------------------------------------------------------------- Key: JBCACHE-888 URL: http://jira.jboss.com/jira/browse/JBCACHE-888 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2 Reporter: Elias Ross Assigned To: Manik Surtani For 2.0, I believe the intent is to stop having code explicitly reference TreeCache. One thing that strikes me as extremely clumsy is the TreeCache.UNITIALIZED flag that is set in the data map itself. I believe that adding the flag to the node can accomplish the same thing. It might make sense to look at this http://java.sun.com/j2se/1.5.0/docs/api/java/util/EnumSet.html for setting flags, etc. -- 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, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-889) EvictionPolicy methods for 2.0, consider revising

by Elias Ross (JIRA)

EvictionPolicy methods for 2.0, consider revising ------------------------------------------------- Key: JBCACHE-889 URL: http://jira.jboss.com/jira/browse/JBCACHE-889 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2 Reporter: Elias Ross Assigned To: Manik Surtani I noticed that nobody seems to use EvictionPolicy methods such as getChildrenNames(), hasChild(), getCacheData(), etc. It might make sense to simply remove these methods and add a EvictionPolicy { Cache getCache(); } . Change EvictionPolicy.configure() to EvictionPolicy.setCache() to match. -- 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, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-867) Refactor use of TreeCacheProxyImpl

by Elias Ross (JIRA)

Refactor use of TreeCacheProxyImpl ---------------------------------- Key: JBCACHE-867 URL: http://jira.jboss.com/jira/browse/JBCACHE-867 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Elias Ross Assigned To: Manik Surtani Move methods from TreeCacheProxyImpl to the NodeImpl itself. Consider also removing this class and having TreeCache implement Cache. -- 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, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3870) Clone the JBossMX javax.management.timer.Timer implementation, to a jboss package

by Dimitris Andreadis (JIRA)

Clone the JBossMX javax.management.timer.Timer implementation, to a jboss package --------------------------------------------------------------------------------- Key: JBAS-3870 URL: http://jira.jboss.com/jira/browse/JBAS-3870 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JMX Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.0.CR1 There are indications that the jdk5 implementation of javax.management.timer.Timer uses internally a single-threaded implementation for executing scheduled tasks, so scheduling of multiple tasks is affected when moving from jdk1.4 and the jboss implementation of Timer, to a jdk5 runtime. The JBossMX Timer implementation in contrast uses a dynamically extensible thread pool to execute scheduled tasks. Since we don't control the jdk5 implementation, a simple solution is to clone the jboss timer into a new package, e.g. org.jboss.javax.management.timer.Timer, for those that want to stick with the jboss implementation. -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3615) failing test in org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase

by Dimitris Andreadis (JIRA)

failing test in org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase ------------------------------------------------------------------------------ Key: JBAS-3615 URL: http://jira.jboss.com/jira/browse/JBAS-3615 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JMX, Test Suite Environment: Java Version 1.5.0_05 Java Vendor Sun Microsystems Inc. Java VM Name Java HotSpot(TM) Server VM Java VM Version 1.5.0_05-b05 Java VM Info mixed mode OS Name Linux OS Version 2.6.9-34.0.2.ELsmp OS Arch i386 Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-4.0.5.GA testMalformed Failure invalid object name: domain:=,foo=bar junit.framework.AssertionFailedError: invalid object name: domain:=,foo=bar at org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase$FullNameTEST.testMalformed(MalformedTestCase.java:152) -- 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, 6 months

2
16
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 December 2006