January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1152) Lock acquisition and replication timeouts should use different Exception classes

by Manik Surtani (JIRA)

Lock acquisition and replication timeouts should use different Exception classes -------------------------------------------------------------------------------- Key: JBCACHE-1152 URL: http://jira.jboss.com/jira/browse/JBCACHE-1152 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA At the moment they both throw o.j.c.lock.TimeoutException which can be misleading -- 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

16 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1166) UpgradeException on concurent put/remove operation

by Jacek Halat (JIRA)

UpgradeException on concurent put/remove operation -------------------------------------------------- Key: JBCACHE-1166 URL: http://jira.jboss.com/jira/browse/JBCACHE-1166 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Environment: Windows XP, Sun jdk150_06 Reporter: Jacek Halat Assigned To: Manik Surtani Attachments: ConcurentOperationTest.java When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock Full StackTrace: org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158) at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143) at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136) at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101) at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93) at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80) Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1) at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508) at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579) at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393) at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76) at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62) at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939) at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598) at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273) at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170) at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153) ... 5 more Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)) at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209) at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167) at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497) ... 25 more Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107) at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43) at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203) ... 27 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

16 years, 11 months

3
14
0 / 0

[JBoss JIRA] Created: (JBFORUMS-259) Actions in admin panel no longer work

by Ryszard Kozmik (JIRA)

Actions in admin panel no longer work ------------------------------------- Key: JBFORUMS-259 URL: http://jira.jboss.com/jira/browse/JBFORUMS-259 Project: JBoss Forums Issue Type: Bug Components: Forum View Layer Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Fix For: 1.0.1 RC, 1.1.0 Alpha Something caused that all actions in admin panel don't work. Additionally, some of jsf actions should be moved to jsf events to make the code look and work better. -- 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

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-62) Slicing Replication

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-62?page=all ] Manik Surtani resolved JBCACHE-62. ---------------------------------- Fix Version/s: (was: 2.1.0.GA) Resolution: Done > Slicing Replication > ------------------- > > Key: JBCACHE-62 > URL: http://jira.jboss.com/jira/browse/JBCACHE-62 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Original Estimate: 10 weeks > Remaining Estimate: 10 weeks > > - Replicate parts of JBossCache to different cluster nodes -- 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

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-62) Slicing Replication

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-62?page=all ] Manik Surtani reopened JBCACHE-62: ---------------------------------- Assignee: Manik Surtani (was: Bela Ban) > Slicing Replication > ------------------- > > Key: JBCACHE-62 > URL: http://jira.jboss.com/jira/browse/JBCACHE-62 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Original Estimate: 10 weeks > Remaining Estimate: 10 weeks > > - Replicate parts of JBossCache to different cluster nodes -- 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

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4148) Replace Gjt code used in the ejb 2.x validation phase

by Fernando Nasser (JIRA)

Replace Gjt code used in the ejb 2.x validation phase ----------------------------------------------------- Key: JBAS-4148 URL: http://jira.jboss.com/jira/browse/JBAS-4148 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Fernando Nasser Fix For: JBossAS-4.2.1.CR1 The JBossAS thirdpart-build.xml grabs a <componentref name="gjt-jpl-util" version="1.0"/> from repository.jboss.com However, the Gjt project has never released a 1.0 version, only a 0.6 version for the Linffors utils and the jpl_util_0_6 is the only tag in their CVS. So, what is the meaning for version 1.0? The CVS tip? Also, what is marked as gjt-jpl-util also contains gjt-jpl-pattern, and the latest CVS tag for that is: jpl-pattern_0_3_b (0.3 beta perhaps) Besides, there is a warning in the pattern source directory: "Untagged files may be (and probably are) in an unstable state and might not compile. If you want something that works, checkout with tags. You have been warned. :) -- Juha" Here, for the record, is Scott's opinion: Scott M Stark wrote: > This is some ancient code used only in the ejb 2.x validation phase. It > has not been touched in something like 5 years. Either we need to > replace it or pull together some code that makes up a usable release. -- 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

16 years, 11 months

4
20
0 / 0

[JBoss JIRA] Created: (JBRULES-1375) remove backdated concurrency classes, now that we are jdk1.5+

by Mark Proctor (JIRA)

