[JBoss JIRA] (ISPN-2756) Enabling/disabling RpcManager statistics via JMX doesn't work
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2756?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2756:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1614
> Enabling/disabling RpcManager statistics via JMX doesn't work
> -------------------------------------------------------------
>
> Key: ISPN-2756
> URL: https://issues.jboss.org/browse/ISPN-2756
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 5.2.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.2.0.Final
>
>
> The test RpcManagerMBeanTest.testEnableJmxStats tries to write to the "StatisticsEnabled" attribute but fails. The operation doesn't throw an exception, but it does log this WARN message:
> {noformat}
> 10:43:42,079 WARN (testng-RpcManagerMBeanTest:) [ResourceDMBean] ISPN000043: Exception while writing value for attribute statisticsEnabled
> java.lang.NullPointerException
> at org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:391)
> at org.infinispan.jmx.ResourceDMBean.setNamedAttribute(ResourceDMBean.java:325)
> at org.infinispan.jmx.ResourceDMBean.setAttribute(ResourceDMBean.java:212)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.setAttribute(DefaultMBeanServerInterceptor.java:746)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.setAttribute(JmxMBeanServer.java:729)
> at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:134)
> {noformat}
> Because statistics are still enabled, the test then fails with an assertion error:
> {noformat}
> 10:43:42,464 ERROR (testng-RpcManagerMBeanTest:) [UnitTestTestNGListener] Test testEnableJmxStats(org.infinispan.jmx.RpcManagerMBeanTest) failed.
> java.lang.AssertionError: expected [-1] but found [1]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:165)
> at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:138)
> {noformat}
--
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, 11 months
[JBoss JIRA] (ISPN-2760) JGroups ClassCastException joining node in dist mode
by Christopher Wong (JIRA)
[ https://issues.jboss.org/browse/ISPN-2760?page=com.atlassian.jira.plugin.... ]
Christopher Wong closed ISPN-2760.
----------------------------------
Resolution: Cannot Reproduce Bug
User error: the second node was running the wrong version of Infinispan.
> JGroups ClassCastException joining node in dist mode
> ----------------------------------------------------
>
> Key: ISPN-2760
> URL: https://issues.jboss.org/browse/ISPN-2760
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.0.CR3
> Reporter: Christopher Wong
> Assignee: Mircea Markus
> Attachments: infinispan.cfg.xml
>
>
> I'm seeing exceptions in my application when I try to start a second node to join the cluster. The cache is for the Lucene directory hooked up under Hibernate Search. These errors did not occur under 5.2.0.CR1, 5.2.0.CR2 nor Galder's build that fixes ISPN-2723 (https://github.com/galderz/infinispan/tree/t_2723). The first node has these exceptions:
> 01-25-2013 13:51:40 WARN MPING protocols.MPING: group_addr (HibernateSearch-Infinispan-cluster-MT) or cluster_name of header (null) is null; passing up discovery request from 41089a5d-fe86-4679-6606-428ad1781501, but this should not be the case
> 01-25-2013 13:51:40 ERROR MPING protocols.MPING: failed receiving packet (from /127.0.0.1:46655)
> java.lang.ClassCastException: org.jgroups.protocols.relay.SiteUUID cannot be cast to org.jgroups.PhysicalAddress
> at org.jgroups.protocols.Discovery.up(Discovery.java:391)
> at org.jgroups.protocols.MPING.up(MPING.java:179)
> at org.jgroups.protocols.MPING.run(MPING.java:330)
> at java.lang.Thread.run(Thread.java:662)
> The joining node has these exceptions:
> 01-25-2013 13:52:02 ERROR MPING : failed receiving packet (from /127.0.0.1:46655)
> java.lang.RuntimeException: class for magic number 1151 not found
> at org.jgroups.util.Util.readOtherAddress(Util.java:849)
> at org.jgroups.util.Util.readAddress(Util.java:813)
> at org.jgroups.util.Util.readAddresses(Util.java:898)
> at org.jgroups.protocols.PingData.readFrom(PingData.java:162)
> at org.jgroups.util.Util.readStreamable(Util.java:938)
> at org.jgroups.protocols.PingHeader.readFrom(PingHeader.java:88)
> at org.jgroups.Message.readHeader(Message.java:902)
> at org.jgroups.Message.readFrom(Message.java:785)
> at org.jgroups.protocols.MPING.run(MPING.java:329)
> at java.lang.Thread.run(Thread.java:662)
--
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, 11 months
[JBoss JIRA] (ISPN-2762) Add version information to infinispan-core JAR file
by Alan Field (JIRA)
Alan Field created ISPN-2762:
--------------------------------
Summary: Add version information to infinispan-core JAR file
Key: ISPN-2762
URL: https://issues.jboss.org/browse/ISPN-2762
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Affects Versions: 5.2.0.CR3
Reporter: Alan Field
Assignee: Mircea Markus
Infinispan version information is logged when a cache is created, but it would be useful to have this information included in the infinispan-core JAR file. I discovered this when I was building and packaging RadarGun and wanted to know which version of Infinispan 5.2 was included. Currently no version information is included in the JAR file.
The version information for a SNAPSHOT build could include the build date and a git hash, along with the version string.
--
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, 11 months
[JBoss JIRA] (ISPN-2759) RHQ plugin + JON, problems with invoking operations on cache / cache manager
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2759?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2759:
------------------------------------
The RHQ plugin could really use some tests to smoke out this kind of problems. I've created ISPN-2761 to track that.
> RHQ plugin + JON, problems with invoking operations on cache / cache manager
> ----------------------------------------------------------------------------
>
> Key: ISPN-2759
> URL: https://issues.jboss.org/browse/ISPN-2759
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 5.2.0.CR3
> Environment: Fresh installation of JON 3.1.2.GA + community RHQ plugin for library mode + community distribution server built from upstream (already containing: https://github.com/infinispan/infinispan/pull/1595). This bug was experienced before this PR already.
> Reporter: Tomas Sykora
> Assignee: Tristan Tarrant
> Fix For: 5.2.0.Final
>
>
> In JON we can see changing statistics for caches without any problems. Monitoring looks to be ok.
> Problems occurred while issuing any operation.
> For example:
> *start cache issued on DefaultCacheManager (JON's popup exception window output):*
> java.lang.NullPointerException
> at org.rhq.plugins.jmx.MBeanResourceComponent.loadBean(MBeanResourceComponent.java:175)
> at org.rhq.plugins.jmx.MBeanResourceComponent.getEmsBean(MBeanResourceComponent.java:137)
> at org.rhq.plugins.jmx.MBeanResourceComponent.invokeOperation(MBeanResourceComponent.java:524)
> 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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634)
> 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)
> *stop cache issued on cache*
> java.lang.NullPointerException
> at org.infinispan.rhq.CacheComponent.invokeOperation(CacheComponent.java:190)
> 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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634)
> 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)
> *ISPN console with trace logging enabled says:*
> 2013-01-25 15:24:27,351 DEBUG [CacheImpl] (RMI TCP Connection(8)-127.0.0.1) Stopping cache ___defaultcache on null
> 2013-01-25 15:24:27,357 DEBUG [TransactionTable] (RMI TCP Connection(8)-127.0.0.1) Wait for on-going transactions to finish for 30 seconds.
> 2013-01-25 15:24:27,357 DEBUG [TransactionTable] (RMI TCP Connection(8)-127.0.0.1) All transactions terminated
> Other operations seem to be unavailable 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
11 years, 11 months
[JBoss JIRA] (ISPN-2761) Write tests for the RHQ plugin
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2761:
----------------------------------
Summary: Write tests for the RHQ plugin
Key: ISPN-2761
URL: https://issues.jboss.org/browse/ISPN-2761
Project: Infinispan
Issue Type: Task
Components: JMX, reporting and management
Affects Versions: 5.2.0.CR3
Reporter: Dan Berindei
Assignee: Mircea Markus
Fix For: 6.0.0.Final
The RHQ plugin doesn't have any functional tests at the moment. The InfinispanRhqTest class just starts a cache manager and waits for someone to start RHQ manually and connect to it.
Instead we should have a test that creates a {{CacheComponent}} instance and invokes several operations on it, reads attributes etc.
--
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, 11 months
[JBoss JIRA] (ISPN-2760) JGroups ClassCastException joining node in dist mode
by Christopher Wong (JIRA)
[ https://issues.jboss.org/browse/ISPN-2760?page=com.atlassian.jira.plugin.... ]
Christopher Wong updated ISPN-2760:
-----------------------------------
Issue Type: Bug (was: Feature Request)
> JGroups ClassCastException joining node in dist mode
> ----------------------------------------------------
>
> Key: ISPN-2760
> URL: https://issues.jboss.org/browse/ISPN-2760
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.0.CR3
> Reporter: Christopher Wong
> Assignee: Mircea Markus
> Attachments: infinispan.cfg.xml
>
>
> I'm seeing exceptions in my application when I try to start a second node to join the cluster. The cache is for the Lucene directory hooked up under Hibernate Search. These errors did not occur under 5.2.0.CR1, 5.2.0.CR2 nor Galder's build that fixes ISPN-2723 (https://github.com/galderz/infinispan/tree/t_2723). The first node has these exceptions:
> 01-25-2013 13:51:40 WARN MPING protocols.MPING: group_addr (HibernateSearch-Infinispan-cluster-MT) or cluster_name of header (null) is null; passing up discovery request from 41089a5d-fe86-4679-6606-428ad1781501, but this should not be the case
> 01-25-2013 13:51:40 ERROR MPING protocols.MPING: failed receiving packet (from /127.0.0.1:46655)
> java.lang.ClassCastException: org.jgroups.protocols.relay.SiteUUID cannot be cast to org.jgroups.PhysicalAddress
> at org.jgroups.protocols.Discovery.up(Discovery.java:391)
> at org.jgroups.protocols.MPING.up(MPING.java:179)
> at org.jgroups.protocols.MPING.run(MPING.java:330)
> at java.lang.Thread.run(Thread.java:662)
> The joining node has these exceptions:
> 01-25-2013 13:52:02 ERROR MPING : failed receiving packet (from /127.0.0.1:46655)
> java.lang.RuntimeException: class for magic number 1151 not found
> at org.jgroups.util.Util.readOtherAddress(Util.java:849)
> at org.jgroups.util.Util.readAddress(Util.java:813)
> at org.jgroups.util.Util.readAddresses(Util.java:898)
> at org.jgroups.protocols.PingData.readFrom(PingData.java:162)
> at org.jgroups.util.Util.readStreamable(Util.java:938)
> at org.jgroups.protocols.PingHeader.readFrom(PingHeader.java:88)
> at org.jgroups.Message.readHeader(Message.java:902)
> at org.jgroups.Message.readFrom(Message.java:785)
> at org.jgroups.protocols.MPING.run(MPING.java:329)
> at java.lang.Thread.run(Thread.java:662)
--
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, 11 months
[JBoss JIRA] (ISPN-2760) JGroups ClassCastException joining node in dist mode
by Christopher Wong (JIRA)
[ https://issues.jboss.org/browse/ISPN-2760?page=com.atlassian.jira.plugin.... ]
Christopher Wong updated ISPN-2760:
-----------------------------------
Attachment: infinispan.cfg.xml
Attaching my Infinispan config file
> JGroups ClassCastException joining node in dist mode
> ----------------------------------------------------
>
> Key: ISPN-2760
> URL: https://issues.jboss.org/browse/ISPN-2760
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Affects Versions: 5.2.0.CR3
> Reporter: Christopher Wong
> Assignee: Mircea Markus
> Attachments: infinispan.cfg.xml
>
>
> I'm seeing exceptions in my application when I try to start a second node to join the cluster. The cache is for the Lucene directory hooked up under Hibernate Search. These errors did not occur under 5.2.0.CR1, 5.2.0.CR2 nor Galder's build that fixes ISPN-2723 (https://github.com/galderz/infinispan/tree/t_2723). The first node has these exceptions:
> 01-25-2013 13:51:40 WARN MPING protocols.MPING: group_addr (HibernateSearch-Infinispan-cluster-MT) or cluster_name of header (null) is null; passing up discovery request from 41089a5d-fe86-4679-6606-428ad1781501, but this should not be the case
> 01-25-2013 13:51:40 ERROR MPING protocols.MPING: failed receiving packet (from /127.0.0.1:46655)
> java.lang.ClassCastException: org.jgroups.protocols.relay.SiteUUID cannot be cast to org.jgroups.PhysicalAddress
> at org.jgroups.protocols.Discovery.up(Discovery.java:391)
> at org.jgroups.protocols.MPING.up(MPING.java:179)
> at org.jgroups.protocols.MPING.run(MPING.java:330)
> at java.lang.Thread.run(Thread.java:662)
> The joining node has these exceptions:
> 01-25-2013 13:52:02 ERROR MPING : failed receiving packet (from /127.0.0.1:46655)
> java.lang.RuntimeException: class for magic number 1151 not found
> at org.jgroups.util.Util.readOtherAddress(Util.java:849)
> at org.jgroups.util.Util.readAddress(Util.java:813)
> at org.jgroups.util.Util.readAddresses(Util.java:898)
> at org.jgroups.protocols.PingData.readFrom(PingData.java:162)
> at org.jgroups.util.Util.readStreamable(Util.java:938)
> at org.jgroups.protocols.PingHeader.readFrom(PingHeader.java:88)
> at org.jgroups.Message.readHeader(Message.java:902)
> at org.jgroups.Message.readFrom(Message.java:785)
> at org.jgroups.protocols.MPING.run(MPING.java:329)
> at java.lang.Thread.run(Thread.java:662)
--
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, 11 months
[JBoss JIRA] (ISPN-2760) JGroups ClassCastException joining node in dist mode
by Christopher Wong (JIRA)
Christopher Wong created ISPN-2760:
--------------------------------------
Summary: JGroups ClassCastException joining node in dist mode
Key: ISPN-2760
URL: https://issues.jboss.org/browse/ISPN-2760
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache
Affects Versions: 5.2.0.CR3
Reporter: Christopher Wong
Assignee: Mircea Markus
I'm seeing exceptions in my application when I try to start a second node to join the cluster. The cache is for the Lucene directory hooked up under Hibernate Search. These errors did not occur under 5.2.0.CR1, 5.2.0.CR2 nor Galder's build that fixes ISPN-2723 (https://github.com/galderz/infinispan/tree/t_2723). The first node has these exceptions:
01-25-2013 13:51:40 WARN MPING protocols.MPING: group_addr (HibernateSearch-Infinispan-cluster-MT) or cluster_name of header (null) is null; passing up discovery request from 41089a5d-fe86-4679-6606-428ad1781501, but this should not be the case
01-25-2013 13:51:40 ERROR MPING protocols.MPING: failed receiving packet (from /127.0.0.1:46655)
java.lang.ClassCastException: org.jgroups.protocols.relay.SiteUUID cannot be cast to org.jgroups.PhysicalAddress
at org.jgroups.protocols.Discovery.up(Discovery.java:391)
at org.jgroups.protocols.MPING.up(MPING.java:179)
at org.jgroups.protocols.MPING.run(MPING.java:330)
at java.lang.Thread.run(Thread.java:662)
The joining node has these exceptions:
01-25-2013 13:52:02 ERROR MPING : failed receiving packet (from /127.0.0.1:46655)
java.lang.RuntimeException: class for magic number 1151 not found
at org.jgroups.util.Util.readOtherAddress(Util.java:849)
at org.jgroups.util.Util.readAddress(Util.java:813)
at org.jgroups.util.Util.readAddresses(Util.java:898)
at org.jgroups.protocols.PingData.readFrom(PingData.java:162)
at org.jgroups.util.Util.readStreamable(Util.java:938)
at org.jgroups.protocols.PingHeader.readFrom(PingHeader.java:88)
at org.jgroups.Message.readHeader(Message.java:902)
at org.jgroups.Message.readFrom(Message.java:785)
at org.jgroups.protocols.MPING.run(MPING.java:329)
at java.lang.Thread.run(Thread.java:662)
--
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, 11 months
[JBoss JIRA] (ISPN-2712) Initial state transfer doesn't appear to all be persisted when using eviction in a replicated cluster
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2712?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2712 started by Adrian Nistor.
> 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: Adrian Nistor
> 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, 11 months
[JBoss JIRA] (ISPN-2712) Initial state transfer doesn't appear to all be persisted when using eviction in a replicated cluster
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2712?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2712:
-------------------------------------
I've just created a test using your config and can confirm that your scenario works in 5.1.x and fails in 5.2: https://github.com/anistor/infinispan/commit/b9351b50ec7b33678d01c71b888c...
It seems that the issue is in the area of eviction and cache loaders.
> 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: Adrian Nistor
> 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, 11 months