September 2008 - jbosscache-issues

[JBoss JIRA] Updated: (JBCACHE-1076) REPL_SYNC only waits for the majority of responses (not all)

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1076?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1076: ----------------------------------- Fix Version/s: 3.2.0 (was: 3.0.0.GA) Priority: Minor (was: Major) I see this as an edge case since it could lead to data inconsistencies anyway (same as async repl) but with none of the perf advantages. > REPL_SYNC only waits for the majority of responses (not all) > ------------------------------------------------------------ > > Key: JBCACHE-1076 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1076 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Manik Surtani > Priority: Minor > Fix For: 3.2.0 > > > By default, synchronous replication has to wait for *all* acks (whereas asynchronous repl waits for none). We should be able to define a config option, where we only wait for a majority of responses. For example, if we have a cluster of 10 nodes, and we don't want to wait for 10 acks, we could define that all sync method calls return after having received 6 acks. > Advantage: if we have 1-2 slow nodes in the above example, and have to wait for all replies, we are slowed down by a minority. -- 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-1401) Node.putAll(Map<K, V>) should probably be Node.putAll(Map<? extends K,? extends V>)

by Elias Ross (JIRA)

Node.putAll(Map<K, V>) should probably be Node.putAll(Map<? extends K,? extends V>) ------------------------------------------------------------------------------------ Key: JBCACHE-1401 URL: https://jira.jboss.org/jira/browse/JBCACHE-1401 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani Node.putAll(Map<K, V>) should probably be Node.putAll(Map<? extends K,? extends V>) to match the signature of Map.putAll(...) . -- 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
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1405) Readding a node deleted via a parent node causes lock timeout

by Krzysztof Sobolewski (JIRA)

Readding a node deleted via a parent node causes lock timeout ------------------------------------------------------------- Key: JBCACHE-1405 URL: https://jira.jboss.org/jira/browse/JBCACHE-1405 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 2.1.1.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: CacheTest.java Everything happens in the same transaction. Lets say we have a node /a/b/c. When I remove node /a, all three nodes (up to c) are marked as deleted. When I add node c again under the same path, I get a lock timeout on this node (with not really detailed message). >From what I gather, the nodes are marked deleted just fine, but one detail is missing: they are not added as deleted in current transaction (except /a, which I delete explicitly). The removed root is added but its children are not. This causes a failure because PessimisticLockInterceptor.manageReverseRemove() checks whether the node is marked as deleted and whether it is marked as deleted in the current transaction. The latter test fails for /a/b. -- 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
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1399) programatic eviction configuration

by Mircea Markus (JIRA)

programatic eviction configuration ---------------------------------- Key: JBCACHE-1399 URL: https://jira.jboss.org/jira/browse/JBCACHE-1399 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.CR7 Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 2.2.0.GA, 3.0.0.GA if the user specifies an eviction config for a certain region, it is discarded (no warn being logged either) if the config file does not have eviction activated, i.e. it does not specify the eviction configuration statically. On a second thought, this might be avoided if the user programmaticaly registers default eviction config, at least. This is unnecessary complexity for the user, though. On an .xml config file not having specified an eviction attribute, following code should work (also eviction should be enabled): Region region = admDataCache.getRegion(fqn, true); ExpirationConfiguration expirationConfiguration = new ExpirationConfiguration(); expirationConfiguration.setTimeToLiveSeconds(2); region.setEvictionPolicy(expirationConfiguration); Another issue (not necessarily related to this one, but on the same forum and easy to fix :) ) is that expirationConfiguration.setTimeToLiveSeconds(2); does not work. -- 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
6
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1274) Ability to configure zero nodes in memory for a region

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1274?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1274. ------------------------------------ Resolution: Done See new eviction configuration element in 3.0. > Ability to configure zero nodes in memory for a region > ------------------------------------------------------ > > Key: JBCACHE-1274 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1274 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eviction > Affects Versions: 2.0.0.GA > Reporter: J B > Assignee: Mircea Markus > Priority: Minor > Fix For: 3.0.0.GA > > > The ability to configure a region to have no nodes in memory. If you have a cache configured with a cacheloader and you for instance dont want a certain region to have any nodes in memory but just to load the data through the cacheloader. At the moment you cant set maxNodes=0, because this actually means, the region can grow to an unlimited size, so I would like the ability to be able to tell the cache that this region should have no nodes in memory. -- 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-552) Use "/" to replace "__DEFAULT__" in eviction policy

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-552?page=com.atlassian.jira.pl... ] Manik Surtani resolved JBCACHE-552. ----------------------------------- Fix Version/s: (was: 3.0.0.GA) Resolution: Out of Date > Use "/" to replace "__DEFAULT__" in eviction policy > --------------------------------------------------- > > Key: JBCACHE-552 > URL: https://jira.jboss.org/jira/browse/JBCACHE-552 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eviction > Reporter: Ben Wang > Assignee: Mircea Markus > Original Estimate: 4 days > Remaining Estimate: 4 days > > Came up with a suggestion from Bela's training course. Currently since the region specification is order important, so use of "/" can be dangerours if not specified correctly. Btu can we order it internally during eviction policy specification such that user can order them randomly? What's the implication for troubleshooting? -- 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] Commented: (JBCACHE-1221) JDBCCacheLoader optimizations

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1221?page=com.atlassian.jira.p... ] Mircea Markus commented on JBCACHE-1221: ---------------------------------------- 1) batch cache put operations during state transfer was implemented, (also the non-batching code was significantly imprved). For drivers that do not support batching this might be disabled: cache.jdbc.batch.enable=true A naive test (based on Derby db, JDBCCacheLoaderStateTransferTest.testMoreState()) shows a reduction from 28secs (no batching, old impl) to 15 secs (batching), i.e. about 45% improvement. I expect this to be even more when network calls are involved. > JDBCCacheLoader optimizations > ------------------------------ > > Key: JBCACHE-1221 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1221 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Cache loaders > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 3.0.0.GA > > > JDBCCacheLoader optimizations: > - batch cache put operations during state transfer > - batch put operations on transactions as follows: > - batch all the puts and flush on transaction commit > - if an remove takes place at some point, then flush before the remove (guess I'll also have to flush before a get takes place in the same transaction, have to check 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, 7 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1376) New configuration file format

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1376?page=com.atlassian.jira.p... ] Mircea Markus resolved JBCACHE-1376. ------------------------------------ Resolution: Done resolved as all aggregated tasks were resolved. > New configuration file format > ----------------------------- > > Key: JBCACHE-1376 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1376 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 3.0.0.GA > > > This is an umbrella task spanning several sub-tasks. -- 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-1381) Make Schema and DTD downloadable

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1381?page=com.atlassian.jira.p... ] Mircea Markus resolved JBCACHE-1381. ------------------------------------ Resolution: Done Solved. No longer needed to upload the XML file, as the JBossEntityResolver is used for looking up the schema file, and it will load the schema from the classpath. > Make Schema and DTD downloadable > -------------------------------- > > Key: JBCACHE-1381 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1381 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Manik Surtani > Assignee: Mircea Markus > -- 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] Assigned: (JBCACHE-1381) Make Schema and DTD downloadable

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1381?page=com.atlassian.jira.p... ] Mircea Markus reassigned JBCACHE-1381: -------------------------------------- Assignee: Mircea Markus (was: Manik Surtani) > Make Schema and DTD downloadable > -------------------------------- > > Key: JBCACHE-1381 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1381 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Manik Surtani > Assignee: Mircea Markus > -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues September 2008