September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-785) InvocationContext and suspended transactions

by Owen Taylor (JIRA)

InvocationContext and suspended transactions -------------------------------------------- Key: JBCACHE-785 URL: http://jira.jboss.com/jira/browse/JBCACHE-785 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1 Reporter: Owen Taylor Assigned To: Manik Surtani The attached test case demonstrates that if you: A) Make calls to the tree cache B) suspend the current transaction C) Make more calls to the tree cache The locks created at step C) are sometimes attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed. It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.) -- 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, 7 months

2
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-761) Make connecting the channel and state transfer an atomic part of startup

by Brian Stansberry (JIRA)

Make connecting the channel and state transfer an atomic part of startup ------------------------------------------------------------------------ Key: JBCACHE-761 URL: http://jira.jboss.com/jira/browse/JBCACHE-761 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Manik Surtani If an exception is thrown during initial state transfer, the channel should be disconnected. The exception will propagate out of startService(), which in the AS will leave the cache service in an incompletely deployed state. But the current code leaves the channel connected, leaving a "zombie" member of the group. Probably need to alter stopService() as well to ensure it can handle an already disconnected channel. -- 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, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-717) cascade persistence operations from timer to action

by Alejandro Guizar (JIRA)

cascade persistence operations from timer to action --------------------------------------------------- Key: JBPM-717 URL: http://jira.jboss.com/jira/browse/JBPM-717 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Reporter: Alejandro Guizar Assigned To: Tom Baeyens Fix For: jBPM 3.1.3 when creating timers from user code, the action object is not saved with the timer. -- 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, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-724) Add more non-String objects to testsuite Fqns

by Brian Stansberry (JIRA)

Add more non-String objects to testsuite Fqns --------------------------------------------- Key: JBCACHE-724 URL: http://jira.jboss.com/jira/browse/JBCACHE-724 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Priority: Minor Almost all of the fqn's used in the testsuite are composed solely of String elements. We should look for and identify places to include non-String elements in order to help prevent issues like JBCACHE-703. -- 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, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-745) nodeEvicted being called for nodes that don't actuall get evicted

by gregorypierce (JIRA)

nodeEvicted being called for nodes that don't actuall get evicted ----------------------------------------------------------------- Key: JBCACHE-745 URL: http://jira.jboss.com/jira/browse/JBCACHE-745 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1 Reporter: gregorypierce Assigned To: Manik Surtani Attachments: CacheEviction.java Working on class example from training materials CacheEviction.java. Will receive a nodeEvicted call that the root node has been evicted, but if you look at the console itself and print the tree - the root node doesn't get evicted. Should not call nodeEvicted with a node that hasn't actually already been evicted from the tree. Looks like it realizes that the node is a parent node and decides against evicting it after the interface call. // FIXME We extend AbstractTreeCacheListener, which provides a default implementation // of the TreeCacheListener interface. You just need to override methods to write to // the console for cache events in which you are interested. Do something like this: public void nodeCreated(Fqn fqn) { System.out.println("nodeCreated(): fqn: " +fqn); } public void nodeEvicted(Fqn fqn) { System.out.println("nodeEvicted(): fqn: " +fqn); } -- 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, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPM-741) JbpmSchedulerThread does not terminate the scheduler/command threads properly

by Alejandro Guizar (JIRA)

JbpmSchedulerThread does not terminate the scheduler/command threads properly ----------------------------------------------------------------------------- Key: JBPM-741 URL: http://jira.jboss.com/jira/browse/JBPM-741 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.1 Reporter: Alejandro Guizar Fix For: jBPM 3.1.3 The implementation of SchedulerThread and CommandExecutorThread in 3.1.1 does not provide a mechanism to exit the run() method, allowing the Thread to exit properly and release any resources it is holding. This becomes an issue for perm gen in JBoss AS and other containers. For SchedulerThread, keepRunning (bool) should be public or provide mutators, so whatever launches the Thread can modify it. For CommandExecutorThread, the while(true) in run() should be changed to something like SchedulerThread uses and, of course, provide mutators to the loop control variable. -- 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, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-756) Marshaller breaks with Strings of length greater than 32767

by Manik Surtani (JIRA)

