[JBoss JIRA] (WFLY-9419) Infinispan subsystem returns wrong value for GlobalConfiguration.transport().clusterName()
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9419?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-13368 to WFLY-9419:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9419 (was: JBEAP-13368)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.CR1
(was: 7.1.0.CR2)
> Infinispan subsystem returns wrong value for GlobalConfiguration.transport().clusterName()
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-9419
> URL: https://issues.jboss.org/browse/WFLY-9419
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> This prevents users from easily creating multiple clusters on the same network whose nodes need to interact with each other via the ejb client.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3332) Chained transformers don't work correctly if an earlier transformer in the chain converts an op into a composite
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3332:
----------------------------------------
Summary: Chained transformers don't work correctly if an earlier transformer in the chain converts an op into a composite
Key: WFCORE-3332
URL: https://issues.jboss.org/browse/WFCORE-3332
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
CompositeOperationTransformer doesn't work correctly if the resource against which transformation is occurring isn't the root. It asserts that it is the root, and therefore fails. And if that is corrected, then it passes an absolute address to a method that builds an absolute PathAddress from a relative one, instead of using the method that takes an absolute address.
Where I'm seeing this fail is with a chained transformer, where the first link in the chain converts an op into a composite. The op is not against the root, so the address of the resource being transformed also isn't. As the chain proceeds, CompositeOperationTransformer gets called and blows up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[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, 7 months
[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, 7 months
[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, 7 months