January 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1653) CacheLoader with BdbjeCacheStore throws NotSerializableException: org.infinispan.marshall.MarshalledValue

by Hüdaverdi Cakir (Created) (JIRA)

CacheLoader with BdbjeCacheStore throws NotSerializableException: org.infinispan.marshall.MarshalledValue --------------------------------------------------------------------------------------------------------- Key: ISPN-1653 URL: https://issues.jboss.org/browse/ISPN-1653 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.1.0.CR2 Environment: Jetty 7.5.4, JDK 1.6.0 Reporter: Hüdaverdi Cakir Assignee: Manik Surtani Trying to setup a persistent CacheLoader for distributed Lucene index. Using Berkeley DB as backend. During startup following exception is thrown: Caused by: java.io.NotSerializableException: org.infinispan.marshall.MarshalledValue at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) ~[na:1.6.0_29] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) ~[na:1.6.0_29] at com.sleepycat.bind.serial.SerialBinding.objectToEntry(SerialBinding.java:179) ~[je-5.0.34.jar:5.0.34] at com.sleepycat.collections.DataView.useKey(DataView.java:502) ~[je-5.0.34.jar:5.0.34] at com.sleepycat.collections.DataCursor.getSearchKey(DataCursor.java:551) ~[je-5.0.34.jar:5.0.34] at com.sleepycat.collections.StoredContainer.getValue(StoredContainer.java:301) ~[je-5.0.34.jar:5.0.34] at com.sleepycat.collections.StoredMap.get(StoredMap.java:240) ~[je-5.0.34.jar:5.0.34] at org.infinispan.loaders.bdbje.BdbjeCacheStore.load(BdbjeCacheStore.java:405) ~[infinispan-cachestore-bdbje.jar:5.1.0.CR2] ... 118 common frames omitted Also tried with replicated mode, fetchPersistantState=false, preload=false... no success. -- 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, 3 months

9
13
0 / 0

[JBoss JIRA] (ISPN-1654) Topology view management in Hotrod Server is not reliable

by Jacek Gerbszt (Created) (JIRA)

Topology view management in Hotrod Server is not reliable --------------------------------------------------------- Key: ISPN-1654 URL: https://issues.jboss.org/browse/ISPN-1654 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.1.0.CR1 Reporter: Jacek Gerbszt Assignee: Manik Surtani Priority: Blocker There is a problem with management of cluster topology view in address cache. You can see that by using remote client - there is the only way I know to see what is inside the address cache. When I restart the whole cluster and make a call from remote client, I receive full cluster topology (25 nodes): {code} INFO 02 sty 11:24:38 [main] org.infinispan.client.hotrod.impl.protocol.Codec11 - ISPN004006: New topology: [/10.0.36.150:11311, /10.0.36.134:11311, /10.0.36.102:11311, /10.0.36.110:11311, /10.0.36.142:11311, /10.0.36.140:11311, /10.0.36.132:11311, /10.0.36.120:11311, /10.0.36.116:11311, /10.0.36.104:11311, /10.0.36.118:11311, /10.0.36.136:11311, /10.0.36.128:11311, /10.0.36.108:11311, /10.0.36.144:11311, /10.0.36.126:11311, /10.0.36.138:11311, /10.0.36.114:11311, /10.0.36.148:11311, /10.0.36.130:11311, /10.0.36.106:11311, /10.0.36.122:11311, /10.0.36.124:11311, /10.0.36.146:11311, /10.0.36.112:11311] INFO 02 sty 11:24:38 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004014: New server added(/10.0.36.150:11311), adding to the pool. ... INFO 02 sty 11:24:38 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004014: New server added(/10.0.36.112:11311), adding to the pool. {code} Next I stop one node (10.0.36.106 in this case) and receive another topology, but not that what I expected: {code} INFO 02 sty 11:26:39 [main] org.infinispan.client.hotrod.impl.protocol.Codec11 - ISPN004006: New topology: [/10.0.36.102:11311, /10.0.36.104:11311] INFO 02 sty 11:26:39 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004014: New server added(/10.0.36.102:11311), adding to the pool. INFO 02 sty 11:26:39 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004014: New server added(/10.0.36.104:11311), adding to the pool. INFO 02 sty 11:26:39 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004016: Server not in cluster anymore(/10.0.36.148:11311), removing from the pool. ... INFO 02 sty 11:26:39 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004016: Server not in cluster anymore(/10.0.36.140:11311), removing from the pool. {code} The client is seeing only two nodes: the coordinator - 10.0.36.102 and the regular node - 10.0.36.104. Now I start a not running node back. And that's the reported topology: {code} INFO 02 sty 11:29:29 [main] org.infinispan.client.hotrod.impl.protocol.Codec11 - ISPN004006: New topology: [/10.0.36.102:11311, /10.0.36.104:11311, /10.0.36.106:11311] INFO 02 sty 11:29:29 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004014: New server added(/10.0.36.102:11311), adding to the pool. INFO 02 sty 11:29:29 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004014: New server added(/10.0.36.104:11311), adding to the pool. INFO 02 sty 11:29:29 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004014: New server added(/10.0.36.106:11311), adding to the pool. {code} The topology is still not valid. Whatever I do, I never receive the full cluster view, until the restart of all nodes. But the worse happens after stopping a coordinator. The client receives an empty topology: {code} INFO 02 sty 12:01:15 [main] org.infinispan.client.hotrod.impl.protocol.Codec11 - ISPN004006: New topology: [] INFO 02 sty 12:01:15 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004016: Server not in cluster anymore(/10.0.36.104:11311), removing from the pool. INFO 02 sty 12:01:15 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004016: Server not in cluster anymore(/10.0.36.102:11311), removing from the pool. INFO 02 sty 12:01:15 [main] org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory - ISPN004016: Server not in cluster anymore(/10.0.36.106:11311), removing from the pool. {code} Subsequent calls end with exceptions: {code} java.lang.IllegalStateException: We should not reach here! at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:78) at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:216) at org.infinispan.CacheSupport.put(CacheSupport.java:52) ... {code} Unfortunately this not reliable behaviour of remote client stops me from using HotRod Server on production. -- 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, 3 months

