June 2009 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1503) ClusteredCacheLoader does not work with MVCC

by Krzysztof Sobolewski (JIRA)

ClusteredCacheLoader does not work with MVCC -------------------------------------------- Key: JBCACHE-1503 URL: https://jira.jboss.org/jira/browse/JBCACHE-1503 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders, Clustering Affects Versions: 3.1.0.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani ClusteredCacheLoader does not seem to work with MVCC - if you take the test from the suite, ClusteredCacheLoaderTest, and remove/disable lines 75-76, thus switching from Pessimistic to MVCC, all tests fail (except those testing concurrency). I guess it should work that way? -- 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

14 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1504) Activation of a passivated node can remove parents from cache loader

by Krzysztof Sobolewski (JIRA)

Activation of a passivated node can remove parents from cache loader -------------------------------------------------------------------- Key: JBCACHE-1504 URL: https://jira.jboss.org/jira/browse/JBCACHE-1504 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders, Eviction Affects Versions: 3.1.0.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani The test (attached) performs the following steps: 1a) put(/a/a/a, x, x) 1b) put(/a/a, x, x) 2) evict(/a, true) 3) put(/a/a/a, x, y) 3a) ActivationInterceptor removes /a/a/a from cache loader and parents (if also loaded) 4) test that get(/a/a, x) is not null fails The thing is that during step 3 the node (/a/a/a) gets loaded; this also needs to create its parent (/a/a) because it too was evicted. The parent is created empty (not loaded) but it has a flag DATA_LOADED set, so during the following step 3a its data gets removed too, because ActivationInterceptor thinks it's safe to do 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

14 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1476) TransactionLog generates spurious ERROR logs on read-only transactions

by Krzysztof Sobolewski (JIRA)

TransactionLog generates spurious ERROR logs on read-only transactions ---------------------------------------------------------------------- Key: JBCACHE-1476 URL: https://jira.jboss.org/jira/browse/JBCACHE-1476 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 3.0.2.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: TransactionLogTest.patch We're testing our internal component with JBoss Cache 3.x and we noticed lots of ERROR logs from TransactionLog like this one: 2009-02-11 13:47:49,773 ERROR [org.jboss.cache.transaction.TransactionLog] (main) Could not find matching prepare for commit: GlobalTransaction:<192.168.1.18:7900>:3 It turns out that these logs are harmless and happen only on transactions that are committed without doing any writes (i.e. read-only transactions). Even though it's mostly harmless, it's annoying, hence this bug. I'm going to attach a patch with a test case, which modifies the log4j configuration and adds a "deadly" appender to TransactionLog's logger to demonstrate the issue (it's a little bit funny...) -- 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

14 years, 11 months

3
6
0 / 0

[JBoss JIRA] Closed: (JBCACHE-1252) problem is CacheStoreInterceptor

