[JBoss JIRA] (ISPN-3467) Remove support for strictPeerToPeer = true
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3467?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3467:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 6.0.0.Beta2
Resolution: Done
> Remove support for strictPeerToPeer = true
> ------------------------------------------
>
> Key: ISPN-3467
> URL: https://issues.jboss.org/browse/ISPN-3467
> Project: Infinispan
> Issue Type: Task
> Components: Configuration, RPC, Server
> Affects Versions: 6.0.0.Alpha3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 6.0.0.Beta2
>
>
> Setting {{transport.strictPeerToPeer = true}} doesn't really do anything with dist caches with L1 disabled, as commands are replicated only to members of the cache. With L1 enabled, writes/txs may or may not fail, depending on if there are any L1 requestors for the modified keys and on the value of {{clustering.l1.invalidationThreshold}} - unpredictable, so more harmful than useful.
> With repl caches, the setting does work as advertised: even if the cache topology contains only the nodes with the cache running, the writes/txs are sent to all the nodes in the cluster, and they will fail if the cache is not running on one of them. On the other hand, in order to retry the operation, the users would have to wait for the cache's topology to contain all the nodes in the cluster - so if they need to ensure that a cache is present on all the nodes in the cluster, they could check that {{RpcManager.getMembers().equals(Transport.getMembers()}} directly.
> So we should remove the {{transport.strictPeerToPeer}} setting, although we could mark it as deprecated and log a warning for the time being.
--
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
11 years, 3 months
[JBoss JIRA] (ISPN-3498) Cannot construct org.infinispan.util.KeyValuePair as it does not have a no-args constructor
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3498?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3498:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Cannot construct org.infinispan.util.KeyValuePair as it does not have a no-args constructor
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-3498
> URL: https://issues.jboss.org/browse/ISPN-3498
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 6.0.0.Alpha4
> Environment: Azul JDK
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: jdg62blocker, testsuite_stability
> Fix For: 6.0.0.Beta2
>
>
> When infinispan testsuite(Alpha3) is running with Azul JDK
> java.runtime.version = 1.6.0_33-b5
> java.runtime.name =Java(TM) SE Runtime Environment
> java.vm.version = 1.6.0_33-ZVM_5.5.3.0-b5-product-azlinuxM-X86_64
> java.vm.vendor = Azul Systems, Inc.
> os.name = Linux
> os.version = 2.6.32-358.11.1.el6.x86_64
> sun.arch.data.model = 64
> sun.cpu.endian = little
> Wollowing redundant Exception occurs
> Error Message
> Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor ---- Debugging information ---- message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException cause-message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor class : org.infinispan.container.entries.ImmortalCacheValue required-type : org.infinispan.container.entries.ImmortalCacheValue converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter path : /org.infinispan.container.entries.ImmortalCacheValue line number : 1 version : 1.4.1-redhat-2 -------------------------------
> Stacktrace
> com.thoughtworks.xstream.converters.ConversionException: Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> ---- Debugging information ----
> message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> cause-message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> class : org.infinispan.container.entries.ImmortalCacheValue
> required-type : org.infinispan.container.entries.ImmortalCacheValue
> converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
> path : /org.infinispan.container.entries.ImmortalCacheValue
> line number : 1
> version : 1.4.1-redhat-2
> -------------------------------
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:79)
> at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:134)
> at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1035)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1019)
> at com.thoughtworks.xstream.XStream.fromXML(XStream.java:895)
> at com.thoughtworks.xstream.XStream.fromXML(XStream.java:886)
> at org.infinispan.marshall.TestObjectStreamMarshaller.objectFromObjectStream(TestObjectStreamMarshaller.java:65)
> at org.infinispan.marshall.TestObjectStreamMarshaller.objectFromByteBuffer(TestObjectStreamMarshaller.java:97)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromInputStream(AbstractMarshaller.java:105)
> at org.infinispan.loaders.jdbc.JdbcUtil.unmarshall(JdbcUtil.java:66)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.readStoredEntry(JdbcStringBasedCacheStore.java:391)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:328)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:67)
> at org.infinispan.loaders.spi.LockSupportCacheStore.load(LockSupportCacheStore.java:128)
> at org.infinispan.loaders.spi.AbstractCacheLoader.containsKey(AbstractCacheLoader.java:34)
> at org.infinispan.loaders.BaseCacheStoreTest.testCommitAndRollbackWithoutPrepare(BaseCacheStoreTest.java:427)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: com.thoughtworks.xstream.converters.reflection.ObjectAccessException: Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.newInstance(PureJavaReflectionProvider.java:71)
> at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.instantiateNewInstance(AbstractReflectionConverter.java:424)
> at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:229)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)
> ... 40 more
> You can see it in jenkins http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-62-ispn-testsuite...
> After implementing or extending Serializable interface in BucketInternalCacheEntry, InternalCacheValue exception disappeared
> Second build was done with Alpha4 version and the same exception appers because of new classes and functionality added
> You can see it in jenkins http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-62-ispn-testsuite...
--
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
11 years, 3 months
[JBoss JIRA] (ISPN-3509) postgresplus database not auto-detected
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3509?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3509:
--------------------------------
Fix Version/s: (was: 6.0.0.Beta2)
> postgresplus database not auto-detected
> ----------------------------------------
>
> Key: ISPN-3509
> URL: https://issues.jboss.org/browse/ISPN-3509
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Alpha3, 6.0.0.Alpha4
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Priority: Minor
> Attachments: server.log
>
>
> When I run our functional tests inside EAP server against postgresplus database following error occured
> 17:19:12,893 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (pool-1-thread-1) ISPN000136: Execution error: org.infinispan.commons.CacheConfigurationException: Unable to detect database type from JDBC driver name or connection metadata. Please provide this manually using the 'databaseType' property in your configuration. Supported database type strings are [MYSQL, POSTGRES, DERBY, HSQL, H2, SQLITE, DB2, DB2_390, INFORMIX, INTERBASE, FIREBIRD, SQL_SERVER, ACCESS, ORACLE, SYBASE]
> at org.infinispan.loaders.jdbc.TableManipulation.getDatabaseType(TableManipulation.java:412) [infinispan-cachestore-jdbc.jar:6.0.0.Alpha4-redhat-1]
> Jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
>
--
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
11 years, 3 months
[JBoss JIRA] (ISPN-3449) ReplaceCommand with ignorePrevValue=true does not work on null entries
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3449?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3449:
------------------------------------
Looks like this only happens for non-tx caches, for tx caches we use {{EntryFactory.wrapEntryForPut()}} when ignorePreviousValue is {{true}}.
> ReplaceCommand with ignorePrevValue=true does not work on null entries
> ----------------------------------------------------------------------
>
> Key: ISPN-3449
> URL: https://issues.jboss.org/browse/ISPN-3449
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.Beta2
>
>
> If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the EntryWrappingInterceptor/EntryFactoryImpl won't put it the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails.
> The command on primary owner succeeds as it does not check whether the responses are successful.
--
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
11 years, 3 months
[JBoss JIRA] (ISPN-3542) Read Only transaction optimization doesn't work properly for RepeatableRead
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3542?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-3542:
-----------------------------------
[~william.burns] the read-only transactions was sending the CommitCommand twice. I've made a PR to fix it.
> Read Only transaction optimization doesn't work properly for RepeatableRead
> ---------------------------------------------------------------------------
>
> Key: ISPN-3542
> URL: https://issues.jboss.org/browse/ISPN-3542
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Beta1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.Beta2
>
> Attachments: ISPN-3542-patch
>
>
> There is a readOnly optimization that Infinispan does to make sure we don't do a 2PC when there is no data to update. However the code for this does
> {code}
> public boolean isReadOnly() {
> return (modifications == null || modifications.isEmpty()) && (lookedUpEntries == null || lookedUpEntries.isEmpty());
> }
> {code}
> For repeatable read we always add a value to lookedUpEntries so this optimization never works that isolation level.
> Looking closer it seems we do a 1PC when it is readOnly to clean up values, so there shouldn't be a need to care about lookedUpEntries (my guess is this was done as a way to test for locks).
--
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
11 years, 3 months
[JBoss JIRA] (ISPN-3345) CachePutInterceptorTest does not always close cache managers
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3345?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3345:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> CachePutInterceptorTest does not always close cache managers
> ------------------------------------------------------------
>
> Key: ISPN-3345
> URL: https://issues.jboss.org/browse/ISPN-3345
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 6.0.0.Beta2, 6.0.0.Final
>
>
> Sometimes CDI's CachePutInterceptorTest fails to close all cache managers:
> {code}
> [16:39:06][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test putWithCacheKeyGenerator(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:06][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 29, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePut(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 30, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePutBeforeInvocation(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 31, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePutCacheKeyParam(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 32, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePutWithCacheName(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 33, failed: 0, skipped: 0.
> [16:40:07][org.infinispan:infinispan-cdi]
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!! (testng-CachePutInterceptorTest) Exiting because CachePutInterceptorTest has NOT shut down all the cache managers it has started !!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!! (testng-CachePutInterceptorTest) The still-running cacheManager was created here: org.infinispan.cdi.AdvancedCacheProducer.getAdvancedCache(AdvancedCacheProducer.java:67) !!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] {code}
--
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
11 years, 3 months
[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:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 993738|https://bugzilla.redhat.com/show_bug.cgi?id=993738] from ASSIGNED to POST
> 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: Pedro Ruivo
> Priority: Critical
> Labels: jdg62blocker
> 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
11 years, 3 months
[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:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 993738|https://bugzilla.redhat.com/show_bug.cgi?id=993738] from ASSIGNED to POST
> 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: Pedro Ruivo
> Priority: Critical
> Labels: jdg62blocker
> 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
11 years, 3 months
[JBoss JIRA] (ISPN-3270) Hotrod clients removeWithVersion doesn't work with replicated cache
by Jakub Markos (JIRA)
[ https://issues.jboss.org/browse/ISPN-3270?page=com.atlassian.jira.plugin.... ]
Jakub Markos updated ISPN-3270:
-------------------------------
Attachment: server-trace-logs.zip
I've tried this for 6.2.0.ER1, and the command sometimes fails (I couldn't reproduce the case where it returns true but the entry is still available). Trace logs where the command fails attached.
> Hotrod clients removeWithVersion doesn't work with replicated cache
> -------------------------------------------------------------------
>
> Key: ISPN-3270
> URL: https://issues.jboss.org/browse/ISPN-3270
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Reporter: Jakub Markos
> Assignee: Mircea Markus
> Fix For: 6.0.0.CR1
>
> Attachments: server-trace-logs.zip
>
>
> I have a cluster of 2 latest infinispan servers (6.0.0-SNAPSHOT) with the following container configuration:
> {code:xml}<cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <replicated-cache name="default" start="EAGER" mode="SYNC" batching="false" remote-timeout="60000">
> <transaction mode="NONE"/>
> <state-transfer enabled="true" timeout="60000"/>
> </replicated-cache>
> </cache-container>
> {code}
> Running this code:
> {code} remoteCache = remoteCacheManager.getCache();
> remoteCache.clear();
> assertFalse(remoteCache.removeWithVersion("aKey", 12321212l));
> remoteCache.put("aKey", "aValue");
> VersionedValue valueBinary = remoteCache.getVersioned("aKey");
> System.out.println("value = " + valueBinary.getValue());
> System.out.println("version = " + valueBinary.getVersion());
> System.out.println(remoteCache.removeWithVersion("aKey",valueBinary.getVersion()));
> valueBinary = remoteCache.getVersioned("aKey");
> System.out.println("value = " + valueBinary.getValue());
> System.out.println("version = " + valueBinary.getVersion());
> {code}
> results most of the time in (and the other times the removeWithVersion returns false)
> {quote}
> value = aValue
> version = 281483566645249
> true
> value = aValue
> version = 281483566645249
> {quote}
> The command works with distributed/local cache.
--
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
11 years, 3 months