December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBESB-258) Prune jars from lib and the examples

by Mark Little (JIRA)

Prune jars from lib and the examples ------------------------------------ Key: JBESB-258 URL: http://jira.jboss.com/jira/browse/JBESB-258 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: ESB Core Affects Versions: 4.0 RC1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.0 The distribution is very large owing to the jars we ship. -- 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

17 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-250) Listeners fail after a lengthy period of being active.

by Mark Little (JIRA)

Listeners fail after a lengthy period of being active. ------------------------------------------------------ Key: JBESB-250 URL: http://jira.jboss.com/jira/browse/JBESB-250 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: ESB Core Reporter: Mark Little Assigned To: Kevin Conner Fix For: 4.0 >From Burr: "It is really simple, when a service is auto-reloaded via its parameterReloadSecs="10" attribute in the esb-config.xml it sometimes fails to properly go through the self-registration process with the registry. Unfortunately it is not consistent. We'll just need to leave a few listeners running some place to see how they behave over time." >From Kurt: "I see this in the logs when it reloads the config (sometimes): [JmsQueueListener] Unregistering this EPR done: creditagency [java] 14:36:10,880 DEBUG [SocketManager] End ReadTask.run [java] 14:36:10,880 DEBUG [UILClientILService] Stopping [java] 14:36:10,880 DEBUG [SocketManager] End WriteTask.run [java] 14:36:10,927 INFO [JmsQueueListener] Unregistering this EPR done: creditagency [java] 14:36:10,942 DEBUG [SocketManager] End ReadTask.run [java] 14:36:10,942 DEBUG [UILClientILService] Stopping [java] 14:36:10,942 DEBUG [SocketManager] End WriteTask.run [java] 14:36:19,348 INFO [JmsQueueListener] Unregistering this EPR, we're going to reload: creditagency so it goes to unregister twice.. the second time we get a stacktrace, since it's already gone. Do we have more then 1 JmsQueueListener thread??" -- 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

17 years, 11 months

2
2
0 / 0

[JBoss JIRA] Assigned: (JBCACHE-533) Change synchronization to use locks in Passivation/Activation interceptor

by Hany Mesha (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-533?page=all ] Hany Mesha reassigned JBCACHE-533: ---------------------------------- Assignee: Hany Mesha (was: Manik Surtani) > Change synchronization to use locks in Passivation/Activation interceptor > ------------------------------------------------------------------------- > > Key: JBCACHE-533 > URL: http://jira.jboss.com/jira/browse/JBCACHE-533 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Elias Ross > Assigned To: Hany Mesha > Fix For: 2.0.0.GA > > > Re synchronization in PassivationInterceptor and ActivationInterceptor > The synchronization statement is needed to prevent multiple threads from trying to passivate or activate the node at the same time. However, we can switch to use BaseCacheLoaderInterceptor.obtainLoaderLock() to obtain locks. The same strategy used in CacheStoreInterceptor and CacheLoaderInterceptor. Please open a JIRA Issue for it and it'll be done. -- 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-861) JDBC tests failing on the packaged distribution

by Rajesh Rajasekaran (JIRA)

JDBC tests failing on the packaged distribution ----------------------------------------------- Key: JBCACHE-861 URL: http://jira.jboss.com/jira/browse/JBCACHE-861 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA1 Reporter: Rajesh Rajasekaran Assigned To: Manik Surtani Fix For: 2.0.0.ALPHA1 The following tests which involve Derby database are failing on the packaged distribution. Build JBossCache-all-2.0.0.ALPHA1.zip Unzip and run the following tests. 1.) org.jboss.cache.loader.JDBCCacheLoaderDerbyDSTest java:/DerbyDS not bound junit.framework.AssertionFailedError: java:/DerbyDS not bound at org.jboss.cache.loader.JDBCCacheLoaderDerbyDSTest.configureCache(JDBCCacheLoaderDerbyDSTest.java:49) at org.jboss.cache.loader.CacheLoaderTestsBase.setUp(CacheLoaderTestsBase.java:72) 2.) org.jboss.cache.loader.JDBCCacheLoaderTest org.jboss.cache.passivation.PassivationToJDBCCacheLoaderTest org.jboss.cache.statetransfer.StateTransfer200Test Failed to load driver null: null java.lang.IllegalStateException: Failed to load driver null: null at org.jboss.cache.loader.JDBCCacheLoader.loadDriver(JDBCCacheLoader.java:945) at org.jboss.cache.loader.JDBCCacheLoader.start(JDBCCacheLoader.java:479) at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:328) at org.jboss.cache.TreeCache.start(TreeCache.java:750) at org.jboss.cache.loader.CacheLoaderTestsBase.setUp(CacheLoaderTestsBase.java:73) -- 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