by Takayoshi Kimura (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1252?page=com.atlassian.jira.p... ] Takayoshi Kimura closed JBCACHE-1252. ------------------------------------- Resolution: Duplicate Issue Assignee: Takayoshi Kimura (was: Manik Surtani) Thanks for the report. We'll address this issue in JBCACHE-1516. > problem is CacheStoreInterceptor > -------------------------------- > > Key: JBCACHE-1252 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1252 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.4.1.SP1 > Environment: Linux 2.6.9-5.ELsmp, JBOSS 4.0.5GA > Reporter: Nadav Fried > Assignee: Takayoshi Kimura > > Hi, > When running load on a 4 node clustered jboss(4.0.5.GA) environment, one of the nodes occassionaly goes out of memory. > When looking at the memory dump, i see alot of org.jgroup.Message objects. After inspecting their contents I'm pretty sure these objects are related to jboss cache. Also, in the stack trace I see that one thread is always stuck trying to write to a HashMap in CacheStoreInterceptor. > It seems that the HashMap is not synchronized. Here is the relevant stack trace part: > "MessageDispatcher up processing thread" daemon prio=10 tid=0x6a840000 nid=0x7a7c runnable [0x68cfe000..0x68cff040] > java.lang.Thread.State: RUNNABLE > at java.util.HashMap.put(HashMap.java:376) > at org.jboss.cache.interceptors.CacheStoreInterceptor.prepareCacheLoader(CacheStoreInterceptor.java:299) > at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:130) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) > at org.jboss.cache.interceptors.TxInterceptor.handleCommitRollback(TxInterceptor.java:660) > at org.jboss.cache.interceptors.TxInterceptor.runCommitPhase(TxInterceptor.java:702) > at org.jboss.cache.interceptors.TxInterceptor$RemoteSynchronizationHandler.afterCompletion(TxInterceptor.java:1007) > at org.jboss.cache.interceptors.OrderedSynchronizationHandler.afterCompletion(OrderedSynchronizationHandler.java:83) > at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1526) > at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1198) > at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:377) > at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:479) > at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:304) > at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:127) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) > at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183) > at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520) > at org.jboss.cache.TreeCache._replicate(TreeCache.java:4827) > at sun.reflect.GeneratedMethodAccessor117.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236) > at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:220) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) > at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) > at java.lang.Thread.run(Thread.java:619) > Here is our configuration(same on all 4 nodes) - (I know it's still the old configuration style but still it should work): >  >  >  > <mbean code="org.jboss.cache.TreeCache" > name="MessagingAS:service=MASClusterCache"> > <depends>jboss:service=Naming</depends> > <depends>jboss:service=TransactionManager</depends> >  > <attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup</attribute> >  > <attribute name="CacheLoaderClass">org.jboss.cache.loader.FileCacheLoader</attribute> > <attribute name="CacheLoaderConfig" replace="false">location=/home/TEMP/jbossCache_poller</attribute> >  > <attribute name="IsolationLevel">READ_UNCOMMITTED</attribute> >  > <attribute name="CacheMode">REPL_ASYNC</attribute> >  > <attribute name="ClusterName">MASLOAD2</attribute> >  > <attribute name="ClusterConfig"> > <config> >  >  > <UDP mcast_addr="228.1.2.5" mcast_port="45577" > ip_ttl="64" ip_mcast="true" > mcast_send_buf_size="150000" mcast_recv_buf_size="80000" > ucast_send_buf_size="150000" ucast_recv_buf_size="80000" > loopback="true"/> > <PING timeout="2000" num_initial_members="3" > up_thread="false" down_thread="false"/> > <MERGE2 min_interval="10000" max_interval="20000"/> > <FD timeout="10000" max_tries="5" shun="true" up_thread="true" down_thread="true"/> > <VERIFY_SUSPECT timeout="1500" > up_thread="false" down_thread="false"/> > <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800" > up_thread="false" down_thread="false"/> > <pbcast.STABLE desired_avg_gossip="20000" > up_thread="false" down_thread="false"/> > <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" > down_thread="false"/> > <FRAG frag_size="8192" > down_thread="false" up_thread="false"/> > <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" > shun="true" print_local_addr="true"/> > <pbcast.STATE_TRANSFER up_thread="false" down_thread="false"/> > </config> > </attribute> >  > <attribute name="InitialStateRetrievalTimeout">20000</attribute> >  > <attribute name="SyncReplTimeout">15000</attribute> >  > <attribute name="LockAcquisitionTimeout">10000</attribute> > </mbean> > Thanks, > Nadav -- 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

14 years, 12 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1515) Evicition Algorithms Can Fail In Overflow Situations

by Jimmy Wilson (JIRA)

Evicition Algorithms Can Fail In Overflow Situations ---------------------------------------------------- Key: JBCACHE-1515 URL: https://jira.jboss.org/jira/browse/JBCACHE-1515 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 1.4.1.SP13 Reporter: Jimmy Wilson Assignee: Jimmy Wilson Fix For: 1.4.X The configuration for LRU time-to-live (TTL) takes a value in seconds, and casts it as an int. This value is then manipulated dynamically to determine if a cache entry should be evicted. The problem with the LRUAlgorithm (line 50) is that it multiplies the int value by 1000 and compares it to another long (neither the TTL nor the conversion factor are cast to long). If the configured TTL is more than 2,147,484 (1/1000 of Integer.MAX_VALUE), the result of the multiplication will be a negative number and eviction will always be triggered immediately. This problem can be corrected by changing the multiplier from "1000" to "1000L". -- 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

14 years, 12 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1513) Documentation: -jboss-beans.xml should be used rather than -beans.xml

by Galder Zamarreno (JIRA)

