September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3288) Putting an entry with rest gives 'Failure to marshall arguments' error

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3288?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3288: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 986888|https://bugzilla.redhat.com/show_bug.cgi?id=986888] I'm rechecking, I probably confused two bugzillas here. > Putting an entry with rest gives 'Failure to marshall arguments' error > ---------------------------------------------------------------------- > > Key: ISPN-3288 > URL: https://issues.jboss.org/browse/ISPN-3288 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Jakub Markos > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 6.0.0.Alpha2 > > Attachments: stacktrace.txt, standalone-repl.xml > > > The test has a cluster with 2 nodes. > See the attached file for the full console output and server config (same for both nodes). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3398) Unmarshall problem in compatibility mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3398?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3398: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 993738|https://bugzilla.redhat.com/show_bug.cgi?id=993738] Still present in 6.2.0.DR4 > Unmarshall problem in compatibility mode > ---------------------------------------- > > Key: ISPN-3398 > URL: https://issues.jboss.org/browse/ISPN-3398 > Project: Infinispan > Issue Type: Bug > Components: Marshalling, Remote protocols, Server > Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 6.0.0.Beta2, 6.0.0.Final > > > JDG 6.2.0.DR2 client/server tests using hotrod and cache in compatibility mode: > throw this: > {code} > 04:48:28,445 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread-0) ISPN000136: Execution error: java.io.IOException: Unsupported protocol version 9 > at org.jboss.marshalling.river.RiverUnmarshaller.start(RiverUnmarshaller.java:1243) > at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.startObjectInput(AbstractJBossMarshaller.java:138) [infinispan-commons-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:119) [infinispan-commons-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:83) [infinispan-commons-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.server.hotrod.HotRodTypeConverter.unmarshall(HotRodTypeConverter.scala:36) [infinispan-server-hotrod-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.server.hotrod.HotRodTypeConverter.boxValue(HotRodTypeConverter.scala:22) [infinispan-server-hotrod-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.compat.TypeConverterInterceptor.visitPutKeyValueCommand(TypeConverterInterceptor.java:72) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:97) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:46) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:169) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} > the exception appears for each request, the form is always > "Unsupported protocol version X" where X differs > see > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/PERF-CS/jo... > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/PERF-CS/jo... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work when locking isolation != NONE

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3330: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Hotrod clients getWithMetadata doesn't work when locking isolation != NONE > -------------------------------------------------------------------------- > > Key: ISPN-3330 > URL: https://issues.jboss.org/browse/ISPN-3330 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final, 6.0.0.Alpha4 > Reporter: Jakub Markos > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > I have a cluster of 2 infinispan servers with this configuration: > {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3"> > <cache-container name="default" default-cache="default" listener-executor="infinispan-listener"> > <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/> > <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000"> > <locking isolation="REPEATABLE_READ"/> > </distributed-cache> > </cache-container> > </subsystem>{code} > Running this code: > {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan > MetadataValue<String> k1 = remoteCache.getWithMetadata("k1"); > assertTrue(k1.getValue().equals("v1")); > // microseconds converted to seconds > assertTrue(k1.getLifespan() == 10); > assertTrue(k1.getMaxIdle() == -1);{code} > fails with: > {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can > not be cast to org.infinispan.container.entries.InternalCacheEntry > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code} > Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2050) Query is attempting to run a KeyTransformer on types which are not meant to be indexed

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2050?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2050: ------------------------------------- Was this discovered in an existing test? > Query is attempting to run a KeyTransformer on types which are not meant to be indexed > -------------------------------------------------------------------------------------- > > Key: ISPN-2050 > URL: https://issues.jboss.org/browse/ISPN-2050 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 5.1.3.FINAL > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Labels: stable_embedded_query > Fix For: 6.0.0.Beta2, 6.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3504) LevelDB Cache store in server doesn't keep data between restarts

by Michal Linhard (JIRA)

