[JBoss JIRA] (ISPN-3722) State transfer must be enabled for Lucene Directory if clustered caches are used
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3722?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3722:
--------------------------------
Labels: 630 (was: )
> State transfer must be enabled for Lucene Directory if clustered caches are used
> --------------------------------------------------------------------------------
>
> Key: ISPN-3722
> URL: https://issues.jboss.org/browse/ISPN-3722
> Project: Infinispan
…
[View More]> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1
>
>
> take a look at the following code:
> {code:java}
> public Set<String> getFileList() {
> Set<String> fileList = (Set<String>) cache.get(fileListCacheKey);
> if (fileList == null) {
> fileList = new ConcurrentHashSet<String>();
> Set<String> prev = (Set<String>) cache.putIfAbsent(fileListCacheKey, fileList);
> if ( prev != null ) {
> fileList = prev;
> }
> }
> return fileList;
> }
> {code}
> when it requests the file list, the joiner does not have the data locally and it tries to do a putIfAbsent with an empty set. However, when it reaches the primary owner (if not changed), it will return the current file list.
> After, it tries to read the files returned in the set and it cannot find it, throwing an IOException -- "Read past EOF"
> A validation should be made in order to not allow clustered caches without state transfer.
--
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
[View Less]
10 years, 11 months
[JBoss JIRA] (ISPN-3724) REST RollUps -- Unsupported protocol version 60 throws annoying ERROR and WARN
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3724?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3724:
--------------------------------
Labels: 620 630 (was: 620)
> REST RollUps -- Unsupported protocol version 60 throws annoying ERROR and WARN
> ------------------------------------------------------------------------------
>
> Key: ISPN-3724
> URL: https://issues.jboss.org/browse/ISPN-3724
> Project: …
[View More]Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1
>
> Attachments: restRollups6dot0to6dot0tryingToGetHRkey, RestRollUpsUnsupportedProtocol60
>
>
> Trying to process REST rolling upgrades using latest infinispan server 6.0.0 snapshot as a TARGET node and the same server as a source node.
> Run Infinispan-server testsuite test for REST Rolling Upgrades.
> mvn clean verify -P suite.examples -Dtest=ExampleConfigsTest#testRestRollingUpgrades -DfailIfNoTests=false
> See new attached file with current stacktrace. REST rolling upgrades from 5.2.x to 6.0 will probably _not_ be supported.
--
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
[View Less]
10 years, 11 months
[JBoss JIRA] (ISPN-3712) HotRod Rolling Upgrades from Delirium 5.2.4 to latest server needs dropped org.infinispan.util.ByteArrayKey
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3712?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3712:
--------------------------------
Labels: 620 630 (was: 620)
> HotRod Rolling Upgrades from Delirium 5.2.4 to latest server needs dropped org.infinispan.util.ByteArrayKey
> -----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3712
> URL: https://issues.…
[View More]jboss.org/browse/ISPN-3712
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Environment: Processing HotRod rolling upgrades from source Infinispan 'Delirium' 5.2.4.Final-redhat-1 server to the latest Infinispan 'Infinium' 6.0.0-SNAPSHOT. Using old standalone.xml for source node and examples/standalone-hotrod-rolling-upgrade.xml for new target server.
> Reporter: Tomas Sykora
> Assignee: Tristan Tarrant
> Labels: 620, 630
> Fix For: 6.0.0.Final, 7.0.0.Alpha1
>
>
> When it is running from 6.0.0-SNAPSHOT to 6.0.0-SNAPSHOT it is ok. It looks like some back-porting compatibility issue.
> See stacktrace:
> javax.management.MBeanException
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:273)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:915)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271)
> ... 9 more
> Caused by: org.infinispan.commons.CacheException: java.lang.ClassNotFoundException: org.infinispan.util.ByteArrayKey from [Module "org.infinispan:main" from local module loader @4099a992 (finder: local module finder @284bd160 (roots: /home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules,/home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules/system/layers/base))]
> at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.synchronizeData(HotRodTargetMigrator.java:63)
> at org.infinispan.upgrade.RollingUpgradeManager.synchronizeData(RollingUpgradeManager.java:59)
> ... 14 more
> Caused by: java.lang.ClassNotFoundException: org.infinispan.util.ByteArrayKey from [Module "org.infinispan:main" from local module loader @4099a992 (finder: local module finder @284bd160 (roots: /home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules,/home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
> at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:777)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:656)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:140)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:118)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.synchronizeData(HotRodTargetMigrator.java:61)
> ... 15 more
--
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
[View Less]
10 years, 11 months
[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3704:
--------------------------------
Labels: 620 630 (was: 620)
> StateTransfer's PutKeyValueCommand may trigger remote get
> ---------------------------------------------------------
>
> Key: ISPN-3704
> URL: https://issues.jboss.org/browse/ISPN-3704
> Project: Infinispan
> Issue Type: Bug
> …
[View More] Components: Core
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620, 630
> Fix For: 7.0.0.Alpha1
>
>
> In TX mode with write skew check on, ST executing puts may trigger a remote get.
> The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from
> {code}
> if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> to
> {code}
> if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> EDIT:
> I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well.
--
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
[View Less]
10 years, 11 months
[JBoss JIRA] (ISPN-3659) Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3659?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3659:
--------------------------------
Labels: 620 630 (was: 620)
> Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches
> -------------------------------------------------------------------------------------
>
> Key: ISPN-3659
> URL: https://issues.jboss.org/browse/ISPN-3659
> …
[View More]Project: Infinispan
> Issue Type: Bug
> Components: Marshalling
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> The fix for ISPN-2372 was incomplete. We now clear the references from the thread-local marshallers to the cache itself, so it can be garbage-collected, but we don't clear the marshallers or their instance caches. If the cache values' object graph is very large, the cached marshallers will use up a lot of memory that could be garbage-collected (assuming the cache was indeed restarted and only one cache instance is running now).
--
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
[View Less]
10 years, 11 months
[JBoss JIRA] (ISPN-3670) Any commands received before the initial topology is installed should block
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3670?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3670:
--------------------------------
Labels: 630 (was: )
> Any commands received before the initial topology is installed should block
> ---------------------------------------------------------------------------
>
> Key: ISPN-3670
> URL: https://issues.jboss.org/browse/ISPN-3670
> Project: Infinispan
> …
[View More] Issue Type: Bug
> Components: State Transfer
> Affects Versions: 6.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1
>
>
> Because the initial cache topology is installed in a single phase, it's possible to receive a StateRequestCommand from another node before receiving the JOIN response from the coordinator and installing the initial cache topology. As such, commands received before we have a cache topology should block instead of being ignored.
> This bug is especially visible in the Map/Reduce tests (e.g. ReplicatedTwoNodesMapReduceTest) because the M/R task sends the CreateCacheCommand to the other nodes before it's executed on the originator. Since the originator happens to be the coordinator, it's possible for the coordinator to start the rebalance before the first member installed the initial topology.
--
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
[View Less]
10 years, 11 months
[JBoss JIRA] (ISPN-3376) CLI upgrade command does not work
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3376?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3376:
--------------------------------
Labels: 620 630 (was: 620)
> CLI upgrade command does not work
> ---------------------------------
>
> Key: ISPN-3376
> URL: https://issues.jboss.org/browse/ISPN-3376
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 6.…
[View More]0.0.Alpha1
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Labels: 620, 630
> Fix For: 7.0.0.Alpha1
>
> Attachments: logs.zip, standalone-hotrod-rolling-upgrade.xml
>
>
> Run my backup server with default standalone.xml configuration
> ./standalone.sh -c standalone.xml -Djboss.socket.binding.port-offset=111 -Djboss.node.name=BACKUPER
> Run my new server with
> ./standalone.sh -c standalone-hotrod-rolling-upgrade.xml -Djboss.node.name=UPGRADER
> 1) run command on BACKUPER
> [remoting://localhost:10110/local/default]> upgrade --dumpkeys default
> ISPN019502: Dumped keys for cache default
> 2) run command on UPGRADER
> [remoting://localhost:9999/local/default]> upgrade --synchronize=hotrod default
> ISPN019026: An error occurred while synchronizing data for cache 'hotrod' using migrator 'default' from the source server
--
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
[View Less]
10 years, 11 months
[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3422:
--------------------------------
Labels: 620 630 nbst (was: 620 nbst)
> In non-tx caches, write operations may not be atomic during rebalance
> ---------------------------------------------------------------------
>
> Key: ISPN-3422
> URL: https://issues.jboss.org/browse/ISPN-3422
> Project: Infinispan
> …
[View More] Issue Type: Bug
> Components: State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620, 630, nbst
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But before we detect the topology change, one or more of the backup owners may have already applied the modification.
> Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. Obviously, the command is not retried if the first attempt is not successful, but scenarios like this are possible:
> {code}
> thread 1: putIfAbsent(k, v1) -> null
> thread 2: putIfAbsent(k, v2) -> null
> {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
[View Less]
10 years, 11 months