August 2010 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-587) ClassCastException in PutKeyValueCommand

by Manik Surtani (JIRA)

ClassCastException in PutKeyValueCommand ---------------------------------------- Key: ISPN-587 URL: https://jira.jboss.org/browse/ISPN-587 Project: Infinispan Issue Type: Bug Components: Tree API Affects Versions: 4.1.0.CR2 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR3 This command attempts to cast an entry to a MVCCEntry but it is possible that the entry in question is just a CacheEntry - happens when using the AtomicMap API, which in turn is used by the Tree adapter. "public Object perform(InvocationContext ctx) throws Throwable { Object o; MVCCEntry e = (MVCCEntry) ctx.lookupEntry(key); Object entryValue = e.getValue(); ... " should be: " public Object perform(InvocationContext ctx) throws Throwable { Object o; CacheEntry e = (CacheEntry) ctx.lookupEntry(key); Object entryValue = e.getValue(); ... " -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
8
0 / 0

[JBoss JIRA] Created: (ISPN-592) Update the LuceneKey2StringMapper to implement TwoWayKey2StringMapper

by Sanne Grinovero (JIRA)

Update the LuceneKey2StringMapper to implement TwoWayKey2StringMapper --------------------------------------------------------------------- Key: ISPN-592 URL: https://jira.jboss.org/browse/ISPN-592 Project: Infinispan Issue Type: Task Components: Loaders and Stores, Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 4.1.0.CR3 Lucene Directory provides a Key2StringMapper to use it together to a JdbcStringBasedCacheStore, this implementation needs to be update to implement TwoWayKey2StringMapper to support preload from the cachestore and for distribution (used during rehashing) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-596) Calls to AdvancedCache.lock() should throw an UnsupportedException if deadlock detection is enabled

by Manik Surtani (JIRA)

Calls to AdvancedCache.lock() should throw an UnsupportedException if deadlock detection is enabled --------------------------------------------------------------------------------------------------- Key: ISPN-596 URL: https://jira.jboss.org/browse/ISPN-596 Project: Infinispan Issue Type: Bug Components: Core API, Transactions Affects Versions: 4.1.0.CR2 Reporter: Manik Surtani Assignee: Mircea Markus Fix For: 4.1.0.CR3, 4.1.0.Final This is temporary, until ISPN-518 is closed. After that, lock() and deadlock detection should be allowed again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-582) Eviction with passivation results in java.lang.NullPointerException or failed gets

by Paul Nardone (JIRA)

Eviction with passivation results in java.lang.NullPointerException or failed gets ---------------------------------------------------------------------------------- Key: ISPN-582 URL: https://jira.jboss.org/browse/ISPN-582 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 4.1.0.CR2 Reporter: Paul Nardone Assignee: Manik Surtani Attachments: InfinispanTest4.java Setup a simple case with a cacheloader set with passivation enabled and and eviction policy of LRU and max enteries 1 -Put first value to cache -Put second value to the cache -Eviction runs org.infinispan.interceptors.PassivationInterceptor#visitEvictCommand attempts to passivate the first value but dataContainer.get(key); returns NULL as it appears the value has already been removed from the data container, which is then passed into the cache store resulting in the NPE Behaviour is subtly different if EvictionThreadPolicy.DEFAULT is used as the NPE is not immediately obvious but the operation still fails With EvictionStrategy.LIRS similar issues arrise, the bug is not apparent on the second put operation but when get is executed NULL is returned This only seems to occur with Passivation enabled I encountered this when making heavy use of Lucene InfinispanDirectory and traced it through to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
6
0 / 0

[JBoss JIRA] Updated: (ISPN-180) Colocated nodes should be handled in DIST

by Manik Surtani (JIRA)