[ https://issues.jboss.org/browse/ISPN-3504?page=com.atlassian.jira.plugin.... ] Michal Linhard commented on ISPN-3504: -------------------------------------- This causes that after cache.clear() operation, the cache store writes to different file than initially and when the server is restarted again, the expected data is not there. > LevelDB Cache store in server doesn't keep data between restarts > ---------------------------------------------------------------- > > Key: ISPN-3504 > URL: https://issues.jboss.org/browse/ISPN-3504 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Mircea Markus > Fix For: 6.0.0.CR1 > > > I have config with passivation="false" purge="false" > and expect data to survive restarts which doesn't happen. > {code} > <cache-container name="default" default-cache="default" > listener-executor="infinispan-listener"> > <local-cache name="default" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <leveldb-store path="temp-leveldb" block-size="1024" > cache-size="50000" clear-threshold="100000" passivation="false" > purge="false" > > <expiration path="temp-leveldb-expired" queue-size="2000" /> > <compression type="SNAPPY" /> > <implementation type="JAVA" /> > </leveldb-store> > </local-cache> > <local-cache name="memcachedCache" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > </local-cache> > </cache-container> > {code} > failing test: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....; > hb=8e1b8a10fed5de5bf3bb9ec6fbc46857e1666798 > for JDG 6.2.0.DR4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3504) LevelDB Cache store in server doesn't keep data between restarts

by Michal Linhard (JIRA)

[ https://issues.jboss.org/browse/ISPN-3504?page=com.atlassian.jira.plugin.... ] Michal Linhard commented on ISPN-3504: -------------------------------------- OK, this is most probably caused by using different file names in start and clear methods: in start() we call: {code} db = openDatabase(configuration.location() + cacheFileName, configuration.dataDbOptions()); {code} in reinitAllDatabases() we have: {code} db = reinitDatabase(configuration.location(), configuration.dataDbOptions()); {code} > LevelDB Cache store in server doesn't keep data between restarts > ---------------------------------------------------------------- > > Key: ISPN-3504 > URL: https://issues.jboss.org/browse/ISPN-3504 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Mircea Markus > Fix For: 6.0.0.CR1 > > > I have config with passivation="false" purge="false" > and expect data to survive restarts which doesn't happen. > {code} > <cache-container name="default" default-cache="default" > listener-executor="infinispan-listener"> > <local-cache name="default" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <leveldb-store path="temp-leveldb" block-size="1024" > cache-size="50000" clear-threshold="100000" passivation="false" > purge="false" > > <expiration path="temp-leveldb-expired" queue-size="2000" /> > <compression type="SNAPPY" /> > <implementation type="JAVA" /> > </leveldb-store> > </local-cache> > <local-cache name="memcachedCache" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > </local-cache> > </cache-container> > {code} > failing test: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....; > hb=8e1b8a10fed5de5bf3bb9ec6fbc46857e1666798 > for JDG 6.2.0.DR4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3513) LevelDBStore.init called three times

by Michal Linhard (JIRA)

Michal Linhard created ISPN-3513: ------------------------------------ Summary: LevelDBStore.init called three times Key: ISPN-3513 URL: https://issues.jboss.org/browse/ISPN-3513 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 6.0.0.Alpha4 Reporter: Michal Linhard Assignee: Mircea Markus PersistenceManagerImpl.createLoadersAndWriters calls LevelDBStore.init three times unnecessarily. Also note that LevelDBStore is both CacheWriter and CacheLoader and the logic of createLoadersAndWriters doesn't seem to take into account that these are not exclusive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3512) Don't deserialize the cache loader entries needed by a remote node

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3512?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3512: -------------------------------- Description: the new API allows exposing the stored entries in serialized format. If an entry is fetched from persistent storage for the sole purpose of being sent remotely, we no longer need to deserialize it (when reading from the store) and serialize it back (when writing to the wire). Now we can write to the wire the serialized format as read fro the storage directly > Don't deserialize the cache loader entries needed by a remote node > ------------------------------------------------------------------- > > Key: ISPN-3512 > URL: https://issues.jboss.org/browse/ISPN-3512 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > > the new API allows exposing the stored entries in serialized format. If an entry is fetched from persistent storage for the sole purpose of being sent remotely, we no longer need to deserialize it (when reading from the store) and serialize it back (when writing to the wire). Now we can write to the wire the serialized format as read fro the storage directly -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3512) Don't deserialize the cache loader entries needed by a remote node

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3512?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3512: -------------------------------- Fix Version/s: 6.0.0.CR1 > Don't deserialize the cache loader entries needed by a remote node > ------------------------------------------------------------------- > > Key: ISPN-3512 > URL: https://issues.jboss.org/browse/ISPN-3512 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.CR1 > > > the new API allows exposing the stored entries in serialized format. If an entry is fetched from persistent storage for the sole purpose of being sent remotely, we no longer need to deserialize it (when reading from the store) and serialize it back (when writing to the wire). Now we can write to the wire the serialized format as read fro the storage directly -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3512) Don't deserialize the cache loader entries needed by a remote node

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3512: ----------------------------------- Summary: Don't deserialize the cache loader entries needed by a remote node Key: ISPN-3512 URL: https://issues.jboss.org/browse/ISPN-3512 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013