[JBoss JIRA] (ISPN-2697) HotRodServer startup fails when its record cannot be inserted into topology cache
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/ISPN-2697?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on ISPN-2697:
--------------------------------
Radim,
the time-based gossip interval is:
{code}
long computeSleepTime() {
return getRandom((mbrs.size() * desired_avg_gossip * 2));
}
long getRandom(long range) {
return (long)((Math.random() * range) % range);
}
{code}
There's also a size based stability, which triggers when a certain number of bytes have been received. The time interval is quite high because we don't want too much traffic from STABLE, and if there's a lot of traffic, the size-based trigger will do the job.
> HotRodServer startup fails when its record cannot be inserted into topology cache
> ---------------------------------------------------------------------------------
>
> Key: ISPN-2697
> URL: https://issues.jboss.org/browse/ISPN-2697
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.0.Beta6
> Reporter: Radim Vansa
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 5.2.0.CR2
>
>
> When the HotRodServer starts it inserts its record to __hotRodTopologyCache ({{HotRodServer.addSelfToTopologyView(...)}}).
> However, this put may very easily fail - as the command is broadcasted using NAKACK2 protocol, if the message gets lost and there's no following broadcasted message, the message will be not retransmitted and the put operation times out (Replication timeout), which fails the whole HotRodServer startup, all because of one lost UDP message.
--
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
13 years, 3 months
[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1583?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-1583:
----------------------------------------
Sorry for closing it too early. I've got a couple of tests for this now. It should be fixed pretty quickly now. Apologies for the inconvenience and thx for the extra info.
> AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
> -------------------------------------------------------------------------------------
>
> Key: ISPN-1583
> URL: https://issues.jboss.org/browse/ISPN-1583
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.1.0.BETA5
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Fix For: 5.2.0.CR2, 5.2.0.Final
>
>
> When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke.
> Take the following code:
> AdvancedCache<K, V> baseCache;
> AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) {
> public void clear() {
> // custom clear logic
> }
> };
> customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear();
> In the above statement, the flag is not applied.
> The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection.
> In the case of with(ClassLoader) we have the opposite problem.
> customCache.with(customClassLoader).clear();
> In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache. The clear() method then operates on baseCache, instead of customCache.
--
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
13 years, 3 months
[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1583?page=com.atlassian.jira.plugin.... ]
Work on ISPN-1583 started by Galder Zamarreño.
> AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
> -------------------------------------------------------------------------------------
>
> Key: ISPN-1583
> URL: https://issues.jboss.org/browse/ISPN-1583
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.1.0.BETA5
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Fix For: 5.2.0.CR2, 5.2.0.Final
>
>
> When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke.
> Take the following code:
> AdvancedCache<K, V> baseCache;
> AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) {
> public void clear() {
> // custom clear logic
> }
> };
> customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear();
> In the above statement, the flag is not applied.
> The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection.
> In the case of with(ClassLoader) we have the opposite problem.
> customCache.with(customClassLoader).clear();
> In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache. The clear() method then operates on baseCache, instead of customCache.
--
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
13 years, 3 months
[JBoss JIRA] (ISPN-2619) DistSyncCacheStoreNotSharedTest fails randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2619?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2619:
--------------------------------
Fix Version/s: 5.2.0.Final
> DistSyncCacheStoreNotSharedTest fails randomly
> ----------------------------------------------
>
> Key: ISPN-2619
> URL: https://issues.jboss.org/browse/ISPN-2619
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 5.2.0.Beta5
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 5.2.0.Final
>
>
> DistSyncCacheStoreNotSharedTest fails (pretty rarely) with this exception:
> {noformat}
> 09:29:51,069 ERROR (testng-DistSyncCacheStoreNotSharedTest:) [UnitTestTestNGListener] Test testAtomicPutIfAbsentFromNonOwner(org.infinispan.distribution.DistSyncCacheStoreNotSharedTest) failed.
> java.lang.AssertionError
> at org.infinispan.distribution.DistSyncCacheStoreNotSharedTest.testAtomicPutIfAbsentFromNonOwner(DistSyncCacheStoreNotSharedTest.java:293)
> {noformat}
> What happens is that at the end of the previous test there is a get() that goes remotely, and one of the ClusteredGetCommands (to node C) is delayed. The test framework then clears the cache store and the data container on node C, but the get command already had the entry in its context and will write it to the data container when it finishes executing, so that the data container is not empty when testAtomicPutIfAbsentFromNonOwner starts.
> {noformat}
> 09:29:51,033 TRACE (OOB-1,ISPN,NodeC-33167:) [CommandAwareRpcDispatcher] Attempting to execute command: ClusteredGetCommand{key=k2, flags=null} [sender=NodeB-52644]
> 09:29:51,062 TRACE (testng-DistSyncCacheStoreNotSharedTest:) [DummyInMemoryCacheStore] Clear store
> 09:29:51,062 DEBUG (testng-DistSyncCacheStoreNotSharedTest:) [TestingUtil] Cleaning data for cache 'dist' on a cache manager at address NodeC-33167
> 09:29:51,065 DEBUG (testng-DistSyncCacheStoreNotSharedTest:) [TestingUtil] removeInMemoryData(): dataContainerBefore == []
> 09:29:51,062 TRACE (OOB-1,ISPN,NodeC-33167:dist) [ReadCommittedEntry] Updating entry (key=k2 removed=false valid=true changed=true created=false value=value2]
> 09:29:51,065 TRACE (OOB-1,ISPN,NodeC-33167:dist) [EntryWrappingInterceptor] Committed entry ReadCommittedEntry(64d90a46){key=k2, value=value2, oldValue=null, isCreated=false, isChanged=false, isRemoved=false, isValid=true}
> 09:29:51,065 DEBUG (testng-DistSyncCacheStoreNotSharedTest:) [TestingUtil] removeInMemoryData(): dataContainerAfter == []
> {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
13 years, 3 months
[JBoss JIRA] (ISPN-2625) Verify Cross-site transfer performace
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-2625?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-2625:
-----------------------------------
We have been looking on that with Bela Ban and found out that our lab has pretty long ping latency which causes a difference in Bela's IspnPerfTest. However, the READ performance dropdown with ASYNC XS replication (compared to SYNC or no-xs one) was not properly explained.
> Verify Cross-site transfer performace
> -------------------------------------
>
> Key: ISPN-2625
> URL: https://issues.jboss.org/browse/ISPN-2625
> Project: Infinispan
> Issue Type: Task
> Components: Cross-Site Replication
> Affects Versions: 5.2.0.Beta5
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Attachments: jgroups-lon-nyc-sfo-belaban.xml, jgroups-site.xml, lon-tx-optimistic-xs-to-nyc-async.xml, nyc-tx-optimistic-xs-from-lon.xml
>
>
> The performance of asynchronous cross-site transfer is questionable. In QA lab we got 2x-4x slower reads (GET) than in no-XS scenario and write (PUT) performance equivalent to those of synchronous XS. While the code cannot be reliably profiled with instrumentation, trace logs also radically slow down the test we have not identified any particular bug that should cause this issue.
> Therefore, I'd like to ask someone from the core developers to try to reproduce such test results and provide his test description together with achieved results.
> We have used three-node cluster in distributed mode with optimistic transactions, replicating to another three-node cluster with the same configuration. Physically the nodes were in the same cluster without any delay element. The logical clusters used different multicast addresses in their JGroups configuration.
> Each node started 10 threads which issued PUT/GET requests in a loop with 1:4 ratio. Each request was wrapped in single transaction. The test was benchmarking the average duration of each operation during 10 minute period preceded by 3 minute warmup with identical configuration but not accounted into performance results.
> JGroups configurations as well as Infinispan configuration will be enclosed.
--
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
13 years, 3 months
[JBoss JIRA] (ISPN-2627) Fail to build minimal-distribution at RhqPluginXmlGenerator
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2627?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-2627.
---------------------------------
Resolution: Duplicate Issue
fixed as part of ISPN-2628
> Fail to build minimal-distribution at RhqPluginXmlGenerator
> -----------------------------------------------------------
>
> Key: ISPN-2627
> URL: https://issues.jboss.org/browse/ISPN-2627
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 5.2.0.Beta5
> Reporter: Thomas Fromm
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Final
>
>
> mvn clean package -Dmaven.test.skip.exec=true -Pminimal-distribution
> I'm struggeling building minimal distribution always here:
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (default) on project infinispan-rhq-plugin: An error has occurred in JavaDocs report generation:
> [ERROR] Exit code: 1 - log4j:WARN No appenders could be found for logger (org.jboss.logging).
> [ERROR] log4j:WARN Please initialize the log4j system properly.
> [ERROR] log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
> [ERROR] javadoc: error - In doclet class org.infinispan.tools.rhq.RhqPluginXmlGenerator, method start has thrown an exception java.lang.reflect.InvocationTargetException
> [ERROR] java.lang.RuntimeException: Display name too long (max 100 chars): [Activation] Disable all cache loaders of a given type, where type is a fully qualified class name of the cache loader to disable
> [ERROR] at org.infinispan.tools.rhq.RhqPluginXmlGenerator.validateDisplayName(RhqPluginXmlGenerator.java:324)
> [ERROR] at org.infinispan.tools.rhq.RhqPluginXmlGenerator.populateMetricsAndOperations(RhqPluginXmlGenerator.java:244)
> [ERROR] at org.infinispan.tools.rhq.RhqPluginXmlGenerator.start(RhqPluginXmlGenerator.java:144)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:601)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:280)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:160)
> [ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:397)
> [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:167)
> [ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:59)
> [ERROR] at com.sun.tools.javadoc.Main.main(Main.java:49)
--
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
13 years, 3 months
[JBoss JIRA] (ISPN-2623) SimpleEvictionMaxEntries fails consistently on IBM JDK with "cache size too big: 182"
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2623?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2623:
--------------------------------
Assignee: Tristan Tarrant (was: Mircea Markus)
> SimpleEvictionMaxEntries fails consistently on IBM JDK with "cache size too big: 182"
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2623
> URL: https://issues.jboss.org/browse/ISPN-2623
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction, Test Suite
> Affects Versions: 5.1.8.Final
> Environment: IBM JDK6, IBM JDK7, any platfrom
> Reporter: Jitka Kudrnacova
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Final
>
>
> Test SimpleEvictionMaxEntries fails consistently across platforms with the following (output from RHEL6_x86_64):
> {code}
> 2012-12-05 10:53:13,616 ERROR [UnitTestTestNGListener] (testng-LRUEvictionFunctionalTest) Method testSimpleEvictionMaxEntries(org.infinispan.eviction.LRUEvictionFunctionalTest) threw an exception
> java.lang.AssertionError: cache size too big: 182
> at org.infinispan.eviction.BaseEvictionFunctionalTest.testSimpleEvictionMaxEntries(BaseEvictionFunctionalTest.java:67)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:613)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
> at org.testng.TestRunner.privateRun(TestRunner.java:749)
> at org.testng.TestRunner.run(TestRunner.java:600)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
> at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
> at java.lang.Thread.run(Thread.java:780)
> [testng-LRUEvictionFunctionalTest] Test testSimpleEvictionMaxEntries(org.infinispan.eviction.LRUEvictionFunctionalTest) failed.
> {code}
> Seen during TS runs for test cycle EAP 6.0.1.ER4.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
13 years, 3 months