December 2011 - infinispan-issues

[JBoss JIRA] (ISPN-1622) getDefaultCacheConfiguration not defined in the EmbeddedCacheManager interface

by Kevin Pollet (Created) (JIRA)

getDefaultCacheConfiguration not defined in the EmbeddedCacheManager interface ------------------------------------------------------------------------------ Key: ISPN-1622 URL: https://issues.jboss.org/browse/ISPN-1622 Project: Infinispan Issue Type: Bug Components: Configuration, Core API Affects Versions: 5.1.0.CR1 Reporter: Kevin Pollet Assignee: Pete Muir Fix For: 5.2.0.FINAL Currently, the {{getDefaultCacheConfiguration}} method is only defined in the {{DefaultCacheManager}} 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

12 years, 6 months

3
2
0 / 0

[JBoss JIRA] (ISPN-1565) Hot Rod client connection timeout

by Michal Linhard (Created) (JIRA)

Hot Rod client connection timeout --------------------------------- Key: ISPN-1565 URL: https://issues.jboss.org/browse/ISPN-1565 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.1.0.BETA5 Reporter: Michal Linhard Assignee: Manik Surtani Currently it's only possible to specify socket timeout that applies for reading from the socket. -- 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

12 years, 6 months

6
6
0 / 0

[JBoss JIRA] (ISPN-1624) Importing project in Eclipse fails for missing m2 exclusions

by Sanne Grinovero (Created) (JIRA)

Importing project in Eclipse fails for missing m2 exclusions ------------------------------------------------------------ Key: ISPN-1624 URL: https://issues.jboss.org/browse/ISPN-1624 Project: Infinispan Issue Type: Task Components: Build process Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 5.1.0.CR2 -- 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

12 years, 6 months

3
2
0 / 0

[JBoss JIRA] (ISPN-1620) A remote get acquired a local lock for the key before writing it to L1

by Dan Berindei (Created) (JIRA)

A remote get acquired a local lock for the key before writing it to L1 ---------------------------------------------------------------------- Key: ISPN-1620 URL: https://issues.jboss.org/browse/ISPN-1620 Project: Infinispan Issue Type: Bug Reporter: Dan Berindei Assignee: Manik Surtani -- 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

12 years, 6 months

5
4
0 / 0

[JBoss JIRA] (ISPN-1612) Make Hot Rod client and server codecs use proper log instances

by Galder Zamarreño (Created) (JIRA)

Make Hot Rod client and server codecs use proper log instances -------------------------------------------------------------- Key: ISPN-1612 URL: https://issues.jboss.org/browse/ISPN-1612 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Minor Fix For: 5.1.0.CR2 The problem which Manik explains in https://github.com/infinispan/infinispan/pull/720#issuecomment-3123511 also affects the Codec classes created in 5.1 to deal with different versions of the Hot Rod protocol. IOW, we might have configured Hot Rod protocol 1.1 but you might see messages logged by Codec10 which might confuse people reading the logs. So, apply Manik's suggestions to the codec classes in the Hot Rod client and server. -- 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

12 years, 6 months

5
4
0 / 0

[JBoss JIRA] (ISPN-1609) A put with FAIL_SILENT which fails should not be allowed to retain the value in the transaction ctx

by Galder Zamarreño (Created) (JIRA)

