October 2008 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-1335) Cache Benchmark Framework

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1335?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1335: ----------------------------------- Fix Version/s: 3.1.0 (was: 3.0.0.GA) > Cache Benchmark Framework > ------------------------- > > Key: JBCACHE-1335 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1335 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 3.1.0 > > > Following enhancements to CacheBenchmarkFramework: > - add email notifications on test status (e.g. test failed for an unexpected reason) > - add test tests to cover more functionality JBossCache: > - TCP cache loaders > - Invalidation > - JDBCCacheLoading > - add tests to cover some other access patterns from JBossCache. Currently there is only an SessionSimulator test > - add a report generator on top of these reports so that data can be centralized easier -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1386) Parallelize TestNG tests

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1386?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1386. ------------------------------------ Resolution: Done > Parallelize TestNG tests > ------------------------ > > Key: JBCACHE-1386 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1386 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Scripts and processes > Reporter: Manik Surtani > Assignee: Dominik Pospisil > Fix For: 3.0.0.GA > > > Stuff that will need to rely on JGroups' ChannelFactory for unit 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1426) Putting a null map in the cache when the node already contains data causes the JDBC Cache Loader to barf

by Manik Surtani (JIRA)

Putting a null map in the cache when the node already contains data causes the JDBC Cache Loader to barf -------------------------------------------------------------------------------------------------------- Key: JBCACHE-1426 URL: https://jira.jboss.org/jira/browse/JBCACHE-1426 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.2.1.CR1, 2.2.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Priority: Critical Fix For: 2.2.1.CR2, 2.2.1.GA simple test: cache.put(fqn, key, value); cache.put(fqn, null); // causes the JDBC cache loader to barf. This is now in the test suite - CacheLoaderTestsBase.testPutNullDataMap() and CacheLoaderTestsBase.testPutNullDataMapNodeHasData(). -- 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, 6 months

1
2
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1382) Investigate use of ExposedBAOS instead of BAOS when marshalling objects

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1382?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1382: ----------------------------------- Fix Version/s: 2.2.1.CR2 > Investigate use of ExposedBAOS instead of BAOS when marshalling objects > ----------------------------------------------------------------------- > > Key: JBCACHE-1382 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1382 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 2.2.1.CR2, 2.2.1.GA, 3.0.0.ALPHA2, 3.0.0.GA > > > From Bela's email: > "At least in AbstractMarshaller: > public byte[] objectToByteBuffer(Object obj) throws Exception > { > ByteArrayOutputStream baos = new ByteArrayOutputStream(); > ObjectOutputStream out = ObjectSerializationFactory.createObjectOutputStream(baos); > objectToObjectStream(obj, out); > out.close(); > return baos.toByteArray(); > } > Here, an ExposedByteArrayOutputStream instead of a BAOS would prevent the COPY of the byte buffer. We also don't need to be concerned about reentrancy as the output streams are local (stack) variables... > Maybe you guys should take a look at all occurrences of BAOS !" -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1423) Call to put(Fqn, Map) where Fqn is passivated leads to out of date data

by Brian Stansberry (JIRA)

Call to put(Fqn, Map) where Fqn is passivated leads to out of date data ----------------------------------------------------------------------- Key: JBCACHE-1423 URL: https://jira.jboss.org/jira/browse/JBCACHE-1423 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders, Eviction Affects Versions: 3.0.0.CR1, 2.2.1.CR1 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 2.2.1.GA See JBCACHE-1172 for discussion of core problem; this is a variant of that wherein put(Fqn, Map) doesn't result result in loading data from the cache loader. Result is if the put(...) overwrote a key, the in-memory data in the node has the new value but the old value still exists on disk and node.isDataLoaded() will still return false. When a later request causes JBC to detect that n.isDataLoaded() == false, the old data will be retrieved from the cache loader and will replace the newer correct data. Following test to be added to PassivationTestsBase shows the issue: public void testPutDataMapAfterPassivation() throws Exception { Fqn f = Fqn.fromString("/a"); assert !cache.exists(f); assert !loader.exists(f); Map<Object, Object> input = new HashMap(); input.put("one", "one"); input.put("two", "two"); cache.put(f, input); cache.evict(f); input = new HashMap(); input.put("one", "oneA"); cache.put(f, input); Map data = cache.getRoot().getChild(f).getData(); assertEquals("incorrect # of entries", 2, data.size()); assertEquals("Has key 'one", "oneA", data.get("one")); // FAILS!!! assertEquals("Has key 'two", "two", data.get("two")); } Simple fix is in CacheLoaderInterceptor: change from 'false' to 'true' value of 'allKeys' param passed to loadIfNeeded() by visitPutDataMapCommand(). A more general fix would be to change CacheLoaderInterceptor.loadNode() such that no key/value pair in the map loaded from the cache loader is allowed to override an existing key/value pair in the in-memory node. That could have broader repercussions though, so I intend to fix this the simple 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

