December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4648) Upgrade jboss transactions to 4.4 (from 4.3)

by Dimitris Andreadis (JIRA)

Upgrade jboss transactions to 4.4 (from 4.3) -------------------------------------------- Key: JBAS-4648 URL: http://jira.jboss.com/jira/browse/JBAS-4648 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Dimitris Andreadis Fix For: JBossAS-5.0.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

16 years, 12 months

1
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1831) New user properties (locale) set by the user is not immediately used by the portal (improve existing solution)

by Thomas Heute (JIRA)

New user properties (locale) set by the user is not immediately used by the portal (improve existing solution) -------------------------------------------------------------------------------------------------------------- Key: JBPORTAL-1831 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1831 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.2 Final Reporter: Thomas Heute Assigned To: Thomas Heute Fix For: 2.6.3 Final Because of some user properties caching, when a user modifies his profile, the new data is not immediately accessible, only after a re-login -- 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, 12 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1840) Window name case sensitive

by Ovidiu Nichifor (JIRA)

Window name case sensitive -------------------------- Key: JBPORTAL-1840 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1840 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.1 Final Environment: Fedora Core 7 java version "1.5.0_12" JBoss [Zion] 4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339) (installed with jems-installer-1.2.0.GA - ejb3 profile) JBoss Portal 2.6.1.GA Reporter: Ovidiu Nichifor Assigned To: Julien Viet Customize your dashboard. 1. Create a window (e.g. WEATHER) and place it on a test page. 2. Create a window (e.g. WeAtHeR) and place it on a test page. The portal fails to create the second window: Caused by: org.hibernate.exception.ConstraintViolationException: could not insert: [org.jboss.portal.core.impl.model.portal.ObjectNode] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) ... Caused by: java.sql.SQLException: Duplicate entry 'dashboard:admin.Test.WeAtHeR' for key 2 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2975) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1600) This only happens if JBoss Portal uses mysql db descriptor (i.e. portal-mysql5-ds.xml). If using hypersonic it works without any errors. -- 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, 12 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-754) RPC return values to use a marshaller as well

by Manik Surtani (JIRA)

RPC return values to use a marshaller as well --------------------------------------------- Key: JBCACHE-754 URL: http://jira.jboss.com/jira/browse/JBCACHE-754 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.4.0, 2.0.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0 Currently, all RPC calls go through the VersionAwareMarshaller which is responsible for efficiently marshalling JBC internal objects as well as user objects using JBoss Serialization. Return values and exceptions, on the other hand, are marshalled/unmarshalled using JGroups' Util.{to|from}ByteBuffer() which uses standard object serialization. The problems here are twofold: 1) Relatively inefficient (in speed as well as byte array size) marshalling/unmarshalling for return values 2) Potential class loader problems Most RPC calls in JBoss Cache do not have return values so this is not a problem that comes up often, but certain features (clustered cache loader, data gravitation in buddy replication) rely on return values. The solution to this problem is to be able to register a marshaller with the JGroups RPCDispatcher for return values (and exceptions) as well as for the RPC calls themselves. -- 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, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-718) PojoCache TxLockInterceptor needs to release the lock node as well

by Ben Wang (JIRA)

PojoCache TxLockInterceptor needs to release the lock node as well ------------------------------------------------------------------ Key: JBCACHE-718 URL: http://jira.jboss.com/jira/browse/JBCACHE-718 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Priority: Minor Fix For: 2.0.0 Currently, in TxLockInterceptor, I achieve the node lock by applying explicitly a cache.put(). It has two drawbacks: 1) It explicit going to insert a value to that node 2) Needs to do a remove when it is done. Not much can be done re: 1 now, but we should do 2, alhtough it will degrade the performance further. -- 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, 12 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-932) Implicit lock ownership check in UnversionedNode

by Manik Surtani (JIRA)

Implicit lock ownership check in UnversionedNode ------------------------------------------------ Key: JBCACHE-932 URL: http://jira.jboss.com/jira/browse/JBCACHE-932 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.BETA2 This will involve read and write DIRECT methods on UnversionedNode to check whether the calling thread has acquired the necessary locks, else throw a lock exception. This will ensure proper concurrent access to the Node, even when not going through the interceptor stack. -- 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, 12 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-788) Optimistic locking should not REQUIRE transactions!

by Manik Surtani (JIRA)

Optimistic locking should not REQUIRE transactions! --------------------------------------------------- Key: JBCACHE-788 URL: http://jira.jboss.com/jira/browse/JBCACHE-788 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.4.0, 1.3.0, 2.0.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0 Makes things simpler. TXs are only used so transaction workspaces can be stored in a transaction entry. This workspace can just as easily be stored in ThreadLocal for non-tx calls (that just have the lifespan of a single invocation). This will: 1) Make things a LOT quicker since we don't need 2PC for all calls. 2) Make the TxInterceptor a lot simpler 3) Allow the use of Opt Locking without a TM -- 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, 12 months

2
3
0 / 0

[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, 12 months

1
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1129) Specify version dependencies in component-info.xml

by Brian Stansberry (JIRA)

Specify version dependencies in component-info.xml -------------------------------------------------- Key: JBCACHE-1129 URL: http://jira.jboss.com/jira/browse/JBCACHE-1129 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.0.0.GA Seems they are listed in pom.xml; need equivalent entries in component-info.xml. This adds fun, since we need to ensure consistency with the AS versions. -- 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, 12 months

2
6
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, 12 months

3
14
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007