Marshaller breaks with Strings of length greater than 32767 ----------------------------------------------------------- Key: JBCACHE-756 URL: http://jira.jboss.com/jira/browse/JBCACHE-756 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Replication Affects Versions: 1.4.0.SP1, 1.4.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 1.4.0.SP2, 2.0.0 See unit tests added. -- 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, 7 months

1
5
0 / 0

[JBoss JIRA] Created: (JBPM-696) Field Instanciator problems

by Shai Bentin (JIRA)

Field Instanciator problems --------------------------- Key: JBPM-696 URL: http://jira.jboss.com/jira/browse/JBPM-696 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.1 Environment: WinXP, Linux running on JBoss Application Server 4.0.3SP1, JDK1.5.0_06 Reporter: Shai Bentin Assigned To: Tom Baeyens Priority: Minor Fix For: jBPM 3.1.2 The method getValue() is see two problems, one is jdk5 related the other is just an idea. In jdk5 doing if (type.isAssignableFrom(Set.class)) and such yields a 'false' even when it is supposed to be true... if we would write the same if in reverse: Set.class.isAssignableFrom(type) we will ge the desired reuslt. The other issue is, if we know the super type why do we impose a specific implementation, i.e. if we have a Collection, why do we impose an ArrayList. We have the user's type and we know it is of type collection so why don't we instanciate the requested type.... Here is how I propose to write this method: public static Object getValue(Class type, Element propertyElement) { // parse the value Object value = null; try { if ( type == String.class ) { value = propertyElement.getText(); } else if ( (type==Integer.class) || (type==int.class) ) { value = new Integer( propertyElement.getTextTrim() ); } else if ( (type==Long.class) || (type==long.class) ) { value = new Long( propertyElement.getTextTrim() ); } else if ( (type==Float.class ) || (type==float.class) ) { value = new Float( propertyElement.getTextTrim() ); } else if ( (type==Double.class ) || (type==double.class) ) { value = new Double( propertyElement.getTextTrim() ); } else if ( (type==Boolean.class ) || (type==boolean.class) ) { value = Boolean.valueOf( propertyElement.getTextTrim() ); } else if ( (type==Character.class ) || (type==char.class) ) { value = new Character( propertyElement.getTextTrim().charAt(0) ); } else if ( (type==Short.class ) || (type==short.class) ) { value = new Short( propertyElement.getTextTrim() ); } else if ( (type==Byte.class ) || (type==byte.class) ) { value = new Byte( propertyElement.getTextTrim() ); } else if (List.class.isAssignableFrom(type)) { value = getCollection(propertyElement, (List)type.newInstance()); } else if (Set.class.isAssignableFrom(type)) { value = getCollection(propertyElement, (Set)type.newInstance()); } else if (Collection.class.isAssignableFrom(type)) { value = getCollection(propertyElement, (Collection)type.newInstance()); } else if (Map.class.isAssignableFrom(type)) { value = getMap(propertyElement, (Map)type.newInstance()); } else if ( type==Element.class ) { value = propertyElement; } else { Constructor constructor = type.getConstructor(new Class[]{String.class}); if ( (propertyElement.isTextOnly()) && (constructor!=null) ) { value = constructor.newInstance(new Object[]{propertyElement.getTextTrim()}); } } } catch (Exception e) { log.error("couldn't parse the bean property value '" + propertyElement.asXML() + "' to a '" + type.getName() + "'" ); throw new JbpmException( e ); } return value; } -- 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, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-758) DbPersistenceService needs update for new Hibernate version

by Thomas Klute (JIRA)