remove backdated concurrency classes, now that we are jdk1.5+ ------------------------------------------------------------- Key: JBRULES-1375 URL: http://jira.jboss.com/jira/browse/JBRULES-1375 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Reteoo Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 4.0.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

16 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1420) Drools Release 4.0.4

by Fernando Meyer (JIRA)

Drools Release 4.0.4 -------------------- Key: JBRULES-1420 URL: http://jira.jboss.com/jira/browse/JBRULES-1420 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Reporter: Fernando Meyer Assigned To: Fernando Meyer -- 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

16 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1416) The use of HashKey is not thread safe in CompositeObjectSinkAdapter

by Mark Proctor (JIRA)

The use of HashKey is not thread safe in CompositeObjectSinkAdapter ------------------------------------------------------------------- Key: JBRULES-1416 URL: http://jira.jboss.com/jira/browse/JBRULES-1416 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3, 4.0.2, 4.0.1, 4.0.0.GA Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 4.0.4, 4.1.0 Noticed that actually the little optimisation in CompositeObjectSinkAdapter to use a hashKey field instance is not thread safe. So need to change it to always just create a local instance and use that. -- 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

16 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1261) Redundant SQL queries on JDBCCacheLoader

by gmeroz (JIRA)

Redundant SQL queries on JDBCCacheLoader ---------------------------------------- Key: JBCACHE-1261 URL: http://jira.jboss.com/jira/browse/JBCACHE-1261 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.0.0.GA Environment: Oracle DB Reporter: gmeroz Assigned To: Manik Surtani Priority: Critical When JDBCCacheLoader is used (with Oracle), the performance is bad due to the many SQL statement run to the DB. many of the SQLs are redundant since they run with the same paramters several times. The problem exist both when inserting/loading to/from DB. The performance can be improved by more than 50% if all redudant SQLs are removed. You can see the problem when running the following code after setting the log to "debug" on org.jboss.cache.loader. // insert only 2 nodes to the cache for (int i=0 ; i<2 ; i++){ cache.put("cat","x"+i,"some_data"); } output (52 queries!!! ): 1 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/) 2 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) 3 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) // same as 2 4 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) // same as 2 5 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) // same as 2 6 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) // same as 2 7 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) // same as 2 8 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) // same as 2 9 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) // same as 2 10 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x0/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxay-2) 11 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/__JBossInternal__/cat/x0/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxay-2) 12 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x0/_ID_) 13 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/__JBossInternal__/cat/x0/_ID_) 14 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x0) 15 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/__JBossInternal__/cat/x0)16 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat) 16 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/__JBossInternal__/cat) 17 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__) 18 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/__JBossInternal__) 19 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/) 20 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/) 21 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x0/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxay-2) 22 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x0/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxay-2) 23 executing sql: update ALLERGAN04.jbosscache_test set node=? where fqn=? 24 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) // same as 2 25 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0) // same as 2 26 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/cat/x0) 27 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat) 28 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/cat) 29 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/) 30 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 31 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 32 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 33 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 34 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 35 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 36 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 37 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 38 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x1/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxh1-3) 39 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/__JBossInternal__/cat/x1/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxh1-3) 40 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x1/_ID_) 41 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/__JBossInternal__/cat/x1/_ID_) 42 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x1) 43 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/__JBossInternal__/cat/x1) 44 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat) 45 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x1/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxh1-3) 46 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x1/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxh1-3) 47 executing sql: update ALLERGAN04.jbosscache_test set node=? where fqn=? 48 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 49 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1) 51 executing sql: insert into ALLERGAN04.jbosscache_test (fqn, node, parent) values (?, ?, ?) (/cat/x1) 52 executing sql: select node from ALLERGAN04.jbosscache_test where fqn=? (/cat) Redundant: 3 x "select node from ALLERGAN04.jbosscache_test where fqn=? (/)" 10 x "select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x0)" 3 x "select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x0/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxay-2)" 2 x "select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat)" 2 x "select node from ALLERGAN04.jbosscache_test where fqn=? (/cat)" 10 x "select node from ALLERGAN04.jbosscache_test where fqn=? (/cat/x1)" 3 x "select node from ALLERGAN04.jbosscache_test where fqn=? (/__JBossInternal__/cat/x1/_ID_/5c4oa2y-nzxzy2-fb7uoxai-1-fb7uoxh1-3)" in total 27 redudant queries.... -- 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

16 years, 11 months

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008