[JBoss JIRA] (JGRP-1613) FORK: cactus stacks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1613 at 8/1/13 7:08 AM:
--------------------------------------------------------
OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope. One of the main reasons was that - as grafts could be dynamically created (as a matter of fact, Sanne would need a graft to be created *per deployed application*) and deleted - not all nodes would have all grafts. This means that GMS would have to maintain something like the dreaded service views (google for Multiplexer service views, e.g. [1]). This means that if we have view \{A,B,C,D\}, but only nodes B and C have a certain graft created, then the *service view* for that graft would be \{B,C\}.
The new functionality should be:
* FORK can only be the top protocol in a stack (or towards the top of the stack)
* An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel
* The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets
* The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel
* In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty
* That string is used to mux/demux messages to the app
* A header is added to each message including that max-id so we know how to mux/demux
* There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel
* When the main channel is closed, sending of messages on the fork-channel throws an exception
* The view and address of the fork-channels is the same as that of the main channel
[1] https://community.jboss.org/wiki/MigrationFromMultiplexerToSharedTransport
was (Author: belaban):
OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope:
* FORK can only be the top protocol in a stack (or towards the top of the stack)
* An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel
* The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets
* The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel
* In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty
* That string is used to mux/demux messages to the app
* A header is added to each message including that max-id so we know how to mux/demux
* There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel
* When the main channel is closed, sending of messages on the fork-channel throws an exception
* The view and address of the fork-channels is the same as that of the main channel
> FORK: cactus stacks
> -------------------
>
> Key: JGRP-1613
> URL: https://issues.jboss.org/browse/JGRP-1613
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: IMAG0129.jpg
>
>
> Introduce cactus stacks where we can have multiple, different, stacks grafted onto the same base stack.
> The problem today is that different applications need different functionality (protocol stack configs) in the AS. For example, we have the default stack used by AS. Then, Hibernate Search wants to use distributed locking (CENTRAL_LOCK) and counting (COUNTER). The total order stack wants to use TOA/SEQUENCER and so on.
> Cactus stacks add the ability to:
> * Provide custom (partial) stacks that are grafted onto a base stack
> * Add/remove stacks at runtime
> See the attached picture for details.
--
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
10 years, 9 months
[JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing when run on IBM JDK
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1783?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka resolved WFLY-1783.
------------------------------------
Resolution: Done
The pom.xml change for basic module of testsuite was merged.
> 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
10 years, 9 months
[JBoss JIRA] (WFLY-1800) Upgrade to Remoting JMX 2.0.0 (Beta 2)
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-1800:
--------------------------------------
Summary: Upgrade to Remoting JMX 2.0.0 (Beta 2)
Key: WFLY-1800
URL: https://issues.jboss.org/browse/WFLY-1800
Project: WildFly
Issue Type: Task
Components: JMX, Remoting
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.Alpha4
So that association of the Subject with the AccessControlContext is in place Remoting JMX 2.0.0.Beta 2 is needed.
--
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
10 years, 9 months
[JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing when run on IBM JDK
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1783?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated WFLY-1783:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/4856
> 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
10 years, 9 months
[JBoss JIRA] (REMJMX-61) Ensure Subject of remote user is associated with the AccessControContext handling the request.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-61?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated REMJMX-61:
-----------------------------------
Description:
WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext.
As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext.
No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads.
This will need to apply to all versions of the protocol - this is specifically a server side change but the remote side of the connection may be using the older protocol versions.
was:
WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext.
As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext.
No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads.
> Ensure Subject of remote user is associated with the AccessControContext handling the request.
> ----------------------------------------------------------------------------------------------
>
> Key: REMJMX-61
> URL: https://issues.jboss.org/browse/REMJMX-61
> Project: Remoting JMX
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.1.CR1, 2.0.0.Beta2
>
>
> WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext.
> As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext.
> No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads.
> This will need to apply to all versions of the protocol - this is specifically a server side change but the remote side of the connection may be using the older protocol versions.
--
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
10 years, 9 months
[JBoss JIRA] (REMJMX-61) Ensure Subject of remote user is associated with the AccessControContext handling the request.
by Darran Lofthouse (JIRA)
Darran Lofthouse created REMJMX-61:
--------------------------------------
Summary: Ensure Subject of remote user is associated with the AccessControContext handling the request.
Key: REMJMX-61
URL: https://issues.jboss.org/browse/REMJMX-61
Project: Remoting JMX
Issue Type: Task
Components: Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.1.CR1, 2.0.0.Beta2
WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext.
As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext.
No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads.
--
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
10 years, 9 months
[JBoss JIRA] (JGRP-1436) GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1436?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1436.
----------------------------
Resolution: Won't Fix
> GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE
> -----------------------------------------------------------
>
> Key: JGRP-1436
> URL: https://issues.jboss.org/browse/JGRP-1436
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> View bundling in GMS bundles events based on (1) whether they can be processed together and (2) whether a view bundling timeout is defined. The latter timeout is for all events, perhaps we want to define separate timeouts, e.g. the timeout for JOINs is 3000, but for LEAVE it is 500. This means that when we get multiple JOIN events, we'll wait up to 5 seconds and then process them together. When we get multiple LEAVE requests, we only wait for half a second before processing them. This causes LEAVEs to be processed almost immediately, whereas JOINs are bundled.
> Also revisit the code which determines which events can be processed together. Perhaps MERGE events can be bundled, 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
10 years, 9 months
[JBoss JIRA] (JGRP-1436) GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1436?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1436 at 8/1/13 6:41 AM:
--------------------------------------------------------
Don't think I want to do this as it complicates the code; having separate timeouts for joins, leaves and suspects means we'd have to maintain 3 instead of 1 queue in GMS.ViewHandler.
Keeping GMS.max_bundling_time sufficiently small, e.g. 50-500ms, guarantees speedy processing of those events.
was (Author: belaban):
Don't think I want to do this as it complicates the code; having separate timeouts for joins, leaves and suspects (?) means we'd have to maintain 3 instead of 1 queue in GMS.ViewHandler.
Keeping GMS.max_bundling_time sufficiently small, e.g. 50-500ms, guarantees speedy processing of those events.
> GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE
> -----------------------------------------------------------
>
> Key: JGRP-1436
> URL: https://issues.jboss.org/browse/JGRP-1436
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> View bundling in GMS bundles events based on (1) whether they can be processed together and (2) whether a view bundling timeout is defined. The latter timeout is for all events, perhaps we want to define separate timeouts, e.g. the timeout for JOINs is 3000, but for LEAVE it is 500. This means that when we get multiple JOIN events, we'll wait up to 5 seconds and then process them together. When we get multiple LEAVE requests, we only wait for half a second before processing them. This causes LEAVEs to be processed almost immediately, whereas JOINs are bundled.
> Also revisit the code which determines which events can be processed together. Perhaps MERGE events can be bundled, 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
10 years, 9 months