January 2009 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1457) TcpCacheServer: Listening thread should attempt recovery

by J B (JIRA)

TcpCacheServer: Listening thread should attempt recovery -------------------------------------------------------- Key: JBCACHE-1457 URL: https://jira.jboss.org/jira/browse/JBCACHE-1457 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.2.0.GA Reporter: J B Assignee: Manik Surtani Priority: Minor If there is any exception thrown on the listening thread for new connections for the TcpCacheServer the thread will die with the effect that no new connections can be made to the CacheServer because the thread is dead. In order to begin listening again a complete restart is needed on the node using the TcpCacheServer which is not an ideal situation. Thread should at least attempt a recovery and not just die. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1459) FastCopyHashMaps misbehave when serialized and then deserialized

by Manik Surtani (JIRA)

FastCopyHashMaps misbehave when serialized and then deserialized ---------------------------------------------------------------- Key: JBCACHE-1459 URL: https://jira.jboss.org/jira/browse/JBCACHE-1459 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.0.1.GA, 3.0.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.2.GA This is the root cause of certain issues like data not appearing to be available when using a TcpDelegatingCacheLoader, since the TcpCacheServer uses FastCopyHashMaps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1460) Inefficient remove() in JDBCCacheLoader

by Krzysztof Sobolewski (JIRA)

Inefficient remove() in JDBCCacheLoader --------------------------------------- Key: JBCACHE-1460 URL: https://jira.jboss.org/jira/browse/JBCACHE-1460 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.0.2.CR1, 2.2.1.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani As I can see, after JBCACHE-1176 the remove() method in JDBCCacheLoader uses a single statement to remove a node and all its children, but this statement is hugely inefficient itself, at least with MySQL 5.0 (on which we detected this problem). Granted that half a million rows is probably uncommon (and it was by accident this table had so many), but it could (and should?) be very efficient for much larger tables. Right now we see execution times of at least several seconds and reaching into minute range (if there are several concurrent deletes). The query in question (with defaults in the config) is: delete from jbosscache where concat(fqn, '/') like concat(?, '%') It's so clever that it totally baffles the database's optimizer and forces it to do a full table scan instead of range index lookup. The biggest problem here is that it's not easy to replace it with something more efficient. I'd like to change deleteNodeSql in the config to: delete from jbosscache where fqn = ? or fqn like concat(?, '/', '%') (and throw out appending '/' to the fqn in Java) This statement does the same thing while allowing the database engine to use the primary key, but it uses *two* placeholders instead of one as in the original, so a simple replacement does not work. I had to subclass the cache loader and almost-duplicate remove() to do it. (Another problem is that setDeleteNodeSql() in JDBCCacheLoaderConfig is ineffective - it's inherited from the superclass, but should be overriden as this class holds its own private copy of this value; I guess I should report it as a separate bug) BTW: The same, except for the setter problem, applies to recursiveChildrenSql property. BTW2: I'm also very uncomfortable with the thought that any '%' or '_' embedded in the fqn can do considerable damage, not only in remove... Yet another bug for that? :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1453) JDBCExtCacheLoader Doesn't Handle Persistent State Transfer Correctly

by Jimmy Wilson (JIRA)

JDBCExtCacheLoader Doesn't Handle Persistent State Transfer Correctly --------------------------------------------------------------------- Key: JBCACHE-1453 URL: https://jira.jboss.org/jira/browse/JBCACHE-1453 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.1.SP9 Reporter: Jimmy Wilson Assignee: Jimmy Wilson Fix For: 1.4.X JDBCExtCacheLoader.storeState uses the availability of bytes on the MarshalledValueInputStream rather than on the ByteArrayInputStream when writing the persistent state, and since the MarshalledValueInputStream always returns zero, the persistent state is never written. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 12 months

