[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
…
[View More]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
[View Less]
13 years, 3 months
[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 …
[View More]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
[View Less]
13 years, 3 months
[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 …
[View More]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
[View Less]
13 years, 3 months
[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()
- …
[View More]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
[View Less]
13 years, 3 months
[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
…
[View More]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
[View Less]
13 years, 3 months