17 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (JBESB-234) Remove dead code

by Mark Little (JIRA)

Remove dead code ---------------- Key: JBESB-234 URL: http://jira.jboss.com/jira/browse/JBESB-234 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ESB Core Reporter: Mark Little Assigned To: Tom Fennelly Fix For: 4.0 -- 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

17 years, 11 months

2
8
0 / 0

El Viejito Pascuero está de viaje?

by Carrier 179

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-895) ClassCastException in GlobalTransaction#equals()

by Stas Chizhov (JIRA)

ClassCastException in GlobalTransaction#equals() ------------------------------------------------ Key: JBCACHE-895 URL: http://jira.jboss.com/jira/browse/JBCACHE-895 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA1 Reporter: Stas Chizhov Assigned To: Manik Surtani Looks like GobalTransaction semantics allows addr property to be null. GlobalTransaction#compareTO(other) method (used by equals()) handles this.adrr == null situation, but does not check for other.adrr == null. Here is corresponding line from from GlobalTransaction#compareTO() comp=addr != null ? addr.compareTo(other.addr) : 0; Nearly any Adress#comapreTO() implementation treats null as illegal argument. IpAdress#compareTO() for instance throws ClassCastException in this case. So if globalTransaction1.addr!= null & globalTransaction2.addr==null globaltransaction1.equals(globalTransaction2) will fail with ClassCastException, but globaltransaction2.equals(globalTransaction1) will not. We observe this issue running JBoss 4.0.2 with default JBossCache and JGroups under following conditions: 1) Have 2 JBoss nodes being put under moderate transaction rate 2) have 1 node paused inside a transaction (either manually via debugger or long GC pause) for a time greater then JGroups FD timeout. After cluster node rejoin we observe this issue in logs: Caused by: java.lang.ClassCastException: IpAddress.compareTo(): comparison between different classes at org.jgroups.stack.IpAddress.compareTo(IpAddress.java:134) at org.jboss.cache.GlobalTransaction.compareTo (GlobalTransaction.java:72) at org.jboss.cache.GlobalTransaction.equals(GlobalTransaction.java:63 -- 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

17 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-260) QA run against the distribution

by Mark Little (JIRA)

QA run against the distribution ------------------------------- Key: JBESB-260 URL: http://jira.jboss.com/jira/browse/JBESB-260 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Testing Affects Versions: 4.0 RC1 Reporter: Mark Little Assigned To: Kevin Conner Fix For: 5.0 Can we make the QA run against a distribution? -- 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

17 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-875) Pessimistic lock interceptor does not write-lock parent nodes when creating or deleting children

by Manik Surtani (JIRA)

Pessimistic lock interceptor does not write-lock parent nodes when creating or deleting children ------------------------------------------------------------------------------------------------ Key: JBCACHE-875 URL: http://jira.jboss.com/jira/browse/JBCACHE-875 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1, 1.4.0.GA, 1.3.0.SP3 Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Critical Fix For: 1.4.1.GA, 2.0.0.GA -- 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

17 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-871) Calling remove(FQN) inside a transaction destroys the node before the commit phase

by Galder Zamarreno (JIRA)

Calling remove(FQN) inside a transaction destroys the node before the commit phase ---------------------------------------------------------------------------------- Key: JBCACHE-871 URL: http://jira.jboss.com/jira/browse/JBCACHE-871 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1, 1.3.0.SP3 Reporter: Galder Zamarreno Assigned To: Manik Surtani Attachments: Siemens00012761Test.java Removing a node that has been just been put inside a transaction (Pessimistic Locking, READ_COMMITTED) destroys the node without leaving any trace. Remove should not actually destroy until the commit has been executed. This allows for any paralell transactions to get a WL on this node as there's no any locks any more in this node (it was destroyed) -- 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

17 years, 11 months

3
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006