[JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing when run on IBM JDK
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1783?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1783:
-----------------------------------------------
Ondrej Chaloupka <ochaloup(a)redhat.com> made a comment on [bug 990112|https://bugzilla.redhat.com/show_bug.cgi?id=990112]
Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
The stack trace:
java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
...
The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.
> IIOPNamingTestCase is failing when run on IBM JDK
> -------------------------------------------------
>
> Key: WFLY-1783
> URL: https://issues.jboss.org/browse/WFLY-1783
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha3
> Environment: ibm jdk
> Reporter: Ondřej Chaloupka
> Assignee: Ondřej Chaloupka
>
> Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
> Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> The stack trace:
> {code}
> java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
> at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
> at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> {code}
> The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.
--
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, 11 months
[JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing when run on IBM JDK
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created WFLY-1783:
--------------------------------------
Summary: IIOPNamingTestCase is failing when run on IBM JDK
Key: WFLY-1783
URL: https://issues.jboss.org/browse/WFLY-1783
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 8.0.0.Alpha3
Environment: ibm jdk
Reporter: Ondřej Chaloupka
Assignee: Ondřej Chaloupka
Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
The stack trace:
{code}
java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
{code}
The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.
--
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, 11 months
[JBoss JIRA] (WFLY-1782) ASYNC-tcp tests should have cacheMode set to ASYNC
by Emmanuel Hugonnet (JIRA)
Emmanuel Hugonnet created WFLY-1782:
---------------------------------------
Summary: ASYNC-tcp tests should have cacheMode set to ASYNC
Key: WFLY-1782
URL: https://issues.jboss.org/browse/WFLY-1782
Project: WildFly
Issue Type: Feature Request
Components: Test Suite
Reporter: Emmanuel Hugonnet
Assignee: Ondrej Zizka
Priority: Minor
testsuite/integration/clust/pom.xml
<cacheMode>SYNC</cacheMode> is used for SYNC-tcp tests instead of <cacheMode>ASYNC</cacheMode>
--
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, 11 months
[JBoss JIRA] (WFLY-1727) Allow injection of resources from external JNDI contexts
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1727?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-1727:
---------------------------------------
I see, for that to work we would need to define a name prefix or namespace for all external contexts, and setup the external context root as the lookup dependency. I'm not sure it is worth to support such use case, we don't support contexts with linkref also, which is similar in concept. Is there a strong need for this feature?
> Allow injection of resources from external JNDI contexts
> --------------------------------------------------------
>
> Key: WFLY-1727
> URL: https://issues.jboss.org/browse/WFLY-1727
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming
> Reporter: Jan Martiska
> Assignee: Eduardo Martins
>
> The ability to federate external JNDI contexts into WildFly's JNDI namespaces was introduced with WFLY-287.
> Currently, it is not possible to programatically inject resources into applications (eg. using @Resource annotation) from the federated contexts. It would be a nice to have feature.
--
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, 11 months
[JBoss JIRA] (JGRP-592) Pluggable policy for picking coordinator
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-592?page=com.atlassian.jira.plugin.s... ]
Bela Ban edited comment on JGRP-592 at 7/30/13 6:57 AM:
--------------------------------------------------------
The new merge policy tries to minimize moving the cordinator around (JGRP-1002). It works by picking the coordinator of the MergeView as the first elements of the sorted set of all subview coordinators. If we have \{A,B,C\}, \{M,N,O\} and \{X,Y,Z\}, then the new coordinator will be either A, M or X, but not any of the other members.
The rest of the subview ordering is left untouched, e.g. if we pick M as new coord, the MergeView will be \{M,A,B,C,N,O,X,Y,Z\}.
was (Author: belaban):
The new merge policy tries to minimize moving the cordinator around (JGRP-1002). It works by picking the coordinator of the MergeView as the first elements of the sorted set of all subview coordinators. If we have {A,B,C}, {M,N,O} and {X,Y,Z}, then the new coordinator will be either A, M or X, but not any of the other members.
The rest of the subview ordering is left untouched, e.g. if we pick M as new coord, the MergeView will be {M,A,B,C,N,O,X,Y,Z}.
> Pluggable policy for picking coordinator
> ----------------------------------------
>
> Key: JGRP-592
> URL: https://issues.jboss.org/browse/JGRP-592
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> Make policy to pick coordinator pluggable. Pick new coordinator after existing coordinator crashes by calling this policy.
> Default policy is to pick the next in line.
> Other policies could pick the next in line from a set of pinned coordinator, so certain members can never become coordinators.
--
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, 11 months
[JBoss JIRA] (JGRP-592) Pluggable policy for picking coordinator
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-592?page=com.atlassian.jira.plugin.s... ]
Bela Ban edited comment on JGRP-592 at 7/30/13 6:58 AM:
--------------------------------------------------------
[Comment from JGRP-1002]
When we have \{C, A, B\} and split into \{C,A\} and \{B\}, then a merge will produce \{A,B,C\}. Therefore the coord is moved from C to A. For certain apps, e.g. JBoss singletons, this is not good, as we're moving the singleton services from a perfectly healthy node to a different node.
GOAL: come up with a deterministic policy of picking a coord such that we minimize coord switching if the existing coord is still member of the cluster.
This depends on or is related to the flexible coord pick policy JIRA issue
was (Author: belaban):
[Comment from JGRP-1002]
When we have {C, A, B} and split into {C,A} and {B}, then a merge will produce {A,B,C}. Therefore the coord is moved from C to A. For certain apps, e.g. JBoss singletons, this is not good, as we're moving the singleton services from a perfectly healthy node to a different node.
GOAL: come up with a deterministic policy of picking a coord such that we minimize coord switching if the existing coord is still member of the cluster.
This depends on or is related to the flexible coord pick policy JIRA issue
> Pluggable policy for picking coordinator
> ----------------------------------------
>
> Key: JGRP-592
> URL: https://issues.jboss.org/browse/JGRP-592
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> Make policy to pick coordinator pluggable. Pick new coordinator after existing coordinator crashes by calling this policy.
> Default policy is to pick the next in line.
> Other policies could pick the next in line from a set of pinned coordinator, so certain members can never become coordinators.
--
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, 11 months
[JBoss JIRA] (JGRP-592) Pluggable policy for picking coordinator
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-592?page=com.atlassian.jira.plugin.s... ]
Bela Ban commented on JGRP-592:
-------------------------------
The new merge policy tries to minimize moving the cordinator around (JGRP-1002). It works by picking the coordinator of the MergeView as the first elements of the sorted set of all subview coordinators. If we have {A,B,C}, {M,N,O} and {X,Y,Z}, then the new coordinator will be either A, M or X, but not any of the other members.
The rest of the subview ordering is left untouched, e.g. if we pick M as new coord, the MergeView will be {M,A,B,C,N,O,X,Y,Z}.
> Pluggable policy for picking coordinator
> ----------------------------------------
>
> Key: JGRP-592
> URL: https://issues.jboss.org/browse/JGRP-592
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> Make policy to pick coordinator pluggable. Pick new coordinator after existing coordinator crashes by calling this policy.
> Default policy is to pick the next in line.
> Other policies could pick the next in line from a set of pinned coordinator, so certain members can never become coordinators.
--
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, 11 months