[JBoss JIRA] (ISPN-3737) L1 requestor registered after value read
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3737?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3737:
--------------------------------
Labels: 620 630 (was: 620)
> L1 requestor registered after value read
> ----------------------------------------
>
> Key: ISPN-3737
> URL: https://issues.jboss.org/browse/ISPN-3737
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> As the L1 requestor is registered only after the value is retrieved from data container, the (transactional) update of the value may not invalide the entry after write and the cache gets inconsistent.
> Consider this interleaving of operations (G=get request from other node, C=commit)
> R: read value -> old value
> C: update old -> new
> C: notify requestors for key
> R: add requestor for key
--
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
[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
> 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
12 years
[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: 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
12 years
[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.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
12 years
[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
> 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
12 years
[JBoss JIRA] (ISPN-3608) HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3608?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3608:
--------------------------------
Labels: 620 630 (was: 620)
> HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3608
> URL: https://issues.jboss.org/browse/ISPN-3608
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> HotRod client's RemoteCacheManager still has a constructor that internally reads hotrod-client.properties (public RemoteCacheManager(boolean start)) and this constructor is not deprecated.
> This call leads to parsing "server_list" property by ConfigurationBuilder.addServers(String servers)).
> However, IPv6 addresses usually contain colons and so this parsing fails (enable to differentiate the host and port as these are separated by colon too)
--
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
[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
> 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
12 years
[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
> 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
12 years
[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.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
12 years