[ https://jira.jboss.org/browse/ISPN-180?page=com.atlassian.jira.plugin.sys... ] Manik Surtani updated ISPN-180: ------------------------------- Fix Version/s: 4.2.0.BETA1 4.2.0.Final (was: 5.0.0.BETA1) (was: 5.0.0.Final) > Colocated nodes should be handled in DIST > ----------------------------------------- > > Key: ISPN-180 > URL: https://jira.jboss.org/browse/ISPN-180 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Fix For: 4.2.0.BETA1, 4.2.0.Final > > > DefaultConsistentHash should place addresses on the hash wheel such that colocated nodes are never less than repl_count nodes apart to prevent data loss when a server fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-594) With deadlock detection enabled, occasional null pointer exceptions are experienced when using the lock() API

by Manik Surtani (JIRA)

With deadlock detection enabled, occasional null pointer exceptions are experienced when using the lock() API ------------------------------------------------------------------------------------------------------------- Key: ISPN-594 URL: https://jira.jboss.org/browse/ISPN-594 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 4.1.0.CR2 Environment: Deadlock detection + Reporter: Manik Surtani Assignee: Manik Surtani Priority: Critical Fix For: 4.1.0.CR3 This has to do with the lock container. The stack trace is as follows: java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) at org.infinispan.util.concurrent.locks.containers.OwnableReentrantPerEntryLockContainer.getLockFromMap(OwnableReentrantPerEntryLockContainer.java:38) at org.infinispan.util.concurrent.locks.containers.OwnableReentrantPerEntryLockContainer.ownsLock(OwnableReentrantPerEntryLockContainer.java:28) at org.infinispan.util.concurrent.locks.LockManagerImpl.ownsLock(LockManagerImpl.java:123) at org.infinispan.util.concurrent.locks.DeadlockDetectingLockManager.localVsLocalDld(DeadlockDetectingLockManager.java:94) at org.infinispan.util.concurrent.locks.DeadlockDetectingLockManager.lockAndRecord(DeadlockDetectingLockManager.java:78) at org.infinispan.container.EntryFactoryImpl.acquireLock(EntryFactoryImpl.java:205) at org.infinispan.container.EntryFactoryImpl.wrapEntryForWriting(EntryFactoryImpl.java:148) at org.infinispan.container.EntryFactoryImpl.wrapEntryForWriting(EntryFactoryImpl.java:106) at org.infinispan.interceptors.LockingInterceptor.visitLockControlCommand(LockingInterceptor.java:146) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:136) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:136) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:136) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.MarshalledValueInterceptor.visitLockControlCommand(MarshalledValueInterceptor.java:92) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:136) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:171) at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:115) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:136) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:58) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:39) at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:136) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:271) at org.infinispan.CacheDelegate.lock(CacheDelegate.java:296) at org.infinispan.CacheDelegate.lock(CacheDelegate.java:289) at test.TestReplace.increase(TestReplace.java:112) at test.TestReplace.access$000(TestReplace.java:20) at test.TestReplace$XThread.run(TestReplace.java:95) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
4
0 / 0

[JBoss JIRA] Created: (ISPN-595) Replication timeout if lock acquired before other node join

by Rodrigo Faria (JIRA)

Replication timeout if lock acquired before other node join ----------------------------------------------------------- Key: ISPN-595 URL: https://jira.jboss.org/browse/ISPN-595 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 4.1.0.CR2 Reporter: Rodrigo Faria Assignee: Manik Surtani If a node acquires a lock and then a another node joins in and tries to acquire the same lock, a replication timeout exception occurs. This does not have to do with lock timeout, since a much higher lockAcquisitionTimeout was configured. This is the exception stack trace: 14:00:52,015 [main] ERROR s.InvocationContextInterceptor - Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for myhostname-23359 at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:421) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:100) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:124) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:229) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:216) at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:199) at org.infinispan.interceptors.base.BaseRpcInterceptor.visitLockControlCommand(BaseRpcInterceptor.java:59) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.LockingInterceptor.visitLockControlCommand(LockingInterceptor.java:149) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:171) at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:115) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:58) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:39) at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147) at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:271) at org.infinispan.CacheDelegate.lock(CacheDelegate.java:296) at org.infinispan.CacheDelegate.lock(CacheDelegate.java:289) at infinispan.Test.main(Test.java:30) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
5
0 / 0

[JBoss JIRA] Created: (ISPN-593) Add ability to filter a query with a list of types

by Manik Surtani (JIRA)

Add ability to filter a query with a list of types -------------------------------------------------- Key: ISPN-593 URL: https://jira.jboss.org/browse/ISPN-593 Project: Infinispan Issue Type: Feature Request Components: Querying Affects Versions: 4.1.0.CR2 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR3, 4.1.0.Final This is already supported in Hibernate Search. We just need to add a public API analogy to this. See: http://github.com/emmanuelbernard/hibernate-search/blob/master/hibernate-... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-590) Lucene segments file are flushed twice using SKIP_LOCK, implement proper index commit()

by Sanne Grinovero (JIRA)

Lucene segments file are flushed twice using SKIP_LOCK, implement proper index commit() --------------------------------------------------------------------------------------- Key: ISPN-590 URL: https://jira.jboss.org/browse/ISPN-590 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.1.0.CR2 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1.0.CR3 For the segments file only Lucene uses a flush()+commit() semantics, which is currently mapped as put()+put() twice, while we could actually put it at commit only. Also as we're using the SKIP_LOCK flag on the byte[] of the contents of this file, which never changes, it's not deterministic which value is pushed to the cache, as the second's put() value contains the checksum too and the first not, the index looks like corrupted if the first put() is accepted only. Going to use batching around this, to properly implement commit() semantics delegating to an eventual transactionmanager, as suggested by Lucene's design of flush+commit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-579) JdbcStringBasedCacheStore shouldn't preload data from the store

by Sanne Grinovero (JIRA)

JdbcStringBasedCacheStore shouldn't preload data from the store --------------------------------------------------------------- Key: ISPN-579 URL: https://jira.jboss.org/browse/ISPN-579 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.1.0.CR2 Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 4.1.0.Final It appears that if I happen to configure a JdbcStringBasedCacheStore using preload=true then cache is preloaded with the values but using the keys in their String form - which is pointless. An error should be thrown, like illegal configuration, or a warning logged at runtime while attempting to load from this implementation and ignoring the load request. Also documentation is not pointing out this limitation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2010