2
3
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1230) toString() should not print entire contents of a node if it exceeds a certain size

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1230?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1230: ----------------------------------- Fix Version/s: 1.4.1.SP10 (was: 1.4.X) > toString() should not print entire contents of a node if it exceeds a certain size > ---------------------------------------------------------------------------------- > > Key: JBCACHE-1230 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1230 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.4.1.SP8, 2.1.0.CR2 > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Minor > Fix For: 1.4.1.SP10, 2.1.0.CR3, 2.1.0.GA > > > Can be very noisy in the logs. > Applies to Node/UnversionedNode as well as JBCMethodCall/MethodCall which dumps entire contents upon toString(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1241) Buddy replication, add data to a node and delete root will cause a exception to be thrown

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1241?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1241: ----------------------------------- Fix Version/s: 1.4.1.SP10 (was: 1.4.X) > Buddy replication, add data to a node and delete root will cause a exception to be thrown > ----------------------------------------------------------------------------------------- > > Key: JBCACHE-1241 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1241 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.1.0.BETA1 > Reporter: Mircea Markus > Assignee: Manik Surtani > Fix For: 1.4.1.SP10, 2.1.0.CR3, 2.1.0.GA > > > BuddyReplicationTestsBase on trunk was added to reproduce the issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1244) Buddy Manager to create _BUDDY_BACKUP_ region on initialisation before accepting any state or membership requests from buddies

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1244?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1244: ----------------------------------- Fix Version/s: 1.4.1.SP10 (was: 1.4.X) > Buddy Manager to create _BUDDY_BACKUP_ region on initialisation before accepting any state or membership requests from buddies > ------------------------------------------------------------------------------------------------------------------------------ > > Key: JBCACHE-1244 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1244 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Buddy Replication > Affects Versions: 1.4.1.GA, 2.0.0.GA, 2.1.0.CR2 > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 1.4.1.SP10, 2.1.0.CR3, 2.1.0.GA > > > Prevents a race condition in creating the node on the fly, causing potential timeout exceptions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1316) recycleQueue.put() could block forever halting evictions and eventually any replications

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1316?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1316: ----------------------------------- Fix Version/s: 1.4.1.SP10 (was: 1.4.X) > recycleQueue.put() could block forever halting evictions and eventually any replications > ---------------------------------------------------------------------------------------- > > Key: JBCACHE-1316 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1316 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Eviction > Affects Versions: 1.4.0.SP1, 2.0.0.GA, 1.4.1.SP8, 1.4.1.SP9, 2.1.0.GA > Reporter: Galder Zamarreno > Assignee: Galder Zamarreno > Fix For: 1.4.1.SP10, 2.1.1.GA, 2.2.0.GA > > > In BaseEvictionAlgorithm, whenever we can't evict a node, we add it to the > recycle queue: > protected void evict(NodeEntry ne) > { > // NodeEntry ne = evictionQueue.getNodeEntry(fqn); > if (ne != null) > { > evictionQueue.removeNodeEntry(ne); > if (!this.evictCacheNode(ne.getFqn())) > { > try > { > recycleQueue.put(ne.getFqn()); > } > catch (InterruptedException e) > { > log.debug("InterruptedException", e); > } > } > } > } > For that to happen, an Exception must have been thrown in: > protected boolean evictCacheNode(Fqn fqn) > { > if (log.isTraceEnabled()) > { > log.trace("Attempting to evict cache node with fqn of " + fqn); > } > EvictionPolicy policy = region.getEvictionPolicy(); > // Do an eviction of this node > try > { > policy.evict(fqn); > } > catch (Exception e) > { > if (e instanceof TimeoutException) > { > log.warn("eviction of " + fqn + " timed out. Will retry later."); > return false; > } > e.printStackTrace(); > return false; > } > if (log.isTraceEnabled()) > { > log.trace("Eviction of cache node with fqn of " + fqn + " successful"); > } > return true; > } > In a production environment, specially if the user ignores warnings or Exceptions, > we could end up blocking indefinitely in recycleQueue.put(ne.getFqn()); if there's > no more room. If this deadlocks, evictions deadlock leading to either OOME or > replication exceptions because no more events can be put in the eviction queue. > Rather than calling put() on the EDU.oswego.cs.dl.util.concurrent.BoundedBuffer, we > should call offer(Object x, long msecs) so that we never run the chance of blocking > forever here again. > Same thing happens for 2.x, it uses LinkedBlockingQueue and calls put() on it, which waits > if necessary for space to become available. Now, the chances of this issue occurring in 2.x > are lower because LinkedBlockingQueue is initialised with a capacity of 500000. > In 1.4.x, the BoundedBuffer was initialised with the default capacity, which was 1024. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1357) Root nodes of marshalled regions won't be loaded correclty from cache loaders

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1357?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1357: ----------------------------------- Fix Version/s: 1.4.1.SP10 (was: 1.4.X) > Root nodes of marshalled regions won't be loaded correclty from cache loaders > ----------------------------------------------------------------------------- > > Key: JBCACHE-1357 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1357 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Cache loaders > Affects Versions: 1.4.1.SP9 > Reporter: Galder Zamarreno > Assignee: Galder Zamarreno > Fix For: 1.4.1.SP10 > > > Yesterday while looking at a support case, I discovered an awkward > behavior when it came to root region based marshalling nodes and > cache loaders. > Let's say you have a cache configured with a cache loader and have > a region marshaled called starting at /me. I have created an MBean > so that I can register/unregister classloader and activate/deactivate > the region upon deployment/undeployment of the classes I wanna > put under /me. > Now, let's say that I put a k,v in /me which will get stored in the cache > loader. If I know touch the deployment archive to force a redeployment > and check the contents of the cache, they're empty. If I try to get the k I > put under /me, it'll return nothing. Why? > Simple: The cache instance is configured to preload from root (/) but > when the region is activated, /me node is created. When the preloading > phase comes, a check is made to see whether the node needs to be > loaded: > private boolean mustLoad(DataNode n, Object key) > { > if (log.isTraceEnabled()) > { > log.trace("mustLoad called with key=" + key + " and datanode=" + n); > } > return n == null || > (n.containsKey(TreeCache.UNINITIALIZED) && (key == null || !n.containsKey(key))); > } > The problem is that nothing will be preloaded for at least the /me node, > because the node is not null, and it's not TreeCache.UNINITIALIZED. Any > child nodes under the region node do not have issues like this. > This is likely a bug: maybe when the region is activated, the node should > probably be created as TreeCache.UNINITIALIZED? I think this would work). > It's true that you could say that putting data at the root node of the region is > not a good idea regardless, but I think deep down this is a bug. > p.s. This is at least present in 1.4.x, need to check trunk. > Manik: I agree this is a bug. Could you raise a JIRA for this? Also agree with > your solution, that when a region is activated and if a node needs to be > created, it should be uninitialized. > If you create a unit test, could you add it to trunk as well? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 12 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1370) Objects retrieved using getObject() in a transaction that rollsback are unusable

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1370?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1370: ----------------------------------- Fix Version/s: 1.4.1.SP10 (was: 1.4.X) > Objects retrieved using getObject() in a transaction that rollsback are unusable > -------------------------------------------------------------------------------- > > Key: JBCACHE-1370 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1370 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Legacy POJO Cache > Affects Versions: 1.4.1.SP1, 1.4.1.SP2, 1.4.1.SP3, 1.4.1.SP4, 1.4.1.SP5, 1.4.1.SP6, 1.4.1.SP7, 1.4.1.SP8, 1.4.1.SP9 > Reporter: Jason T. Greene > Assignee: Jason T. Greene > Fix For: 1.4.1.SP10 > > > POJO Cache 1.4.x adds interceptor changes during get operations to the undo list. This effectively prevents an object retrieved from a get() from being usable if a rollback occurs during the TX that contains the get. > For this, and other reasons, get operations should never rollback interceptor additions. > Original report: > In my cluster i have 2 PojoCache (REPL_SYNC,inactive on startup,transcational,replication version 1.4.0.GA). First i create one cache and fill it with data, then i create the second cache and force full state transfer using region activation. On the second cache, after it received the state, in a new transaction, i fecth an object from the cache and modify a map it contains and then rollback the transaction. After the rollback, *all* the objects in the seconds cache are corrupted: all properties values are now null!, (the other cache is not corrupted). Note, when modifing a primitive property and then rollback, the cache is not corrupted. What i found is that in the corrupted objects, the instanceAdvisor appendedInterceptors list is missing the CacheInterceptor. > attached a unit test demonstrating this bug. The test is based on the distribution org.jboss.cache.aop.statetransfer.StateTransferAopTestBase unit test, to run it, add it to the distribution org.jboss.cache.aop.statetransfer tests package and run the tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues January 2009