A put with FAIL_SILENT which fails should not be allowed to retain the value in the transaction ctx --------------------------------------------------------------------------------------------------- Key: ISPN-1609 URL: https://issues.jboss.org/browse/ISPN-1609 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.CR1 Reporter: Galder Zamarreño Assignee: Manik Surtani Imagine this scenario: # Call put key=k and value="v1" # Within transaction tx1, call put for key=k, value="v2" and stop the tx. # Within a separate transaction tx2, call put with FAIL_SILENT for key=x and value="v3" # put call in tx2 should fail # within tx2 call get(k), this should return "v1" since that's the last valid committed value -> currently it returns "v3" which is wrong Code: {code} public void testSilentLockFailureAffectsPostOperations() throws Exception { final Cache<Integer, String> cache = cache(0); final TransactionManager tm = cache.getAdvancedCache().getTransactionManager(); final ExecutorService e = Executors.newCachedThreadPool(); final CountDownLatch waitLatch = new CountDownLatch(1); final CountDownLatch continueLatch = new CountDownLatch(1); cache.put(1, "v1"); Future<Void> f1 = e.submit(new Callable<Void>() { @Override public Void call() throws Exception { tm.begin(); try { cache.put(1, "v2"); waitLatch.countDown(); continueLatch.await(); } catch (Exception e) { tm.setRollbackOnly(); throw e; } finally { if (tm.getStatus() == Status.STATUS_ACTIVE) tm.commit(); else tm.rollback(); } return null; } }); Future<Void> f2 = e.submit(new Callable<Void>() { @Override public Void call() throws Exception { waitLatch.await(); tm.begin(); try { AdvancedCache<Integer, String> silentCache = cache.getAdvancedCache().withFlags( Flag.FAIL_SILENTLY, Flag.ZERO_LOCK_ACQUISITION_TIMEOUT); silentCache.put(1, "v3"); assert !silentCache.lock(1); assert "v1".equals(cache.get(1)); } catch (Exception e) { tm.setRollbackOnly(); throw e; } finally { if (tm.getStatus() == Status.STATUS_ACTIVE) tm.commit(); else tm.rollback(); continueLatch.countDown(); } return null; } }); f1.get(); f2.get(); }{code} -- 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

12 years, 6 months

7
11
0 / 0

[JBoss JIRA] (ISPN-1519) Stale locks on adding a new node to a cluster

by Erik Salter (Created) (JIRA)

Stale locks on adding a new node to a cluster --------------------------------------------- Key: ISPN-1519 URL: https://issues.jboss.org/browse/ISPN-1519 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 5.0.1.FINAL Reporter: Erik Salter Assignee: Manik Surtani There is an issue with stale locks when a new node joins a running cluster. There are three caches all using eagerLockSingleNode=true with the transaction running on the primary data owner. The local locks for the affected keys are acquired, and the prepare is sent to the backup owner. During this time, the new node is detected and joins the cluster. The transaction times out waiting for the transaction lock, and a rollback is attempted. Whereas the local keys are unlocked, the remotely-acquired locks never release. I have full trace log files at: http://dl.dropbox.com/u/10929737/5.0.1-stale-lock/data-grid-4/server.log.... http://dl.dropbox.com/u/10929737/5.0.1-stale-lock/data-grid-4/server.log.... http://dl.dropbox.com/u/10929737/5.0.1-stale-lock/data-grid-5/server.log.... The transaction in question is GlobalTransaction:<data-grid-4-61247>:169901, found on data-grid-4. I have verified that the primary owner of the keys in question are on data-grid-4. -- 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

12 years, 6 months

6
10
0 / 0

[JBoss JIRA] (ISPN-1618) Cannot use a provided JChannel if its address is not topology aware and we need it

by Tristan Tarrant (Created) (JIRA)

Cannot use a provided JChannel if its address is not topology aware and we need it ---------------------------------------------------------------------------------- Key: ISPN-1618 URL: https://issues.jboss.org/browse/ISPN-1618 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.0.CR1 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.1.0.CR2 When Infinispan is used within AS7/EAP a JChannel (actually a MuxChannel) is already connected, and therefore it is too late to set an AddressGenerator which provides TopologyAwareAddresses. Infinispan needs to be able to get the existing address and, if it is of the correct type (TopologyUUID), modify the site, rack and machine ids on it with the ones provided in the configuration. -- 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

12 years, 6 months

2
3
0 / 0

[JBoss JIRA] (ISPN-1614) lock() is under javadoc'ed

by Galder Zamarreño (Created) (JIRA)

lock() is under javadoc'ed -------------------------- Key: ISPN-1614 URL: https://issues.jboss.org/browse/ISPN-1614 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.FINAL Javadoc lock() operation better. -- 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

12 years, 6 months

4
5
0 / 0

[JBoss JIRA] (ISPN-1606) Data inconsistencies when a cache view installation is rolled back

by Dan Berindei (Created) (JIRA)

Data inconsistencies when a cache view installation is rolled back ------------------------------------------------------------------ Key: ISPN-1606 URL: https://issues.jboss.org/browse/ISPN-1606 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.1.0.CR1 Reporter: Dan Berindei Assignee: Dan Berindei When a cache view installation is rolled back, the state transfer is interrupted but is not rolled back. Because we allow transactions to run before retrying the cache view installation, in that period of time write transactions running on the old owners will not modify the data on the new owners and read transactions on the new owners will not contact the old owners, resulting in data inconsistency. -- 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

12 years, 6 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2011