9
13
0 / 0

[JBoss JIRA] (ISPN-1668) Null cache values are not allowed

by Galder Zamarreño (Created) (JIRA)

Null cache values are not allowed --------------------------------- Key: ISPN-1668 URL: https://issues.jboss.org/browse/ISPN-1668 Project: Infinispan Issue Type: Bug Reporter: Galder Zamarreño Assignee: Galder Zamarreño This was always the case but somehow the following works which it shouldn't: {code}cache.put("hello", null);{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, 3 months

3
5
0 / 0

[JBoss JIRA] (ISPN-1640) Installing a merged cache view takes too long

by Dan Berindei (Created) (JIRA)

Installing a merged cache view takes too long --------------------------------------------- Key: ISPN-1640 URL: https://issues.jboss.org/browse/ISPN-1640 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.1.0.CR1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.1.0.FINAL When the CacheViewsManager running on the merge coordinator receives the merged view, it immediately sends a StateTransferControlCommand{type=RECOVER_VIEW} to all the other members of the cluster do discover their installed views. Sometimes the RECOVER_VIEW command reaches a node from the other partition before the merged view is installed on that node, and the message is dropped. The coordinator will eventually retry sending the message and succeed the second time, but the retry time can be up to 50 seconds with the default JGroups configuration. I've discussed with Bela several possible workarounds: 1. Wait a short amount of time before sending the RECOVER_VIEW command. 2. Send the RECOVER_VIEW command as unicasts. 3. Use the RSVP flag for the RECOVER_VIEW command (once we upgrade to JGroups 3.1). -- 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, 3 months

3
3
0 / 0

[JBoss JIRA] (ISPN-1671) A delayed leave message can block transaction after state transfer has ended

by Dan Berindei (Created) (JIRA)

A delayed leave message can block transaction after state transfer has ended ---------------------------------------------------------------------------- Key: ISPN-1671 URL: https://issues.jboss.org/browse/ISPN-1671 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.1.0.CR2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.1.0.CR3, 5.1.0.FINAL In order to block transactions on all nodes at approximately the same time, if we notice a leaver we block transactions even before state transfer starts. Since the order of the messages is not guaranteed, the leave message can get to a node after the state transfer has ended and it can block transactions for a long time (until the next cache view change). -- 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, 3 months

3
4
0 / 0

[JBoss JIRA] (ISPN-1652) Flags ignored in remote nodes on transaction prepare

by Galder Zamarreño (Created) (JIRA)

Flags ignored in remote nodes on transaction prepare ---------------------------------------------------- Key: ISPN-1652 URL: https://issues.jboss.org/browse/ISPN-1652 Project: Infinispan Issue Type: Bug Components: Loaders and Stores, Transactions Affects Versions: 5.1.0.CR2, 5.0.1.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.CR3, 5.1.0.FINAL Some flags might not be replicating correctly. As shown in the forum entry, transactional put calls on a node with Flag.SKIP_CACHE_LOAD might result in cache load operations when the tx prepares in a different node. -- 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, 3 months

5
5
0 / 0

[JBoss JIRA] (ISPN-1663) Grid filesystem improvements

by Marko Lukša (Created) (JIRA)

