[JBoss JIRA] (DROOLS-1321) Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1321:
----------------------------------------
Summary: Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
Key: DROOLS-1321
URL: https://issues.jboss.org/browse/DROOLS-1321
Project: Drools
Issue Type: Task
Components: build
Reporter: Geoffrey De Smet
Assignee: Michael Biarnes Kiefer
Motivation:
1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.
To do:
- Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
- This includes canonical meta elements
- This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
- This does not include external links, such as to wikipedia etc.
Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.
Exceptions:
- ci.optaplanner.org must be on http, because those sites don't work over https...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-848) "XNIO001001: No XNIO provider found" by some tests running with security manager
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFCORE-848?page=com.atlassian.jira.plugin... ]
Ingo Weiss reassigned WFCORE-848:
---------------------------------
Assignee: Ingo Weiss (was: Josef Cacek)
> "XNIO001001: No XNIO provider found" by some tests running with security manager
> --------------------------------------------------------------------------------
>
> Key: WFCORE-848
> URL: https://issues.jboss.org/browse/WFCORE-848
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Alpha11
> Reporter: Petr Kremensky
> Assignee: Ingo Weiss
>
> Some tests in wildfly-core fails due to "XNIO001001: No XNIO provider found" while run with security manager enabled.
> {noformat}
> mvn test -Dtest=SuspendResumeTestCase -Dsecurity.manager -DtestLogToFile=false
> 10:27:16,814 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.test-undertow-server: org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> at org.xnio.Xnio.getInstance(Xnio.java:181)
> at io.undertow.Undertow.start(Undertow.java:97)
> at org.wildfly.test.suspendresumeendpoint.TestUndertowService.start(TestUndertowService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 10:27:16,816 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "web-suspend.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> 10:27:16,817 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "web-suspend.jar" was rolled back with the following failure message:
> {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> {noformat}
> Affected tests found so far:
> * org.wildfly.core.test.standalone.suspend.web.SuspendResumeTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainGracefulShutdownTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainSuspendResumeTestCase
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-6932) LookupTestCase fails with security manager
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-6932?page=com.atlassian.jira.plugin.... ]
Ingo Weiss commented on WFLY-6932:
----------------------------------
Seems to be working on the latest {{master}} branch.
> LookupTestCase fails with security manager
> ------------------------------------------
>
> Key: WFLY-6932
> URL: https://issues.jboss.org/browse/WFLY-6932
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Jan Tymel
>
> *org.jboss.as.test.integration.ee.remotelookup.LookupTestCase#testServerLocalLookup*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.remotelookup.LookupTestCase#testServerLocalLookup -Dsecurity.manager}}
> Fails with:
> {code}
> WARN [org.apache.activemq.artemis.core.client] (pool-3-thread-1) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost" "resolve")" in code source "(vfs:/content/deploy.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkConnect(SecurityManager.java:1048)
> at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:407)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1268)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at java.net.InetAddress.getByName(InetAddress.java:1076)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:220)
> at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:575)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1009)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1053)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1232)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:867)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:769)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:760)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
> at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.lookupConnectionFactory(LookupTestCase.java:81)
> at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.testServerLocalLookup(LookupTestCase.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 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:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2056:
---------------------------
Attachment: bla2.java
bla.java
> Measure latency for RPCs
> ------------------------
>
> Key: JGRP-2056
> URL: https://issues.jboss.org/browse/JGRP-2056
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: bla.java, bla2.java
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2056:
---------------------------
Attachment: (was: bla.java)
> Measure latency for RPCs
> ------------------------
>
> Key: JGRP-2056
> URL: https://issues.jboss.org/browse/JGRP-2056
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2056:
--------------------------------
Latency for members A and B in the same JVM is ~60us for regular messages (JChannel) (bla) and 3-4us higher for MessageDispatcher (bla2).
Using {{SenderSendsBundler}}, the numbers drop to 42us (bla) and 47us (bla2).
RoundTrip shows RTT times (A and B are 2 processes on the same box) of 102us ({{TransferQueueBundler}}) and 83us ({{SenderSendsBundler}}), which is about twice the latency, which is OK.
> Measure latency for RPCs
> ------------------------
>
> Key: JGRP-2056
> URL: https://issues.jboss.org/browse/JGRP-2056
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7266) BOM wildfly-javaee7-with-tools mismanages some dependencies
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-7266:
-----------------------------------
We do publish it, as it is needed for testing EE7 compatibility, but not really something end user apps would need to depend upon.
Well, they can, but you get all EE7 APIs at once, not just ones you need.
It could be that we only started doing boms around WF8 times.
> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
> Key: WFLY-7266
> URL: https://issues.jboss.org/browse/WFLY-7266
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
> Reporter: kostd kostd
> Assignee: Tomaz Cerar
> Priority: Optional
> Attachments: pom.xml
>
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.wildfly.bom</groupId>
> <artifactId>wildfly-javaee7-with-tools</artifactId>
> <version>10.1.0.Final</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> <dependencies>
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-spec-api</artifactId>
> <version>10.1.0.Final</version>
> <type>pom</type>
> <scope>provided</scope>
> </dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO] +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO] +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO] | \- javax.inject:javax.inject:jar:1:provided
> [INFO] +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO] +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO] +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO] +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO] +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO] +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO] +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO] +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO] | \- javax.activation:activation:jar:1.1.1:provided
> [INFO] +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO] +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO] +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO] \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
> <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
> <!-- BOM imports -->
> <!-- JBoss distributes a complete set of Java EE 7 APIs including
> a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
> a collection) of artifacts. We use this here so that we always get the correct
> versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
> this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
> this stack with any version of WildFly that implements Java EE 7! -->
> <dependency>
> <groupId>org.jboss.spec</groupId>
> <artifactId>jboss-javaee-7.0</artifactId>
> <version>${version.org.jboss.spec.jboss.javaee.7}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
> <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
> <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
> <dependency>
> <groupId>org.jboss.spec.javax.el</groupId>
> <artifactId>jboss-el-api_3.0_spec</artifactId>
> <version>${version.org.jboss.spec.javax.el}</version>
> </dependency>
> ...
> <dependency>
> <groupId>org.jboss.spec.javax.faces</groupId>
> <artifactId>jboss-jsf-api_2.2_spec</artifactId>
> <version>${version.org.jboss.spec.javax.faces}</version>
> </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-5239:
--------------------------------------
Well that's rather unfortunate situation, since this is the only test case, I'm aware of, included in standard execution (-DallTests) which requires 4 nodes to pass - only servers in Perf and Messaging lab have these four configured (+ maybe some exceptions in mwqe lab). I'll see what can be done on our side to workaround this.
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar &#27;[0m&#27;[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &#27;[0mExecuted HTTP request
> &#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7273:
-------------------------------
Description:
In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
Exception in server log:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("ldap-realm" => "ldap")
]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
was:
In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-7273
> URL: https://issues.jboss.org/browse/WFLY-7273
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7273:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-7273
> URL: https://issues.jboss.org/browse/WFLY-7273
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months