[JBoss JIRA] (ISPN-2703) The "machine" attribute of server hinting does not work
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-2703?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-2703:
-------------------------------------
Dan, let me describe the problem more thoroughly.
We are starting 3 servers but numOwners is still only 2. We expect that whenever we put certain key/value pair in the cache to node0 or node1, it will be replicated to node2 because it has different "machine" attribute (rack and site are the same for all 3 nodes).
The site/rack/machine attributes are configured in the following way:
node0:
site=primary
rack=primary
machine=primary
node1:
site=primary
rack=primary
machine=primary
node2:
site=primary
rack=primary
machine=secondary
The test we are running is located at https://svn.devel.redhat.com/repos/jboss-qa/jdg/jdg-functional-tests/trun...
After I added a little more logging to the test, I got the following:
Entry count - node0: 1 ,node1: 0, node2: 1
Entry count - node0: 2 ,node1: 0, node2: 2
Entry count - node0: 3 ,node1: 0, node2: 3
Entry count - node0: 4 ,node1: 0, node2: 4
Entry count - node0: 5 ,node1: 0, node2: 5
Entry count - node0: 6 ,node1: 0, node2: 6
Entry count - node0: 7 ,node1: 0, node2: 7
Entry count - node0: 8 ,node1: 0, node2: 8
Entry count - node0: 9 ,node1: 0, node2: 9
...still the same even with more iterations.
The same test already works correctly for both rack and machine attributes (I mean replicating to a different site/rack) and the output then looks like this:
Entry count - node0: 0 ,node1: 1, node2: 1
Entry count - node0: 0 ,node1: 2, node2: 2
Entry count - node0: 1 ,node1: 2, node2: 3
Entry count - node0: 1 ,node1: 3, node2: 4
Entry count - node0: 2 ,node1: 3, node2: 5
> The "machine" attribute of server hinting does not work
> -------------------------------------------------------
>
> Key: ISPN-2703
> URL: https://issues.jboss.org/browse/ISPN-2703
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta6
> Reporter: Martin Gencur
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.2.0.CR2
>
> Attachments: trace_log_machine_attribute_failing.txt
>
>
> The rack and site attributes already work correctly. I'm creating this one issue just for the remaining "machine" attribute.
> Will attach trace logs
--
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-2703) The "machine" attribute of server hinting does not work
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-2703?page=com.atlassian.jira.plugin.... ]
Martin Gencur edited comment on ISPN-2703 at 1/15/13 9:17 AM:
--------------------------------------------------------------
Dan, let me describe the problem more thoroughly.
We are starting 3 servers but numOwners is still only 2. We expect that whenever we put certain key/value pair in the cache to node0 or node1, it will be replicated to node2 because it has different "machine" attribute (rack and site are the same for all 3 nodes).
The site/rack/machine attributes are configured in the following way:
node0:
site=primary
rack=primary
machine=primary
node1:
site=primary
rack=primary
machine=primary
node2:
site=primary
rack=primary
machine=secondary
The test we are running is located at https://svn.devel.redhat.com/repos/jboss-qa/jdg/jdg-functional-tests/trun...
After I added a little more logging to the test, I got the following:
Entry count - node0: 1 ,node1: 0, node2: 1
Entry count - node0: 2 ,node1: 0, node2: 2
Entry count - node0: 3 ,node1: 0, node2: 3
Entry count - node0: 4 ,node1: 0, node2: 4
Entry count - node0: 5 ,node1: 0, node2: 5
Entry count - node0: 6 ,node1: 0, node2: 6
Entry count - node0: 7 ,node1: 0, node2: 7
Entry count - node0: 8 ,node1: 0, node2: 8
Entry count - node0: 9 ,node1: 0, node2: 9
...still the same even with more iterations.
The same test already works correctly for both rack and site attributes (I mean replicating to a different site/rack) and the output then looks like this:
Entry count - node0: 0 ,node1: 1, node2: 1
Entry count - node0: 0 ,node1: 2, node2: 2
Entry count - node0: 1 ,node1: 2, node2: 3
Entry count - node0: 1 ,node1: 3, node2: 4
Entry count - node0: 2 ,node1: 3, node2: 5
was (Author: mgencur):
Dan, let me describe the problem more thoroughly.
We are starting 3 servers but numOwners is still only 2. We expect that whenever we put certain key/value pair in the cache to node0 or node1, it will be replicated to node2 because it has different "machine" attribute (rack and site are the same for all 3 nodes).
The site/rack/machine attributes are configured in the following way:
node0:
site=primary
rack=primary
machine=primary
node1:
site=primary
rack=primary
machine=primary
node2:
site=primary
rack=primary
machine=secondary
The test we are running is located at https://svn.devel.redhat.com/repos/jboss-qa/jdg/jdg-functional-tests/trun...
After I added a little more logging to the test, I got the following:
Entry count - node0: 1 ,node1: 0, node2: 1
Entry count - node0: 2 ,node1: 0, node2: 2
Entry count - node0: 3 ,node1: 0, node2: 3
Entry count - node0: 4 ,node1: 0, node2: 4
Entry count - node0: 5 ,node1: 0, node2: 5
Entry count - node0: 6 ,node1: 0, node2: 6
Entry count - node0: 7 ,node1: 0, node2: 7
Entry count - node0: 8 ,node1: 0, node2: 8
Entry count - node0: 9 ,node1: 0, node2: 9
...still the same even with more iterations.
The same test already works correctly for both rack and machine attributes (I mean replicating to a different site/rack) and the output then looks like this:
Entry count - node0: 0 ,node1: 1, node2: 1
Entry count - node0: 0 ,node1: 2, node2: 2
Entry count - node0: 1 ,node1: 2, node2: 3
Entry count - node0: 1 ,node1: 3, node2: 4
Entry count - node0: 2 ,node1: 3, node2: 5
> The "machine" attribute of server hinting does not work
> -------------------------------------------------------
>
> Key: ISPN-2703
> URL: https://issues.jboss.org/browse/ISPN-2703
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta6
> Reporter: Martin Gencur
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.2.0.CR2
>
> Attachments: trace_log_machine_attribute_failing.txt
>
>
> The rack and site attributes already work correctly. I'm creating this one issue just for the remaining "machine" attribute.
> Will attach trace logs
--
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-2545) org.infinispan.query.analysis.SolrAnalyzerTest testAnalyzers() fail on IBM JDK7
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2545?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2545:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1575
> org.infinispan.query.analysis.SolrAnalyzerTest testAnalyzers() fail on IBM JDK7
> -------------------------------------------------------------------------------
>
> Key: ISPN-2545
> URL: https://issues.jboss.org/browse/ISPN-2545
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.2.0.Beta4
> Reporter: Anna Manukyan
> Assignee: Tristan Tarrant
> Labels: testsuite_stability
>
> The org.infinispan.query.analysis.SolrAnalyzerTest.testAnalyzers() is failing periodically on IBM JDK7 with the following exceptions:
> {code}
> Error Message
> Unknown Analyzer definition: standard_analyzer
> Stacktrace
> org.hibernate.search.SearchException: Unknown Analyzer definition: standard_analyzer
> at org.hibernate.search.impl.ImmutableSearchFactory.getAnalyzer(ImmutableSearchFactory.java:249)
> at org.hibernate.search.impl.MutableSearchFactory.getAnalyzer(MutableSearchFactory.java:167)
> at org.infinispan.query.analysis.SolrAnalyzerTest.testAnalyzers(SolrAnalyzerTest.java:104)
> 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:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:345)
> at java.util.concurrent.FutureTask.run(FutureTask.java:177)
> 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:769)
> {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
12 years
[JBoss JIRA] (ISPN-2705) site command does not work correctly
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2705?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2705:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1572
> site command does not work correctly
> ------------------------------------
>
> Key: ISPN-2705
> URL: https://issues.jboss.org/browse/ISPN-2705
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.2.0.CR1
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
> Fix For: 5.2.0.CR2
>
>
> * Issuing "site --status" command results in NPE:
> {code}
> 13:11:10,278 ERROR [org.infinispan.cli.interpreter.Interpreter] (pool-1-thread-1) ISPN019003: Interpreter error: java.lang.NullPointerException
> at org.infinispan.cli.interpreter.statement.SiteStatement.execute(SiteStatement.java:56) [infinispan-cli-server-5.2.0.CR1-redhat-1.jar:5.2.0.CR1-redhat-1]
> at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:161) [infinispan-cli-server-5.2.0.CR1-redhat-1.jar:5.2.0.CR1-redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09]
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:270) [infinispan-core-5.2.0.CR1-redhat-1.jar:5.2.0.CR1-redhat-1]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_09]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) [rt.jar:1.7.0_09]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
> {code}
> * "site --offline" has the same results
> * "site --status default.LON" results in "Incorrect site name: null"
> I'm pretty sure the active site is named LON as I was using an example configuration file shipped with JDG: standalone-xsite.xml. Also, the log shows Received new cluster view: [mgencur/LON|0] [mgencur/LON]
--
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-2545) org.infinispan.query.analysis.SolrAnalyzerTest testAnalyzers() fail on IBM JDK7
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2545?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-2545:
-------------------------------------
Assignee: Tristan Tarrant (was: Sanne Grinovero)
> org.infinispan.query.analysis.SolrAnalyzerTest testAnalyzers() fail on IBM JDK7
> -------------------------------------------------------------------------------
>
> Key: ISPN-2545
> URL: https://issues.jboss.org/browse/ISPN-2545
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.2.0.Beta4
> Reporter: Anna Manukyan
> Assignee: Tristan Tarrant
> Labels: testsuite_stability
>
> The org.infinispan.query.analysis.SolrAnalyzerTest.testAnalyzers() is failing periodically on IBM JDK7 with the following exceptions:
> {code}
> Error Message
> Unknown Analyzer definition: standard_analyzer
> Stacktrace
> org.hibernate.search.SearchException: Unknown Analyzer definition: standard_analyzer
> at org.hibernate.search.impl.ImmutableSearchFactory.getAnalyzer(ImmutableSearchFactory.java:249)
> at org.hibernate.search.impl.MutableSearchFactory.getAnalyzer(MutableSearchFactory.java:167)
> at org.infinispan.query.analysis.SolrAnalyzerTest.testAnalyzers(SolrAnalyzerTest.java:104)
> 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:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:345)
> at java.util.concurrent.FutureTask.run(FutureTask.java:177)
> 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:769)
> {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
12 years
[JBoss JIRA] (ISPN-2335) MultiHotRodServersTest not works with ConfigurationBuilder API
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2335?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño reassigned ISPN-2335:
--------------------------------------
Assignee: Galder Zamarreño (was: Tristan Tarrant)
> MultiHotRodServersTest not works with ConfigurationBuilder API
> --------------------------------------------------------------
>
> Key: ISPN-2335
> URL: https://issues.jboss.org/browse/ISPN-2335
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols, Test Suite
> Affects Versions: 5.2.0.Alpha4
> Reporter: Thomas Fromm
> Assignee: Galder Zamarreño
> Fix For: 5.2.0.CR2
>
> Attachments: trace-infinispan.log, trace-infinispan.log.fail
>
>
> I tried to use ConfigurationBuilder API with addClusterEnabledCacheManager inside MultiHotRodServersTest.addHotRodServer.
> Unfortunality it works on with the old Configuration object, with the Builder the test fails. I tried to find any relevant difference inside configuration, but wasn't successful :-(
> So I use a LegacyConfigurationAdaptor to create old config.
> Attachmed I've traces from the failing tests and from the working one. Maybe it helps.
--
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-2697) HotRodServer startup fails when its record cannot be inserted into topology cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-2697?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-2697:
-----------------------------------
@Dan Berinder: it is not the rate of STABILITY (there's no message STABLE) which stays constant but STABLE_GOSSIP. In fact, STABILITY rate increases with increasing cluster size, and this is the period which should be guarded against sync.repl_timeout. However, I think that the period of STABILITY messages on large clusters is pretty long (do we want to set repl_timeout to 6 minutes for 64 node cluster with gossip period 5 seconds?)
> 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: Dan Berindei
> 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
12 years