Grid filesystem improvements ---------------------------- Key: ISPN-1663 URL: https://issues.jboss.org/browse/ISPN-1663 Project: Infinispan Issue Type: Enhancement Reporter: Marko Lukša Assignee: Manik Surtani Fix For: 5.1.0.CR3 - Implement appending to files (up to now, the append parameter was ignored) - Implement GridFile.getParent() and getParentFile() - Implement GridFile.lastModified() - Prevent writing to and reading from directories - Fix bugs related to non-default chunk size - Leak when overwriting existing file with shorter content length (excess file chunks are never removed from cache) - Leak when calling GridFile.delete() (removes only file metadata, but not the actual file contents) - GridFile.createNewFile() does not honor the contract of File.createNewFile() - GridFile.list() does not honor contract of File.list() and also has a few bugs (it doesn't handle file separators correctly) - GridFilesystem.getFile(File, String) creates File with illegal path (on windows, the created file begins with "C:\...") - mkdir() fails on "/dir", but works on "dir" - the root dir is not handled properly - add javadoc to GridFilesystem -- 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, 3 months

3
3
0 / 0

[JBoss JIRA] (ISPN-1655) Upgrade to JGroups 3.0.2

by Galder Zamarreño (Created) (JIRA)

Upgrade to JGroups 3.0.2 ------------------------ Key: ISPN-1655 URL: https://issues.jboss.org/browse/ISPN-1655 Project: Infinispan Issue Type: Component Upgrade Reporter: Galder Zamarreño Assignee: Galder Zamarreño -- 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, 3 months

3
3
0 / 0

[JBoss JIRA] (ISPN-1661) Cache ends up with null values

by Galder Zamarreño (Created) (JIRA)

Cache ends up with null values ------------------------------ Key: ISPN-1661 URL: https://issues.jboss.org/browse/ISPN-1661 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.CR2 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Blocker Fix For: 5.1.0.CR3 In the 2LC code integration, I've started seeing things like this: {code}java.lang.NullPointerException at org.infinispan.container.EntryFactoryImpl.wrapEntryForPut(EntryFactoryImpl.java:151) at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:132) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:117) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:61) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.MarshalledValueInterceptor.visitPutKeyValueCommand(MarshalledValueInterceptor.java:154) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:222) at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:160) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:61) at org.infinispan.interceptors.IsMarshallableInterceptor.visitPutKeyValueCommand(IsMarshallableInterceptor.java:108) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:116) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:61) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) at org.hibernate.cache.infinispan.impl.ClassLoaderAwareCache$ClassLoaderAwareCommandInterceptor.handleDefault(ClassLoaderAwareCache.java:77) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:61) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:934) at org.infinispan.CacheImpl.putIfAbsent(CacheImpl.java:660) at org.infinispan.CacheImpl.putForExternalRead(CacheImpl.java:340) at org.infinispan.CacheImpl.putForExternalRead(CacheImpl.java:324) at org.infinispan.AbstractDelegatingCache.putForExternalRead(AbstractDelegatingCache.java:54) at org.hibernate.cache.infinispan.util.CacheAdapterImpl.putForExternalRead(CacheAdapterImpl.java:126){code} If you look at the log line before, it says: {code}2012-01-03 19:07:33,888 6368 TRACE [org.infinispan.container.EntryFactoryImpl] (main:org.hibernate.test.cache.infinispan.functional.Item) Retrieved from container ImmortalCacheEntry{key=MarshalledValue{instance=org.hibernate.test.cache.infinispan.functional.Item#3, serialized=false, cachedHashCode=3}@6d386751, value=ImmortalCacheValue{value=null}}{code} That surely cannot be right, null values are not allowed. I dunno what's causing this yet, making a note of it... -- 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, 3 months

7
7
0 / 0

[JBoss JIRA] (ISPN-1659) problem with using ispncon

by Andrzej Dopierała (Created) (JIRA)

problem with using ispncon -------------------------- Key: ISPN-1659 URL: https://issues.jboss.org/browse/ISPN-1659 Project: Infinispan Issue Type: Bug Components: Build process Environment: debian lenny Python 2.5.2 Reporter: Andrzej Dopierała Assignee: Manik Surtani I try to use ispncon. But - after instalation it doesn't work: builderlenny:~/infinispan-ispncon-e72cb36/bin# ./ispncon Traceback (most recent call last): File "./ispncon", line 3, in <module> from ispncon import console File "/usr/lib/python2.5/site-packages/ispncon-0.8.1_SNAPSHOT-py2.5.egg/ispncon/console.py", line 105 except CacheClientError as e: ^ SyntaxError: invalid syntax What i'm doing wrong? :) -- 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, 3 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2012