[JBoss JIRA] (WFLY-9364) Closing an EJBClientContext sometimes hangs causing high CPU usage
by Marius Tantareanu (JIRA)
[ https://issues.jboss.org/browse/WFLY-9364?page=com.atlassian.jira.plugin.... ]
Marius Tantareanu commented on WFLY-9364:
-----------------------------------------
Thank you for the updates. Is there a particular fix in 3.5.x that addresses this issue? In other words, is there any chance for us to backport a fix to 3.4.x? I'm asking this as we are unable to upgrade to WildFly 11 at this point and the WildFly 10.1 client does not seem to work with XNIO 3.5.x.
> Closing an EJBClientContext sometimes hangs causing high CPU usage
> ------------------------------------------------------------------
>
> Key: WFLY-9364
> URL: https://issues.jboss.org/browse/WFLY-9364
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: Server:
> - OS:
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> - JDK:
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
> - WildFly:
> WildFly 10.1.0.Final
> Client:
> - OS:
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> - JDK:
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
> Reporter: Marius Tantareanu
> Assignee: Jason Greene
> Attachments: echo-client.zip, output_rhel7.txt, output_win10.txt, simple-ear.ear, td_rhel7.txt, td_win10.txt
>
>
> EJBClientContext.close() sometimes hangs and causes high CPU usage. We have a WildFly client that uses EJB client API to invoke some EJBs remotely.
> Basically the client executes the following actions in a loop:
> - setup an EJBClientContext programatically
> - create a JNDI context
> - lookup an EJB and invoke some operations on it
> - close the JNDI context and the EJBClientContext
> After the client runs a few hundreds iterations (the actual number of iterations varies quite a lot from one run to another) it blocks while invoking EJBClientContext.close(). Also one XNIO thread in the client app is constantly consuming one CPU core (full thread dump from the client app is attached). I was only able to reproduce this when connecting over TLS (port 8443). When using the unsecure port (8080) the problem does not reproduce (or it reproduces much less frequently and I didn't run enough iterations to catch it).
> Once the client app enters this state, top shows something like (notice the CPU usage of thread 12512):
> >top -H -p 6463
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 12512 root 20 0 11.527g 222680 13788 R 99.3 0.7 141:10.99 java
> 6466 root 20 0 11.527g 222680 13788 S 0.3 0.7 0:07.05 java
> 6467 root 20 0 11.527g 222680 13788 S 0.3 0.7 0:06.97 java
> 6477 root 20 0 11.527g 222680 13788 S 0.3 0.7 0:04.24 java
> 6463 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 6464 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:03.46 java
> 6465 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:06.94 java
> 6468 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:07.02 java
> 6469 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:16.42 java
> 6470 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.01 java
> 6471 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.01 java
> 6472 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 6473 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:06.87 java
> 6474 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:06.70 java
> 6475 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:03.09 java
> 6476 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12513 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12514 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12515 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12516 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12517 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12518 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12519 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12520 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12523 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12524 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12597 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> The thread that causes the CPU usage is the following:
> "Remoting "config-based-ejb-client-endpoint" I/O-1" #6025 daemon prio=5 os_prio=0 tid=0x00007f2f709d3000 nid=0x30e0 runnable [0x00007f2e7f9be000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x00000005cc1844e8> (a sun.nio.ch.Util$3)
> - locked <0x00000005cc19f258> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000005cc184468> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> The client app main thread is blocked as below:
> "main" #1 prio=5 os_prio=0 tid=0x00007f2f70008800 nid=0x1940 in Object.wait() [0x00007f2f76350000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:190)
> - locked <0x00000005cc18de48> (a java.lang.Object)
> at org.jboss.ejb.client.remoting.ConnectionPool.safeClose(ConnectionPool.java:177)
> at org.jboss.ejb.client.remoting.ConnectionPool.release(ConnectionPool.java:104)
> - locked <0x00000005cbd369e0> (a org.jboss.ejb.client.remoting.ConnectionPool)
> at org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection.close(ConnectionPool.java:198)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.safeClose(RemotingConnectionManager.java:65)
> - locked <0x00000005cc1a6840> (a java.util.Collections$SynchronizedRandomAccessList)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector$ContextCloseListener.contextClosed(ConfigBasedEJBClientContextSelector.java:220)
> at org.jboss.ejb.client.EJBClientContext.close(EJBClientContext.java:1305)
> - locked <0x00000005cc1a6888> (a org.jboss.ejb.client.EJBClientContext)
> at com.microfocus.echoclient.EchoClient.disconnect(EchoClient.java:66)
> at com.microfocus.echoclient.EchoClient.connectDisconnect(EchoClient.java:54)
> at com.microfocus.echoclient.EchoClient.main(EchoClient.java:36)
> The problem also reproduces on Windows (full thread dump of the client app is attached).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFLY-9160) ChunkPartitionTestCase fails with security manager
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-9160?page=com.atlassian.jira.plugin.... ]
Yeray Borges reassigned WFLY-9160:
----------------------------------
Assignee: Yeray Borges (was: James Perkins)
> ChunkPartitionTestCase fails with security manager
> --------------------------------------------------
>
> Key: WFLY-9160
> URL: https://issues.jboss.org/browse/WFLY-9160
> Project: WildFly
> Issue Type: Bug
> Components: Batch, Test Suite
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
>
> ChunkPartitionTestCase fails with security manager
> {code}
> Suppressed: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local1937539592015998438.challenge" "read")" in code source "(vfs:/content/batch-chunk-partition.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.batch-chunk-partition.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350)
> at java.io.FileInputStream.<init>(FileInputStream.java:127)
> at org.wildfly.security.sasl.localuser.LocalUserClient.evaluateMessage(LocalUserClient.java:93)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.util.AbstractSaslClient.evaluateChallenge(AbstractSaslClient.java:59)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.lambda$handleEvent$0(ClientConnectionOpenListener.java:644)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898)
> ... 3 more
> Suppressed: javax.security.sasl.SaslException: DIGEST-MD5: Server rejected authentication
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:730)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:572)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFLY-9161) JobControlTestCase fails with security manager
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-9161?page=com.atlassian.jira.plugin.... ]
Yeray Borges reassigned WFLY-9161:
----------------------------------
Assignee: Yeray Borges (was: James Perkins)
> JobControlTestCase fails with security manager
> ----------------------------------------------
>
> Key: WFLY-9161
> URL: https://issues.jboss.org/browse/WFLY-9161
> Project: WildFly
> Issue Type: Bug
> Components: Batch, Test Suite
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
>
> JobControlTestCase fails with security manager
> Some tests fail with:
> {code}
> aused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local2441956400719098652.challenge" "read")" in code source "(vfs:/content/test-batch.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test-batch.war" from Service Module Loader")
> DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Server rejected authentication
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:109)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:400)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:542)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:504)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:492)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118)
> ... 155 more
> ...
> {code}
> or
> {code}
> Suppressed: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local471205335337215113.challenge" "read")" in code source "(vfs:/content/test-batch.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test-batch.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350)
> at java.io.FileInputStream.<init>(FileInputStream.java:127)
> at org.wildfly.security.sasl.localuser.LocalUserClient.evaluateMessage(LocalUserClient.java:93)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.util.AbstractSaslClient.evaluateChallenge(AbstractSaslClient.java:59)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.lambda$handleEvent$0(ClientConnectionOpenListener.java:644)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898)
> ... 3 more
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFLY-9370) Fix failing SingletonTunnelTestCase
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9370?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9370:
--------------------------------------
Fixing the above issues, the test gets stuck on
{noformat}
at org.jgroups.stack.RouterStubManager.forAny(RouterStubManager.java:95)
at org.jgroups.protocols.TUNNEL$DefaultTUNNELPolicy.sendToAllMembers(TUNNEL.java:245)
at org.jgroups.protocols.TUNNEL.send(TUNNEL.java:219)
at org.jgroups.protocols.TP._send(TP.java:1598)
at org.jgroups.protocols.TP.down(TP.java:1514)
at org.jgroups.protocols.Discovery.down(Discovery.java:440)
at org.jgroups.protocols.MERGE3.down(MERGE3.java:261)
at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:384)
at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233)
at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92)
at org.jgroups.protocols.pbcast.NAKACK2.send(NAKACK2.java:807)
at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:510)
at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:682)
at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1111)
at org.jgroups.protocols.FlowControl.down(FlowControl.java:347)
at org.jgroups.protocols.MFC.handleDownMessage(MFC.java:123)
at org.jgroups.protocols.FlowControl.down(FlowControl.java:324)
at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
at org.jgroups.protocols.FORK.down(FORK.java:101)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1039)
at org.jgroups.JChannel.down(JChannel.java:790)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:683)
at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:172)
at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:319)
at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:75)
at org.jgroups.blocks.Request.execute(Request.java:67)
at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:373)
at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:386)
at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:272)
at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcher.executeOnCluster(ChannelCommandDispatcher.java:101)
at org.wildfly.clustering.server.singleton.PrimaryProxyService.getValue(PrimaryProxyService.java:60)
at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
at org.wildfly.clustering.server.singleton.DistributedSingletonService.getValue(DistributedSingletonService.java:180)
at org.jboss.msc.service.ServiceControllerImpl.awaitValue(ServiceControllerImpl.java:1166)
- locked <0x00000007a33d8a00> (a org.jboss.msc.service.ServiceControllerImpl)
at org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet.doGet(NodeServiceServlet.java:70)
{noformat}
> Fix failing SingletonTunnelTestCase
> -----------------------------------
>
> Key: WFLY-9370
> URL: https://issues.jboss.org/browse/WFLY-9370
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 11.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> {{SingletonTunnelTestCase(ASYNC-tunnel)#testSingletonService}} is failing consistently now.
> The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be moved to the right location and renamed (i.e. drop tunnel since that has nothing to do with what it is testing).
> {noformat}
> &#27;[0m&#27;[31m04:44:19,235 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "singleton.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.clustering.group.default"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.test1.service.default is missing [jboss.clustering.group.default]",
> "jboss.test2.service.default is missing [jboss.clustering.group.default]"
> ],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.discovery.\"singleton.war\"",
> "jboss.deployment.unit.\"singleton.war\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"singleton.war\".WeldStartService",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.JndiBindingsService",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.START",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.VIEW.\"org.jboss.as.test.clustering.TopologyChangeListener\".REMOTE",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInterceptorBindingsService",
> "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".deploymentCompleteService",
> "jboss.deployment.unit.\"singleton.war\".ejb3.client-context.registration-service",
> "jboss.deployment.unit.\"singleton.war\".jndiDependencyService",
> "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformation",
> "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformationStart",
> "jboss.naming.context.java.app.singleton.singleton.TopologyChangeListenerBean",
> "jboss.naming.context.java.app.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"",
> "jboss.naming.context.java.global.singleton.TopologyChangeListenerBean",
> "jboss.naming.context.java.global.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"",
> "jboss.naming.context.java.module.singleton.singleton.TopologyChangeListenerBean",
> "jboss.naming.context.java.module.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"",
> "jboss.undertow.deployment.default-server.default-host./singleton",
> "jboss.undertow.deployment.default-server.default-host./singleton.UndertowDeploymentInfoService"
> ],
> "Services that may be the cause:" => [
> "jboss.clustering.group.default",
> "org.wildfly.network.socket-binding.undefined"
> ]
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (ELY-849) Rename setMechanismProperties to setSaslMechanismProperties
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-849:
---------------------------------
Fix Version/s: 1.2.0.Beta5
(was: 1.2.0.Beta6)
> Rename setMechanismProperties to setSaslMechanismProperties
> -----------------------------------------------------------
>
> Key: ELY-849
> URL: https://issues.jboss.org/browse/ELY-849
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.2.0.Beta5
>
>
> If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties.
> We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (ELY-849) Rename setMechanismProperties to setSaslMechanismProperties
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-849:
------------------------------------
Assignee: Darran Lofthouse
> Rename setMechanismProperties to setSaslMechanismProperties
> -----------------------------------------------------------
>
> Key: ELY-849
> URL: https://issues.jboss.org/browse/ELY-849
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.2.0.Beta5
>
>
> If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties.
> We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month