DbPersistenceService needs update for new Hibernate version ----------------------------------------------------------- Key: JBPM-758 URL: http://jira.jboss.com/jira/browse/JBPM-758 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.2 Environment: jboss AS 4.0.4, hibernate 3.1 or hibernate 3.2 Reporter: Thomas Klute Assigned To: Tom Baeyens Fix For: jBPM 3.1.3 Release of JDBC connections changed with hibernate version > 3.0. DbPersistenceService now throws exception when trying to close a hibernate session (because in was closed automatically when the transaction committed). The exception happens every few seconds when using the jbpm scheduler-service. See below for stack trace. See http://www.hibernate.org/250.html#A31 for a detailed description of hibernate-changes regarding JDBC connections. FYI: The exception does not roll back the transaction, because it has already been committed. Please adapt the code to the new hibernate behaviour. Maybe just comment out the "throw" of the exception. I have no idea what code would work with old _and_ new hibernate versions. We just got the problem integrating jbpm into a jboss AS 4.0.4 using hibernate 3.2. ... 2006-09-28 16:11:53,996 DEBUG [org.jbpm.persistence.db.DbPersistenceService] creating hibernate session 2006-09-28 16:11:53,998 DEBUG [org.hibernate.jdbc.JDBCContext] TransactionFactory reported no active transaction; Synchronization not registered 2006-09-28 16:11:53,998 DEBUG [org.hibernate.impl.SessionImpl] opened session at timestamp: 4749118316527616 2006-09-28 16:11:53,998 DEBUG [org.jbpm.persistence.db.DbPersistenceService] beginning hibernate transaction 2006-09-28 16:11:53,998 DEBUG [org.hibernate.transaction.JTATransaction] Looking for UserTransaction under: UserTransaction 2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] Obtained UserTransaction 2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] begin 2006-09-28 16:11:54,000 DEBUG [org.hibernate.transaction.JTATransaction] Began a new JTA transaction 2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.JDBCContext] successfully registered Synchronization 2006-09-28 16:11:54,000 DEBUG [org.jbpm.scheduler.impl.SchedulerThread] checking for timers 2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0) 2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.ConnectionManager] opening JDBC connection 2006-09-28 16:11:54,000 DEBUG [org.hibernate.SQL] select timer0_.ID_ as col_0_0_ from JBPM_TIMER timer0_ where (timer0_.EXCEPTION_ is null) and timer0_.ISSUSPENDED_<>1 order by timer0_.DUEDATE_ asc 2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open ResultSet (open ResultSets: 0, globally: 0) 2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] exhausted results 2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] closing iterator 2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close ResultSet (open ResultSets: 1, globally: 1) 2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1) 2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] aggressively releasing JDBC connection 2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)] 2006-09-28 16:11:54,001 DEBUG [org.jbpm.JbpmContext] closing JbpmContext 2006-09-28 16:11:54,002 DEBUG [org.jbpm.svc.Services] closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService@15a9173 2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] committing hibernate transaction 2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] commit 2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] Committed JTA UserTransaction 2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] closing hibernate session 2006-09-28 16:11:54,002 ERROR [STDERR] org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session 2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191) 2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.svc.Services.close(Services.java:211) 2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.JbpmContext.close(JbpmContext.java:139) 2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161) 2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70) 2006-09-28 16:11:54,003 ERROR [STDERR] Caused by: org.hibernate.SessionException: Session was already closed 2006-09-28 16:11:54,003 ERROR [STDERR] at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277) 2006-09-28 16:11:54,003 ERROR [STDERR] at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189) 2006-09-28 16:11:54,003 ERROR [STDERR] ... 4 more 2006-09-28 16:11:54,003 ERROR [org.jbpm.svc.Services] problem closing service 'persistence' org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191) at org.jbpm.svc.Services.close(Services.java:211) at org.jbpm.JbpmContext.close(JbpmContext.java:139) at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161) at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70) Caused by: org.hibernate.SessionException: Session was already closed at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277) at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189) ... 4 more 2006-09-28 16:11:54,003 INFO [org.jbpm.scheduler.impl.SchedulerThread] runtime exception while executing timers org.jbpm.JbpmException: problem closing services {persistence=org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session} at org.jbpm.svc.Services.close(Services.java:223) at org.jbpm.JbpmContext.close(JbpmContext.java:139) at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161) at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70) Caused by: org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191) at org.jbpm.svc.Services.close(Services.java:211) ... 3 more Caused by: org.hibernate.SessionException: Session was already closed at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277) at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189) ... 4 more -- 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, 7 months

3
2
0 / 0

[JBoss JIRA] Created: (JBSEAM-310) Global setting for no-conversation-view-id

by Gavin King (JIRA)

Global setting for no-conversation-view-id ------------------------------------------ Key: JBSEAM-310 URL: http://jira.jboss.com/jira/browse/JBSEAM-310 Project: JBoss Seam Issue Type: Feature Request Components: JSF Reporter: Gavin King Assigned To: Gavin King Fix For: 1.1 Currently, no-conversation-view-id is too fine grained. We should allow a global setting to be used as the default if none is defined in pages.xml or the pageflow. Note that another issue asks for no-conversation-view-id at pageflow level instead of node level. This is also useful. -- 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, 7 months

1
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 September 2006