Documentation: -jboss-beans.xml should be used rather than -beans.xml --------------------------------------------------------------------- Key: JBCACHE-1513 URL: https://jira.jboss.org/jira/browse/JBCACHE-1513 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assignee: Manik Surtani -jboss-beans.xml should be used rather than -beans.xml, otherwise beans won't deploy. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1512) extremely high memory usage problem

by sridhar reddy (JIRA)

extremely high memory usage problem ----------------------------------- Key: JBCACHE-1512 URL: https://jira.jboss.org/jira/browse/JBCACHE-1512 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.1.0.GA Environment: windows XP, windows enterprise 2003 R2, Ubuntu 8.1, Redhat 5.3 Reporter: sridhar reddy Assignee: Manik Surtani Priority: Blocker My requirement is to associate a set of key value pairs together. all these kind of key value pairs are grouped together. So i am populating all the set of value pairs in hashmap. Group of such set of maps in a node . When i populate the entire HashMap t oncewith 1000 object and persisted in cache, the data file size is around 100K. and its perfect. But when i repeated the population of cache in iteratively i mean gradually, with the same 1000 objects, the data file is grown to 30MB. how bad. When i replaced the hashmap with the set, the data size remains same in both the ways. but for me the i need hashmap. one step population code is Code: public class TestCache { private Cache<Long, Object> cache = null; public TestCache(){ try { CacheFactory<Long, Object> factory = new DefaultCacheFactory<Long, Object>(); String cacheConfigFile = "cacheloader.xml"; cache = factory.createCache(cacheConfigFile); cache.create(); cache.start(); } catch (ConfigurationException e) { } catch (CacheException e) { } } public void populateCache(){ Map<Long, Object> empMap= new HashMap<Long, Object>(); for(long i=1; i <= 1000; i++){ Employee emp = new Employee(i,"Test name "+i,"test region "+i); empMap.put(i, emp); } Node<Long, Object> collNode = cache.getRoot().addChild(Fqn.fromElements("test","emp","cache")); collNode.put(0L, empMap); cache.stop(); } public static void main(String[] args) { TestCache tc= new TestCache(); tc.populateCache(); } } the second program which kept iteratively is Code: public class TestCache { private Cache<Long, Object> cache = null; public TestCache(){ try { CacheFactory<Long, Object> factory = new DefaultCacheFactory<Long, Object>(); String cacheConfigFile = "cacheloader.xml"; cache = factory.createCache(cacheConfigFile); cache.create(); cache.start(); } catch (ConfigurationException e) { } catch (CacheException e) { } } public void populateCache(){ Map<Long, Object> empMap= null; for(long i=1; i <= 1000; i++){ Employee emp = new Employee(i,"Test name "+i,"test region "+i); Node<Long, Object> collNode = cache.getRoot().getChild(Fqn.fromElements("test","emp","cache")); if(collNode == null){ collNode = cache.getRoot().addChild(Fqn.fromElements("test","emp","cache")); } empMap = (Map<Long, Object>)collNode.get(0L); if(empMap == null) empMap= new HashMap<Long, Object>(); empMap.put(i, emp); collNode.clearData(); collNode.remove(0L); collNode.put(0L, empMap); } cache.stop(); } public static void main(String[] args) { TestCache tc= new TestCache(); tc.populateCache(); } } configuration file is Code: <?xml version="1.0" encoding="UTF-8"?> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.0"> <transaction transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup" /> <locking isolationLevel="REPEATABLE_READ" lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000" nodeLockingScheme="mvcc" writeSkewCheck="false" concurrencyLevel="500"/> <invocationBatching enabled="true"/> <jmxStatistics enabled="true"/> <loaders passivation="false" shared="false"> <preload> <node fqn="/" /> </preload> <loader class ="org.jboss.cache.loader.jdbm.JdbmCacheLoader" async="false" fetchPersistentState="true" ignoreModifications="false" > <properties> location=/home/sridhar/cache cache.jdbc.connection.factory=org.jboss.cache.loader.C3p0ConnectionFactory c3p0.maxPoolSize=10 c3p0.checkoutTimeout=5000 </properties> </loader> </loaders> </jbosscache> in the second program when i replaced the HashMap with Set, there is no difference in the size of data files created. Why such strange behaviour. what will be the solution to this? -- 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

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues June 2009