15 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1420) LockForChildInsertRemove flag not set for root node

by Krzysztof Sobolewski (JIRA)

LockForChildInsertRemove flag not set for root node --------------------------------------------------- Key: JBCACHE-1420 URL: https://jira.jboss.org/jira/browse/JBCACHE-1420 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani The lockForChildInsertRemove flag gets propagated to all nodes but the root. The root node is being constructed at least four times, three of which properly extract this flag from Configuration object; the remaining one doesn't because it receives null Configuration (it's the first one created). The thing is that the object returned as the root node to the application is the only one with this flag uninitialized. At this point I saw the stack trace and gave up all hopes of penetrating the initialization logic :) Usually this is no big deal, but I have a test that can reliably blow up in 10 seconds on average (on an old, UP laptop) because of that :) and it scares me... -- 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, 6 months

2
5
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1382) Investigate use of ExposedBAOS instead of BAOS when marshalling objects

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1382?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1382: ----------------------------------- Fix Version/s: 2.2.1.GA > Investigate use of ExposedBAOS instead of BAOS when marshalling objects > ----------------------------------------------------------------------- > > Key: JBCACHE-1382 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1382 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 2.2.1.GA, 3.0.0.ALPHA2, 3.0.0.GA > > > From Bela's email: > "At least in AbstractMarshaller: > public byte[] objectToByteBuffer(Object obj) throws Exception > { > ByteArrayOutputStream baos = new ByteArrayOutputStream(); > ObjectOutputStream out = ObjectSerializationFactory.createObjectOutputStream(baos); > objectToObjectStream(obj, out); > out.close(); > return baos.toByteArray(); > } > Here, an ExposedByteArrayOutputStream instead of a BAOS would prevent the COPY of the byte buffer. We also don't need to be concerned about reentrancy as the output streams are local (stack) variables... > Maybe you guys should take a look at all occurrences of BAOS !" -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCACHE-1082) Optimise nodes for single elements

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1082?page=com.atlassian.jira.p... ] Manik Surtani reassigned JBCACHE-1082: -------------------------------------- Assignee: Manik Surtani (was: Mircea Markus) > Optimise nodes for single elements > ---------------------------------- > > Key: JBCACHE-1082 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1082 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR1 > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.1.0 > > Attachments: ReplicatedPojoPerfTest.java, UnversionedNode.patch.txt > > > Many use cases just place a single object in a Node. Rather than going through the memory and performance penalties of using Maps for a single entry, we should: > 1) Create a reference to 2 Objects for key and value, as well as a Map. > 2) Only initialise/construct the Map if Node.putAll() is called, or when Node.put() is called with a second key/value pair > 3) Otherwise just hold the key/value pair as direct object refs. > Would affect UnversionedNode and WorkspaceNodeImpl. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1082) Optimise nodes for single elements

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1082?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1082. ------------------------------------ Fix Version/s: 3.0.0.GA (was: 3.1.0) Resolution: Done Done using a SingletonMap and upgrading/downgrading where possible. Should result in a *much* smaller memory footprint and possibly faster access times (I say possibly because writes are a bit slower, in checking whether upgrading or downgrading the map is needed) > Optimise nodes for single elements > ---------------------------------- > > Key: JBCACHE-1082 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1082 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR1 > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.0.0.GA > > Attachments: ReplicatedPojoPerfTest.java, UnversionedNode.patch.txt > > > Many use cases just place a single object in a Node. Rather than going through the memory and performance penalties of using Maps for a single entry, we should: > 1) Create a reference to 2 Objects for key and value, as well as a Map. > 2) Only initialise/construct the Map if Node.putAll() is called, or when Node.put() is called with a second key/value pair > 3) Otherwise just hold the key/value pair as direct object refs. > Would affect UnversionedNode and WorkspaceNodeImpl. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1408) Optimistic locking + JDBC cache loader + DataSources

by Mircea Markus (JIRA)

Optimistic locking + JDBC cache loader + DataSources ---------------------------------------------------- Key: JBCACHE-1408 URL: https://jira.jboss.org/jira/browse/JBCACHE-1408 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.0.ALPHA1, 2.2.0.GA Reporter: Mircea Markus Assignee: Manik Surtani CacheStoreInterceptor.handleCommitCommand calls CacheStoreInterceptor.storeInternalState. In the optimistic scenario, this will try to add the version of the node (internal state) to the previously stored nodes (nodes are being called in handlePrepareCommand). The problem is that handleCommitCommand is called in an transaction having the status Status.COMMITTED, and when trying to fetch a Connection, org.jboss.resource.connectionmanager.TxConnectionManager checks for current tx status and throws an exception if running tx is not active. Solution: move the code which stores additional info in handlePrepareCommand. This should also bring important performance gains, as for each node a new DB call is made in order to add the version (see CacheStoreInterceptor.storeInternalState). -- 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, 7 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues October 2008