[JBoss JIRA] (ISPN-2584) BackupReceiver survives cache shutdown
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2584?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2584:
-------------------------------------
Is this a duplicate of ISPN-2585 ?
> BackupReceiver survives cache shutdown
> --------------------------------------
>
> Key: ISPN-2584
> URL: https://issues.jboss.org/browse/ISPN-2584
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 5.2.0.Beta5
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Fix For: 5.2.0.Final
>
>
> When the cache manager is stopped together with all caches, the static field {{BackupReceiverRepositoryImpl.backupReceivers}} is not cleaned up. When another cache manager is started and we try to XS replicate into this node, the request reaches {{BackupReceiver}} with references to the old, stopped cache. This instance has TERMINATED ComponentRepository without {{TransactionTable}} and this results in {{NullPointerException}} in {{BackupCacheUpdater.replayModificationsInTransaction}}.
> When the cache is stopped, it should remove all references to it from the {{BackupReceiverRepositoryImpl.backupReceivers}}.
--
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, 12 months
[JBoss JIRA] (ISPN-871) Out-of-heap data container implementation
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-871?page=com.atlassian.jira.plugin.s... ]
Adrian Nistor commented on ISPN-871:
------------------------------------
+1. I have a hunch that a pure java solution based on nio buffers can perform better than a native implementation. Not sure how much context switching overhead is added by JNI of modern JVMs but a few years ago it was pretty slow (also depending on the number of method arguments). If you need lots of very granular JNI calls (and DataContainer interface is such a case) and the arguments/return value need complex marshalling (and memory copying) then this becomes relevant.
> Out-of-heap data container implementation
> -----------------------------------------
>
> Key: ISPN-871
> URL: https://issues.jboss.org/browse/ISPN-871
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Manik Surtani
> Assignee: Tristan Tarrant
> Labels: gc, jni, native, performance, research
> Fix For: 6.0.0.Final
>
>
> The {{DataContainer}} interface could be implemented using a off-heap impl in C, using a wrapper around [TBB|http://threadingbuildingblocks.org/]'s concurrent hashmap.
> Cheap and easy way, no memory management needed, at worst case same performance as the Java CHM-like impl of the data container + some JNI overhead. Potential benefit of large data heaps.
--
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, 12 months
[JBoss JIRA] (ISPN-2712) Initial state transfer doesn't appear to all be persisted when using eviction in a replicated cluster
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2712?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2712:
-----------------------------------
Fix Version/s: 5.2.0.Final
> Initial state transfer doesn't appear to all be persisted when using eviction in a replicated cluster
> ------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2712
> URL: https://issues.jboss.org/browse/ISPN-2712
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.CR1
> Reporter: Randall Hauch
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 5.2.0.Final
>
> Attachments: ispn_eviction_log.txt, spectrum-repository-infinispan.xml
>
>
> Using a clustered cache with 2 nodes, where the cache in each node is configured identically with replication, eviction and (non-shared) file cache store. (See attached configuration.)
> The first (coordinator) process in the cluster is started and populated with 293 entries. Then the first process continually adds a few entries every 5 seconds. After a short delay, the second process is started, at which point it joins the cluster and starts the state-transfer process; logging shows in the first process that all 293 entries are transferred to the new cluster member, and the second log shows that they are all received. The second process then attempts to look for a specific entry that was created during initial population in the first process. This fails to find the existing entry.
> By enabling trace logging and "IDE breakpoint output messages" around state transfer, it's visible that from the 293 keys, only 218 are placed into the cache, the others being lost.
> (This problem was originally discovered when clustering ModeShape, which behaves roughly in the manner described above. The initial entries that are populated upon initialization are content created when a new repository is started. The second process looks for this content, and if it finds the content it knows not to create all of this initial content. However, if it doesn't find it, it thinks the repository has not yet been initialized and that it should create the initial content. The problem described by this bug then manifests itself in ModeShape through dozens of exceptions because the repository has been corrupted. See MODE-1745 for details on this problem. ModeShape's corresponding known issue for this issue, ISPN-2712, is MODE-1754.)
> The eviction is configured like this:
> {code:xml}
> <eviction strategy="LIRS" maxEntries="1000"/>
> {code}
> The attached log file is from the second process (the "receiver" node) and it contains the following key points:
> * line 40 - the total number of keys & entries to be transferred = 293
> * line 1352 and from there onwards 1358 / 1364 / i + 6 - the data container's size stops growing at 218, while the other entries are being sent. This means that in effect, they are ignored.
> * line 1797 - the loop from {{org.infinispan.statetransfer.StateConsumerImpl#doApplyState}} finishes
> Disabling eviction fixes the problem and all 293 nodes are placed in Node2's cache.
> (I initially marked this as CRITICAL priority, though it is a blocker for our use of Infinispan 5.2.)
--
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, 12 months
[JBoss JIRA] (ISPN-2721) Issue with conditional operations and verisioning
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2721?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2721:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1579
> Issue with conditional operations and verisioning
> -------------------------------------------------
>
> Key: ISPN-2721
> URL: https://issues.jboss.org/browse/ISPN-2721
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Mircea Markus
> Assignee: Galder Zamarreño
> Fix For: 5.2.0.CR2
>
> Attachments: SimpleConditionalOperationsWriteSkewTest.java
>
>
> The problem:
> - repeatable read cache with write skew check enabled
> - a conditional operation (e.g. replace) executes and is not successful (e.g. because the value doesn't exist)
> - during the successful operation the entry is written to the container with a null version. (i.e. the previous version is erased). That is well bad!
> Suggested solution:
> - for such entries that were not modified (isChanged==false) the value should not be re-written to the container OR
> Attached is a unit test capturing the problem.
--
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, 12 months
[JBoss JIRA] (ISPN-2721) Issue with conditional operations and verisioning
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2721?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-2721:
----------------------------------------
I'm gonna add the test to the pull req and resubmit btw.
> Issue with conditional operations and verisioning
> -------------------------------------------------
>
> Key: ISPN-2721
> URL: https://issues.jboss.org/browse/ISPN-2721
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Mircea Markus
> Assignee: Galder Zamarreño
> Attachments: SimpleConditionalOperationsWriteSkewTest.java
>
>
> The problem:
> - repeatable read cache with write skew check enabled
> - a conditional operation (e.g. replace) executes and is not successful (e.g. because the value doesn't exist)
> - during the successful operation the entry is written to the container with a null version. (i.e. the previous version is erased). That is well bad!
> Suggested solution:
> - for such entries that were not modified (isChanged==false) the value should not be re-written to the container OR
> Attached is a unit test capturing the problem.
--
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, 12 months
[JBoss JIRA] (ISPN-2721) Issue with conditional operations and verisioning
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2721?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2721:
-----------------------------------
Fix Version/s: 5.2.0.CR2
> Issue with conditional operations and verisioning
> -------------------------------------------------
>
> Key: ISPN-2721
> URL: https://issues.jboss.org/browse/ISPN-2721
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Mircea Markus
> Assignee: Galder Zamarreño
> Fix For: 5.2.0.CR2
>
> Attachments: SimpleConditionalOperationsWriteSkewTest.java
>
>
> The problem:
> - repeatable read cache with write skew check enabled
> - a conditional operation (e.g. replace) executes and is not successful (e.g. because the value doesn't exist)
> - during the successful operation the entry is written to the container with a null version. (i.e. the previous version is erased). That is well bad!
> Suggested solution:
> - for such entries that were not modified (isChanged==false) the value should not be re-written to the container OR
> Attached is a unit test capturing the problem.
--
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, 12 months
[JBoss JIRA] (ISPN-2721) Issue with conditional operations and verisioning
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2721?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-2721:
----------------------------------------
@Mircea, test passes with my latest pull req for ISPN-2300.
> Issue with conditional operations and verisioning
> -------------------------------------------------
>
> Key: ISPN-2721
> URL: https://issues.jboss.org/browse/ISPN-2721
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Mircea Markus
> Assignee: Galder Zamarreño
> Attachments: SimpleConditionalOperationsWriteSkewTest.java
>
>
> The problem:
> - repeatable read cache with write skew check enabled
> - a conditional operation (e.g. replace) executes and is not successful (e.g. because the value doesn't exist)
> - during the successful operation the entry is written to the container with a null version. (i.e. the previous version is erased). That is well bad!
> Suggested solution:
> - for such entries that were not modified (isChanged==false) the value should not be re-written to the container OR
> Attached is a unit test capturing the problem.
--
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, 12 months
[JBoss JIRA] (ISPN-2642) IndexOutOfBoundsException in HotRodDecoder
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2642?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2642:
-----------------------------------------------
Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug 887323|https://bugzilla.redhat.com/show_bug.cgi?id=887323] from ON_QA to VERIFIED
> IndexOutOfBoundsException in HotRodDecoder
> ------------------------------------------
>
> Key: ISPN-2642
> URL: https://issues.jboss.org/browse/ISPN-2642
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.0.Beta5
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Fix For: 5.2.0.CR1, 5.2.0.Final
>
>
> In one of the elasticity tests in hyperion I'm getting:
> {code}
> 03:48:04,765 ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodClientMaster-179) ISPN005009: Unexpected error before any request parameters read: java.lang.IndexOutOfBoundsException: 2
> at scala.collection.mutable.ResizableArray$class.apply(ResizableArray.scala:44)
> at scala.collection.mutable.ArrayBuffer.apply(ArrayBuffer.scala:47)
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x$$anonfun$writeHashTopologyHeader$1$$anonfun$apply$mcVI$sp$1.apply$mcVI$sp(AbstractTopologyAwareEncoder1x.scala:99) [infinispan-server-hotrod-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:81)
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x$$anonfun$writeHashTopologyHeader$1.apply$mcVI$sp(AbstractTopologyAwareEncoder1x.scala:96) [infinispan-server-hotrod-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:78)
> at org.infinispan.server.hotrod.AbstractTopologyAwareEncoder1x.writeHashTopologyHeader(AbstractTopologyAwareEncoder1x.scala:93) [infinispan-server-hotrod-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at org.infinispan.server.hotrod.AbstractEncoder1x.writeHeader(AbstractEncoder1x.scala:62) [infinispan-server-hotrod-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:63) [infinispan-server-hotrod-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:67) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:60) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.channel.Channels.write(Channels.java:712) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.channel.Channels.write(Channels.java:679) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248) [netty-3.5.9.Final.jar:]
> at org.infinispan.server.core.AbstractProtocolDecoder.writeResponse(AbstractProtocolDecoder.scala:179) [infinispan-server-core-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeKey(AbstractProtocolDecoder.scala:115) [infinispan-server-core-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:71) [infinispan-server-core-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:47) [infinispan-server-core-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:502) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:437) [netty-3.5.9.Final.jar:]
> at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:387) [infinispan-server-core-5.2.0.Beta5-redhat-1.jar:5.2.0.Beta5-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:84) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:472) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:333) [netty-3.5.9.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35) [netty-3.5.9.Final.jar:]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> {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, 12 months