December 2008 - jbosscache-issues

[JBoss JIRA] Created: (JBCACHE-1407) Region-based marshalling to support multiple regions in a PREPARE.

by Brian Stansberry (JIRA)

Region-based marshalling to support multiple regions in a PREPARE. ------------------------------------------------------------------ Key: JBCACHE-1407 URL: https://jira.jboss.org/jira/browse/JBCACHE-1407 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Replication Reporter: Brian Stansberry Assignee: Manik Surtani A transaction can operate on multiple regions within a cache, so the resulting PREPARE will include data from multiple regions. But the region-based marshalling logic will identify a single region Fqn for the message (first one it finds); result is data from other regions will not unmarshall properly. Region-based marshalling needs to be able to handle such a case; analyze the prepare and create a separate region-fqn/data pair for each time the region changes. Storing the node's data in an org.jboss.cache.marshall.MarshalledValue doesn't solve the problem, as in use cases like Hibernate, custom types can be part of the Fqn (below the region root.) -- 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 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1440) Better perfoming cache loader for JDBM

by Elias Ross (JIRA)

Better perfoming cache loader for JDBM -------------------------------------- Key: JBCACHE-1440 URL: https://jira.jboss.org/jira/browse/JBCACHE-1440 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani Patch to add JdbmCacheLoader2 This non-backwards compatible version fixes some performance issues with getChildNames(), stores an entire Map not just a key. The store Map not key structure more naturally matches the granularity of cache loader operations. (For post 3.0 release I think.) -- 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 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1417) Dynamic resizing of shared lock collection for MVCC write locks based on load/cache size

by Manik Surtani (JIRA)

Dynamic resizing of shared lock collection for MVCC write locks based on load/cache size ---------------------------------------------------------------------------------------- Key: JBCACHE-1417 URL: https://jira.jboss.org/jira/browse/JBCACHE-1417 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.0.GA A few ideas here: Users could provide a min and max concurrency level, or a factor of number of nodes in the cache. Need to think of an efficient way to resize the lock collection without affecting ongoing operations. Would also need to consider intelligent collection monitoring to make sure hash functions spread nodes across the locks well, otherwise consider altering the hash function. -- 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 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1442) Improve performance with "Cache.setData" call

by Elias Ross (JIRA)

Improve performance with "Cache.setData" call --------------------------------------------- Key: JBCACHE-1442 URL: https://jira.jboss.org/jira/browse/JBCACHE-1442 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani For a configuration that uses an async cache loader in 3.0, performance of "put(Map m)" may be unexpectedly slow. This is because put(Map) is a merge call and always results in a load. Imagine if put(Map) is being done over the network, e.g. JDBC database. This is not want users would expect. And there's no alternative to this in the current API set. (The work-around is to have cache calls done using a thread pool...) Cache.getNode(X).replaceAll() won't work as it results in a load, and/or a null pointer exception if the node is not found. The old TreeCache from 1.4 had a "put erase" option. I suggest we create a setData() method that does not do a merge. Changes are attached, with some new tests, but I'm not sure the implementation is really complete. The tests set "goals" for the proper behavior of the cache loader. -- 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 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1421) Optimize writes on primitives and Strings to short-circuit if there are no changes

by Manik Surtani (JIRA)

Optimize writes on primitives and Strings to short-circuit if there are no changes ---------------------------------------------------------------------------------- Key: JBCACHE-1421 URL: https://jira.jboss.org/jira/browse/JBCACHE-1421 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.1.0 E.g., cache.put(fqn, "key", "Hello"); // tx 1 ... wait ... cache.put(fqn, "key", "Hello"); // tx 2 tx 2 should be able to short-circuit the process if there is no change in the payload. Only makes sense for primitives and Strings though. Even primitive arrays are not worth it since it would involve iterating through the array. -- 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 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1451) Read Time Out for TcpDelegatingCacheLoader

by J B (JIRA)

Read Time Out for TcpDelegatingCacheLoader ------------------------------------------ Key: JBCACHE-1451 URL: https://jira.jboss.org/jira/browse/JBCACHE-1451 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.1.1.GA Reporter: J B Assignee: Manik Surtani Priority: Trivial Currently there is no way to set the SO_TIMEOUT on the socket used in TcpDelegatingCacheLoader, this means that it can block forever on the read when asking for remote data from the TcpCacheServer. Users should be able to configure a timeout on whether they want to block forever or not. -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1444) ObjectName's validation fails for Jbosscache 3.0 on WAS 6.1 due to ":" char in name.

by Peter Kovgan (JIRA)

ObjectName's validation fails for Jbosscache 3.0 on WAS 6.1 due to ":" char in name. ------------------------------------------------------------------------------------ Key: JBCACHE-1444 URL: https://jira.jboss.org/jira/browse/JBCACHE-1444 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: 3.0.0.CR3 Environment: WAS 6.1, IBM VM Reporter: Peter Kovgan Assignee: Manik Surtani I deploy jboss cache on WAS 6.1(base install), and the problem is: new JmxRegistrationManager uses this function to create unique object name: private void processBaseName(ObjectName baseName) in LOCAL mode, name is objectNameBase = LOCAL_CACHE_PREFIX + Thread.currentThread().getName() + "-" + System.currentTimeMillis(); the problem WAS returns <ContainerName>:<some number> as a Thread.currentThread().getName(). This means you have something like WebContainer : 1 in name, but the ":" char fails during the validation in WAS's proprietary(!!!) javax.management.ObjectName.class. Probably needed some configurable option that excludes ":" Thread.currentThread().getName() - problem part - should be changed for WAS to exclude ":" below is WAS check for invalid characters: while ((in_index < len) && ((c1 = name_chars[in_index++]) != '=')) switch (c1) { // '=' considered to introduce value part case '*' : case '?' : case ',' : case ':' : case '\n' : final String ichar = ((c1=='\n')?"\\n":""+c1); throw new MalformedObjectNameException( "Invalid character '" + ichar + "' in key part of property"); default: ; } -- 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, 3 months

3
13
0 / 0

[JBoss JIRA] Created: (JBCACHE-1452) JDBCCacheLoader Doesn't Work With Sybase

by Jimmy Wilson (JIRA)

JDBCCacheLoader Doesn't Work With Sybase ---------------------------------------- Key: JBCACHE-1452 URL: https://jira.jboss.org/jira/browse/JBCACHE-1452 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 The JDBCCacheLoader implementation doesn't work with Sybase because it tries to set a null BLOB column and Sybase doesn't support BLOBs. -- 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, 4 months

2
8
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, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1406) issue with removing an node in tx

by Mircea Markus (JIRA)

issue with removing an node in tx --------------------------------- Key: JBCACHE-1406 URL: https://jira.jboss.org/jira/browse/JBCACHE-1406 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP9 Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 1.4.X tx.start()' cache.put(/a/b/c); cache.remove(/a/b); cache.put(/a/b/d); tx.commit(); assert "this still exists in the internal structure" : cache.peek(/a/b/c) == null; above assertion fails. The problem is that when tx commits and cache wants to remove /a/b, sees that its not marked for removal (as it was re-added through put(/a/b/d) )and does not look in its children. Method is TreeCache.realRemove, and it;s called from TxInterceptor.commit() UT added to reproduce the issue is: org.jboss.cache.RemoveOnTxTest. -- 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, 4 months

4
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues December 2008