June 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1195) Rehashing and state transfer to use digesting

by Manik Surtani (JIRA)

Rehashing and state transfer to use digesting --------------------------------------------- Key: ISPN-1195 URL: https://issues.jboss.org/browse/ISPN-1195 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, State transfer Affects Versions: 5.0.0.FINAL Reporter: Manik Surtani Assignee: Dan Berindei Priority: Critical Fix For: 5.1.0.BETA1, 5.1.0.Final Rather than pushing entire state to new joiners, a mechanism of digests should be used to minimise network transfers. For example, Merkle trees can be used to determine which entries are out of date and need pushing, in the case of nodes that persist to a local cache store, and is restarted but still has access to some state on disk. This would require versioned entries though. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-1379) cache startup error with named cache element <evictions maxEntries="-1"/> overriding defaults

by Jan Slezak (JIRA)

cache startup error with named cache element <evictions maxEntries="-1"/> overriding defaults --------------------------------------------------------------------------------------------- Key: ISPN-1379 URL: https://issues.jboss.org/browse/ISPN-1379 Project: Infinispan Issue Type: Bug Reporter: Jan Slezak Assignee: Manik Surtani if there is defined for example <eviction maxEntries="10" strategy="FIFO"/> in <default/> and there is redefinition <eviction maxEntries="-1"/> in named cache - the cache reports error during startup: org.infinispan.config.ConfigurationException: Eviction maxEntries value cannot be less than or equal to zero if eviction is enabled -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-375) Enable Hot Rod clients to start transactions

by Galder Zamarreno (JIRA)

Enable Hot Rod clients to start transactions -------------------------------------------- Key: ISPN-375 URL: https://jira.jboss.org/jira/browse/ISPN-375 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.1.0.BETA1, 5.1.0.Final It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only. This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction. Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky. -- 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

11 years, 8 months

6
12
0 / 0

[JBoss JIRA] Created: (ISPN-1426) Socket creation not within retry logicc

by Galder Zamarreño (JIRA)

Socket creation not within retry logicc --------------------------------------- Key: ISPN-1426 URL: https://issues.jboss.org/browse/ISPN-1426 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.0.1.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA1, 5.1.0.FINAL Hot Rod client should create transport instances within the retry logic, otherwise exceptions like: {code}Caused by: java.net.ConnectException: Connection refused{code} Won't be recovered -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
7
0 / 0

[JBoss JIRA] (ISPN-2092) Write skew check not detected in LOCAL mode when doing multiple modifications

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2092: ----------------------------------- Summary: Write skew check not detected in LOCAL mode when doing multiple modifications Key: ISPN-2092 URL: https://issues.jboss.org/browse/ISPN-2092 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.1.5.FINAL Environment: jdk 1.6.0_32, Fedora 16 Reporter: Adrian Nistor Assignee: Adrian Nistor Using a local cache with optimistic locking, repeatable read and write skew check, two threads will concurrently execute a transaction that put() the same key. In this case write skew check is properly detected and only one is able to commit. If the two threads modify two keys no write skew check happens and both will commit. It turns out there is an optimization in OptimisticLockingInterceptor for single modification transactions. The write skew check is properly done on this code path but is not done for the code path that handles transactions with multiple modifications. More specifically, LockAcquisitionVisitor.performWriteSkewCheck is not invoked at all. Please have a look at WriteSkewTest.testCheckWriteSkewWithMultipleModifications() in the pull request that demonstrates the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

3
5
0 / 0

[JBoss JIRA] (ISPN-2100) Apply ConcurrentHashMapV8 improvements

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2100: -------------------------------------- Summary: Apply ConcurrentHashMapV8 improvements Key: ISPN-2100 URL: https://issues.jboss.org/browse/ISPN-2100 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL Some improvements have been added to ConcurrentHashMapV8: http://cs.oswego.edu/pipermail/concurrency-interest/2012-June/009505.html We should port these to our implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

3
4
0 / 0

[JBoss JIRA] (ISPN-2098) DummyTxTest fails randomly

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2098: ----------------------------------- Summary: DummyTxTest fails randomly Key: ISPN-2098 URL: https://issues.jboss.org/browse/ISPN-2098 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.5.FINAL Reporter: Adrian Nistor Assignee: Adrian Nistor Priority: Minor The test uses multiple threads and does not take into account that some threads might: 1. fail to perform remove() due to an immediate WriteSkewException. I only expected this exception at commit time but it seems for local caches this can also happen immediately. 2. some threads might fail to remove() altogether because the key is already gone and will not get any exception that causes a rollback See attached log. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
6
0 / 0

[JBoss JIRA] (ISPN-2095) Eviction causes lost AtomicMap entries

by Paul Ferraro (JIRA)

Paul Ferraro created ISPN-2095: ---------------------------------- Summary: Eviction causes lost AtomicMap entries Key: ISPN-2095 URL: https://issues.jboss.org/browse/ISPN-2095 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 5.1.5.FINAL Reporter: Paul Ferraro Assignee: Manik Surtani Priority: Blocker Here's the scenario: Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). 1. Create cache entry containing atomic map with 2 map entries on node1. 2. Passivate that cache entry on node2 via manual evict. 3. Modify 1 of the atomic map entries within the cache entry on node1. 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
13
0 / 0

[JBoss JIRA] (ISPN-2080) Cache Listener is not notified on cache replace

by William Burns (JIRA)

William Burns created ISPN-2080: ----------------------------------- Summary: Cache Listener is not notified on cache replace Key: ISPN-2080 URL: https://issues.jboss.org/browse/ISPN-2080 Project: Infinispan Issue Type: Bug Components: Listeners Affects Versions: 5.1.5.FINAL Reporter: William Burns Assignee: Manik Surtani Previously I have been using put with cache listeners to get remote updates. This works fine, however I changed over to using the concurrent map replace method due to my new value being a composite value and I wanted to make sure to work with asynchronous updates across jvm in a loop. The changes work fine however I am no longer getting CacheModification listener events. I have attached a test case that tests this and changes that allow for the cache listeners to be notified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
8
0 / 0

[JBoss JIRA] (ISPN-2097) Tear down methods should run even if the test method failed

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2097: ---------------------------------- Summary: Tear down methods should run even if the test method failed Key: ISPN-2097 URL: https://issues.jboss.org/browse/ISPN-2097 Project: Infinispan Issue Type: Task Components: Test Suite Affects Versions: 5.1.5.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.ALPHA1 By default TestNG doesn't run methods annotated with `@AfterMethod`/`@AfterTest`/`@AfterClass` if the test method failed. This means we have to write `alwaysRun=true` explicitly, or the method won't run after a failure and it may leave cache managers lying around. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2012