October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1189) Implement JGroups Connect + State Transfer in JBC

by Manik Surtani (JIRA)

Implement JGroups Connect + State Transfer in JBC ------------------------------------------------- Key: JBCACHE-1189 URL: http://jira.jboss.com/jira/browse/JBCACHE-1189 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Vladimir Blagojevic Fix For: 2.1.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

18 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1142) Update JBoss Cache source code infrastructure

by Manik Surtani (JIRA)

Update JBoss Cache source code infrastructure --------------------------------------------- Key: JBCACHE-1142 URL: http://jira.jboss.com/jira/browse/JBCACHE-1142 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Critical Fix For: 2.1.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

18 years, 7 months

1
2
0 / 0

[JBoss JIRA] Updated: (JBCACHE-407) Write locks not acquired on newly created empty nodes

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-407?page=all ] Manik Surtani updated JBCACHE-407: ---------------------------------- Fix Version/s: 2.1.0.BETA1 > Write locks not acquired on newly created empty nodes > ----------------------------------------------------- > > Key: JBCACHE-407 > URL: http://jira.jboss.com/jira/browse/JBCACHE-407 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.4.1.GA, 1.4.0.GA, 1.3.0.GA, 2.0.0.GA > Reporter: Brian Stansberry > Assigned To: Manik Surtani > Fix For: 2.1.0.GA, 2.1.0.BETA1 > > > When an empty node is created during a put (e.g node "/a" created as a result of a cache.put("/a/1", "key", "value"); call), only a read lock is acquired on the empty node. If the node is created as part of a transaction, the following failure can occur: > 2 threads, empty cache, READ_COMMITTED > 1) T1 starts a tx > 2) T1 invokes cache.put("/a/1", "key", "value1"); > 3) T2 invokes cache.put("/a/2", "key", "value2"); > 4) T1's transaction rolls back > 5) T2 invokes cache.get("/a/2", "key"); Should get "value2", will get null because the tx rollback will remove node /a and thus /a/2 as well. > This IMO breaks READ_COMMITTED semantics, as T2 is able to "read" /a (in the sense of seeing it exists and thus can have children appended to it) before the tx that created /a is committed. > New unit test IsolationLevelReadCommittedTest.testNodeCreationRollback() demonstrates the issue. -- 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

18 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1179) Blocking access to cache based on CacheStatus broken around channel connect/disconnect

by Brian Stansberry (JIRA)

Blocking access to cache based on CacheStatus broken around channel connect/disconnect -------------------------------------------------------------------------------------- Key: JBCACHE-1179 URL: http://jira.jboss.com/jira/browse/JBCACHE-1179 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Manik Surtani Priority: Critical Fix For: 2.1.0.GA CacheImpl.invokeMethod will throw an ISE if CacheStatus != STARTED. Problem is the channel is connected during CacheStatus.STARTING and CacheStatus.STOPPING. As long as the channel is connected you get exceptions during replication for as shown in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118013. -- 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

18 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1181) CacheJmxWrappers exposes details as JMX attributes, not operations

by Brian Stansberry (JIRA)

CacheJmxWrappers exposes details as JMX attributes, not operations ------------------------------------------------------------------ Key: JBCACHE-1181 URL: http://jira.jboss.com/jira/browse/JBCACHE-1181 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry getConfigurationAsString(); getConfigurationAsHtmlString(); getCacheDetails(); getCacheDetailsAsHtml(); All are too verbose for exposure as MBean attributes in the JMX console. They need to be converted into operations so users will have to specifically invoke them. A better API would be: printConfigurationAsString(); printConfigurationAsHtmlString(); printCacheDetails(); printCacheDetailsAsHtml(); -- 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

18 years, 7 months

2
9
0 / 0

[JBoss JIRA] Created: (JBCACHE-1193) Tests should not call Transaction.commit/rollback()

by Jason T. Greene (JIRA)

Tests should not call Transaction.commit/rollback() --------------------------------------------------- Key: JBCACHE-1193 URL: http://jira.jboss.com/jira/browse/JBCACHE-1193 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Jason T. Greene Assigned To: Jason T. Greene Fix For: 2.1.0.GA The JTA spec says that the thread association of a transaction can only be controlled by TransactionManager. The reason is that a Transaction can be bound to multple threads. In order to be compliant, and work with JBoss JTA, we need to ensure that all operations go through TransactionManager -- 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

18 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1182) JMX wrappers log WARN messages on calling getter for deprecated attributes

by Brian Stansberry (JIRA)

JMX wrappers log WARN messages on calling getter for deprecated attributes -------------------------------------------------------------------------- Key: JBCACHE-1182 URL: http://jira.jboss.com/jira/browse/JBCACHE-1182 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.1.0.GA Logged after viewing a cache mbean in AS's jmx-console: 12:55:33,437 WARN [CacheJmxWrapper] MBean attribute 'CacheLoaderConfiguration' is deprecated; use 'CacheLoaderConfig' 12:55:34,046 WARN [CacheJmxWrapper] MBean attribute 'UseInterceptorMbeans' is d eprecated; use 'ExposeManagementStatistics' These should only be logged for the setter; the setter is what implies conscious usage of the outdated API. -- 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

18 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1175) Option.forceCall(A)sync

by Brian Stansberry (JIRA)

Option.forceCall(A)sync ----------------------- Key: JBCACHE-1175 URL: http://jira.jboss.com/jira/browse/JBCACHE-1175 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.1.0.GA Add an option to allow an individual call to go async/sync when the cache overall is configured for the opposite. This would only be relevant to calls not running in a tx; transactional replication would use the standard semantic configured for the cache. Use case for this is Hibernate timestamp region replication, which needs to go async, while all other Hibernate 2nd level cache traffic goes sync. A good region-based cache impl would solve the problem as well, but that will surely take quite a while to implement a while while doing it via an Option looks quite trivial. -- 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

18 years, 7 months

2
9
0 / 0

[JBoss JIRA] Created: (JBCACHE-1178) Option to set lock timeout

by Brian Stansberry (JIRA)

Option to set lock timeout -------------------------- Key: JBCACHE-1178 URL: http://jira.jboss.com/jira/browse/JBCACHE-1178 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Allow override of the standard lock timeout on a per-invocation basis. For background on the specific use case that needs this, see http://lists.jboss.org/pipermail/hibernate-dev/2007-September/002669.html -- 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

18 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1171) Make constructor Fqn(List<E> names, boolean safe) public

by Brian Stansberry (JIRA)

Make constructor Fqn(List<E> names, boolean safe) public -------------------------------------------------------- Key: JBCACHE-1171 URL: http://jira.jboss.com/jira/browse/JBCACHE-1171 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Manik Surtani Priority: Minor This constructor saves the cost of making a defensive copy of the passed in List. I've got some code that necessarily creates an ArrayList to pass to the Fqn c'tor, but there's no need to copy it; I hold no ref to the List. Being able to use this c'tor would be a minor optimization. I don't see any reason not to expose it as public; the javadoc for the constructor is clear about the proper usage. -- 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

18 years, 7 months

2
3
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 October 2007