[JBoss JIRA] (JBJCA-1353) Parallelize flush of pools
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1353?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated JBJCA-1353:
-------------------------------
Description:
This is related to WFLY-8492 where WildFly server does not shutdown in a timely fashion. There are several tasks to address WFLY-8492 and one of them is related to IronJacamar.
In the thread dumps done when before we kill -9 the server because it did not shutdown in the expected time, we have a thread:
{code}
"ServerService Thread Pool -- 82" #322 prio=5 os_prio=31 tid=0x00007fcad286b800 nid=0x13007 waiting on condition [0x000070000c462000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000791e1cf20> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:375)
- locked <0x0000000791e1cf60> (a java.lang.Object)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:315)
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sessionStop(ActiveMQSessionContext.java:343)
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:662)
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:651)
at org.apache.activemq.artemis.jms.client.ActiveMQSession.stop(ActiveMQSession.java:1023)
at org.apache.activemq.artemis.jms.client.ActiveMQConnection.stop(ActiveMQConnection.java:321)
- locked <0x0000000791e1c360> (a org.apache.activemq.artemis.jms.client.ActiveMQXAConnection)
at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.destroyHandles(ActiveMQRAManagedConnection.java:229)
at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.destroy(ActiveMQRAManagedConnection.java:268)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.doDestroy(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1369)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.flush(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:882)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.shutdown(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1065)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.shutdown(AbstractPool.java:930)
- locked <0x0000000790f758d0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.shutdown(AbstractConnectionManager.java:286)
- locked <0x0000000790f75868> (a org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl)
at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService.unregisterAll(AbstractResourceAdapterDeploymentService.java:199)
at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService$3.run(AbstractResourceAdapterDeploymentService.java:353)
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}
When the server is asked to shutdown, IJ will flush its pools. In turn, this calls Artemis RA managed connection destroy() which will stop any underlying JMS connection.
The test is using a remote JMS that has been stopped and thus the underlying JMS connection will be blocked for some time.
I had a look at SemaphoreConcurrentLinkedDequeManagedConnectionPool#flush[1] and it is destroying the pool's connections sequentially.
This implies that the time to flush the pool can be potentially up to n * t where n is the number of connections managed by the pool and t is the timeout that each connections used when it is stopped.
In the test run, n = 20, t = 30s so we have to wait 10 minutes to the the pool completely flushed.
Would it be possible to flush the pool concurrently, so that the time to flush the pools would be close to t?
Something like:
{code}
destroy.parallelStream().forEach(clw -> doDestroy(clw));
{code}
With such a code, the time to flush the pool would be close to t.
In our test run, that would reduce the time to wait from 10 minutes to circa 30s.
Would there be any issue with parallelizing the flush of the pool in such way?
[1] https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/or...
was:
This is related to WFLY-8492 where WildFly server does not shutdown in a timely fashion. There are several tasks to address WFLY-8492 and one of them is related to IronJacamar.
In the thread dumps done when before we kill -9 the server because it did not shutdown in the expected time, we have a thread:
{code}
"ServerService Thread Pool -- 82" #322 prio=5 os_prio=31 tid=0x00007fcad286b800 nid=0x13007 waiting on condition [0x000070000c462000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000791e1cf20> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:375)
- locked <0x0000000791e1cf60> (a java.lang.Object)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:315)
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sessionStop(ActiveMQSessionContext.java:343)
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:662)
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:651)
at org.apache.activemq.artemis.jms.client.ActiveMQSession.stop(ActiveMQSession.java:1023)
at org.apache.activemq.artemis.jms.client.ActiveMQConnection.stop(ActiveMQConnection.java:321)
- locked <0x0000000791e1c360> (a org.apache.activemq.artemis.jms.client.ActiveMQXAConnection)
at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.destroyHandles(ActiveMQRAManagedConnection.java:229)
at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.destroy(ActiveMQRAManagedConnection.java:268)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.doDestroy(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1369)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.flush(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:882)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.shutdown(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1065)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.shutdown(AbstractPool.java:930)
- locked <0x0000000790f758d0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.shutdown(AbstractConnectionManager.java:286)
- locked <0x0000000790f75868> (a org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl)
at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService.unregisterAll(AbstractResourceAdapterDeploymentService.java:199)
at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService$3.run(AbstractResourceAdapterDeploymentService.java:353)
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}
When the server is asked to shutdown, IJ will flush its pools. In turn, this calls Artemis RA managed connection destroy() which will stop any underlying JMS connection.
The test is using a remote JMS that has been stopped and thus the underlying JMS connection will be blocked for some time.
I had a look at SemaphoreConcurrentLinkedDequeManagedConnectionPool#flush[1] and it is destroying the pool's connections sequentially.
This implies that the time to flush the pool is n * t where n is the number of connections managed by the pool and t is the timeout that each connections used when it is stopped.
In the test run, n = 20, t = 30s so we have to wait 10 minutes to the the pool completely flushed.
Would it be possible to flush the pool concurrently, so that the time to flush the pools would be close to t?
Something like:
{code}
destroy.parallelStream().forEach(clw -> doDestroy(clw));
{code}
With such a code, the time to flush the pool would be close to t.
In our test run, that would reduce the time to wait from 10 minutes to circa 30s.
Would there be any issue with parallelizing the flush of the pool in such way?
[1] https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/or...
> Parallelize flush of pools
> --------------------------
>
> Key: JBJCA-1353
> URL: https://issues.jboss.org/browse/JBJCA-1353
> Project: IronJacamar
> Issue Type: Enhancement
> Reporter: Jeff Mesnil
>
> This is related to WFLY-8492 where WildFly server does not shutdown in a timely fashion. There are several tasks to address WFLY-8492 and one of them is related to IronJacamar.
> In the thread dumps done when before we kill -9 the server because it did not shutdown in the expected time, we have a thread:
> {code}
> "ServerService Thread Pool -- 82" #322 prio=5 os_prio=31 tid=0x00007fcad286b800 nid=0x13007 waiting on condition [0x000070000c462000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0000000791e1cf20> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:375)
> - locked <0x0000000791e1cf60> (a java.lang.Object)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:315)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sessionStop(ActiveMQSessionContext.java:343)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:662)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:651)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.stop(ActiveMQSession.java:1023)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnection.stop(ActiveMQConnection.java:321)
> - locked <0x0000000791e1c360> (a org.apache.activemq.artemis.jms.client.ActiveMQXAConnection)
> at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.destroyHandles(ActiveMQRAManagedConnection.java:229)
> at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.destroy(ActiveMQRAManagedConnection.java:268)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.doDestroy(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1369)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.flush(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:882)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.shutdown(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1065)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.shutdown(AbstractPool.java:930)
> - locked <0x0000000790f758d0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.shutdown(AbstractConnectionManager.java:286)
> - locked <0x0000000790f75868> (a org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl)
> at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService.unregisterAll(AbstractResourceAdapterDeploymentService.java:199)
> at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService$3.run(AbstractResourceAdapterDeploymentService.java:353)
> 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}
> When the server is asked to shutdown, IJ will flush its pools. In turn, this calls Artemis RA managed connection destroy() which will stop any underlying JMS connection.
> The test is using a remote JMS that has been stopped and thus the underlying JMS connection will be blocked for some time.
> I had a look at SemaphoreConcurrentLinkedDequeManagedConnectionPool#flush[1] and it is destroying the pool's connections sequentially.
> This implies that the time to flush the pool can be potentially up to n * t where n is the number of connections managed by the pool and t is the timeout that each connections used when it is stopped.
> In the test run, n = 20, t = 30s so we have to wait 10 minutes to the the pool completely flushed.
> Would it be possible to flush the pool concurrently, so that the time to flush the pools would be close to t?
> Something like:
> {code}
> destroy.parallelStream().forEach(clw -> doDestroy(clw));
> {code}
> With such a code, the time to flush the pool would be close to t.
> In our test run, that would reduce the time to wait from 10 minutes to circa 30s.
> Would there be any issue with parallelizing the flush of the pool in such way?
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/or...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3084) Permission check failed for RemotingPermission "createEndpoint" even if it is granted
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3084?page=com.atlassian.jira.plugi... ]
Ondrej Lukas closed WFCORE-3084.
--------------------------------
Resolution: Rejected
Closing as not a bug. It was caused by missing dependency 'org.jboss.remoting3' in deployment.
> Permission check failed for RemotingPermission "createEndpoint" even if it is granted
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-3084
> URL: https://issues.jboss.org/browse/WFCORE-3084
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta28
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> In case when deployment which needs RemotingPermission "createEndpoint" has granted "org.jboss.remoting3.security.RemotingPermission" "createEndpoint" in META-INT/permissions.xml then it still fails with:
> {code}
> java.io.IOException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/direct-call-dep.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.direct-call-dep.war" from Service Module Loader")
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> at com.redhat.eap.qe.elytron.authnctx.DirectCallServlet.doGet(DirectCallServlet.java:84)
> ... 42 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/direct-call-dep.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.direct-call-dep.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 org.jboss.remoting3.EndpointBuilder.build(EndpointBuilder.java:90)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:128)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> ... 44 more
> {code}
> When {{java.security.AllPermission}} is granted to deployment (instead of RemotingPermission "createEndpoint") then it works fine. See 'Steps to Reproduce' for more details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JBJCA-1353) Parallelize flush of pools
by Jeff Mesnil (JIRA)
Jeff Mesnil created JBJCA-1353:
----------------------------------
Summary: Parallelize flush of pools
Key: JBJCA-1353
URL: https://issues.jboss.org/browse/JBJCA-1353
Project: IronJacamar
Issue Type: Enhancement
Reporter: Jeff Mesnil
This is related to WFLY-8492 where WildFly server does not shutdown in a timely fashion. There are several tasks to address WFLY-8492 and one of them is related to IronJacamar.
In the thread dumps done when before we kill -9 the server because it did not shutdown in the expected time, we have a thread:
{code}
"ServerService Thread Pool -- 82" #322 prio=5 os_prio=31 tid=0x00007fcad286b800 nid=0x13007 waiting on condition [0x000070000c462000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000791e1cf20> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:375)
- locked <0x0000000791e1cf60> (a java.lang.Object)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:315)
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sessionStop(ActiveMQSessionContext.java:343)
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:662)
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:651)
at org.apache.activemq.artemis.jms.client.ActiveMQSession.stop(ActiveMQSession.java:1023)
at org.apache.activemq.artemis.jms.client.ActiveMQConnection.stop(ActiveMQConnection.java:321)
- locked <0x0000000791e1c360> (a org.apache.activemq.artemis.jms.client.ActiveMQXAConnection)
at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.destroyHandles(ActiveMQRAManagedConnection.java:229)
at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.destroy(ActiveMQRAManagedConnection.java:268)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.doDestroy(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1369)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.flush(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:882)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.shutdown(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1065)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.shutdown(AbstractPool.java:930)
- locked <0x0000000790f758d0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.shutdown(AbstractConnectionManager.java:286)
- locked <0x0000000790f75868> (a org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl)
at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService.unregisterAll(AbstractResourceAdapterDeploymentService.java:199)
at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService$3.run(AbstractResourceAdapterDeploymentService.java:353)
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}
When the server is asked to shutdown, IJ will flush its pools. In turn, this calls Artemis RA managed connection destroy() which will stop any underlying JMS connection.
The test is using a remote JMS that has been stopped and thus the underlying JMS connection will be blocked for some time.
I had a look at SemaphoreConcurrentLinkedDequeManagedConnectionPool#flush[1] and it is destroying the pool's connections sequentially.
This implies that the time to flush the pool is n * t where n is the number of connections managed by the pool and t is the timeout that each connections used when it is stopped.
In the test run, n = 20, t = 30s so we have to wait 10 minutes to the the pool completely flushed.
Would it be possible to flush the pool concurrently, so that the time to flush the pools would be close to t?
Something like:
{code}
destroy.parallelStream().forEach(clw -> doDestroy(clw));
{code}
With such a code, the time to flush the pool would be close to t.
In our test run, that would reduce the time to wait from 10 minutes to circa 30s.
Would there be any issue with parallelizing the flush of the pool in such way?
[1] https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/or...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ]
Peter Palaga commented on ELY-1295:
-----------------------------------
I was able to figure out how to avoid the {{NoSuchAlgorithmException}} reported above through this fix: https://github.com/ppalaga/wildfly-elytron/commit/7d6b37230d7c277f0a96d36...
Basically a similar hack is necessary for IBM JDK like we already have for Oracle JDK. The {{JceSecurity}} analogon is obfuscated in IBM JDK. It is called {{javax.crypto.b}} and the map field caching the validation results is called {{j}}.
It can still be manipulated via reflection to make IBM JDK think that the code in {{target/classes}} passed the cert validation.
But having this workaround in place does not make the whole test pass. For {{format=PKCS12}}, there is a new exception that I was not able to solve in any way:
{code}
java.security.UnrecoverableKeyException: Get Key failed: Get Key failed: Unrecognized key type.
at com.ibm.crypto.provider.PKCS12KeyStoreOracle.engineGetKey(Unknown Source)
at com.ibm.crypto.provider.PKCS12KeyStoreOracle.engineGetEntry(Unknown Source)
at java.security.KeyStore.getEntry(KeyStore.java:1532)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:155)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
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 mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:156)
at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:65)
at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
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.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
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.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Caused by: java.security.UnrecoverableKeyException: Get Key failed: Unrecognized key type.
... 45 more
{code}
I am giving up here unless somebody has an idea how to proceed.
> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
> Key: ELY-1295
> URL: https://issues.jboss.org/browse/ELY-1295
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Peter Palaga
> Assignee: Darran Lofthouse
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> at java.security.KeyStore.getEntry(KeyStore.java:1532)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> ... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1280) GSSAPI only identities credential if we actually have one.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1280?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse resolved ELY-1280.
-----------------------------------
Fix Version/s: 1.1.0.CR3
Resolution: Done
> GSSAPI only identities credential if we actually have one.
> ----------------------------------------------------------
>
> Key: ELY-1280
> URL: https://issues.jboss.org/browse/ELY-1280
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.CR3
>
>
> In ER2 kerberos authentication in remoting does not work with IBM java. I see same error in 2 scenarios:
> * Elytron kerberos authentication for management interface - CLI
> * Elytron kerberos authenticaiton for EJB
> This issue (reproducer/description)is based on CLI case. As it seems to me it is caused by same error.
> {code}
> 13:15:25,038 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) Command:[/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/../tests/target/dist/jboss-eap/bin/jboss-cli.sh, -Djboss.cli.config=/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/../tests/target/dist/jboss-eap/bin/jboss-cli.xml, -c, --controller=remote+http://localhost.localdomain:9990, --timeout=60000, -Djavax.security.auth.useSubjectCredsOnly=false, -Djava.security.krb5.conf=/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb5-4030706113084817464.conf, -Dsun.security.krb5.debug=true, -Dcom.ibm.security.jgss.debug=all, -Dcom.ibm.security.krb5.Krb5Debug=all, -Djavax.net.ssl.trustStore=/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/KerberosCLITestCase/localhost.keystore, :whoami]
> 13:15:26,352 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Initialized connection from /127.0.0.1:41690 to /127.0.0.1:9990 with options {org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL=>remote}
> 13:15:26,352 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Accepted connection from /127.0.0.1:41690 to localhost.localdomain/127.0.0.1:9990
> 13:15:26,353 TRACE [org.jboss.remoting.remote] (management I/O-1) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@6a1d77d9
> 13:15:26,353 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Sent 28 bytes
> 13:15:26,353 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Flushed channel
> 13:15:26,375 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) No buffers in queue for message header
> 13:15:26,375 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Allocated fresh buffers
> 13:15:26,375 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received 56 bytes
> 13:15:26,375 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 13:15:26,375 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Received java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capabilities request
> 13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: version 1
> 13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: remote endpoint name "cli-client"
> 13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: message close protocol supported
> 13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: remote version is "5.0.0.CR4-redhat-1"
> 13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: remote channels in is "40"
> 13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: remote channels out is "40"
> 13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received capability: authentication service
> 13:15:26,376 TRACE [org.jboss.remoting.remote.server] (management I/O-1) No EXTERNAL mechanism due to lack of SSL
> 13:15:26,380 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Added mechanism GSSAPI
> 13:15:26,381 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Added mechanism PLAIN
> 13:15:26,381 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Sent 81 bytes
> 13:15:26,381 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Flushed channel
> 13:15:27,194 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) No buffers in queue for message header
> 13:15:27,194 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Allocated fresh buffers
> 13:15:27,194 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received 583 bytes
> 13:15:27,194 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=579 cap=8192]
> 13:15:27,194 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Received java.nio.HeapByteBuffer[pos=0 lim=579 cap=8192]
> 13:15:27,194 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received authentication request
> 13:15:27,194 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback type='SASL' name='GSSAPI' host-name='localhost.localdomain' protocol='remote'
> 13:15:27,194 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback type='SASL' name='GSSAPI' host-name='localhost.localdomain' protocol='remote'
> 13:15:27,197 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-1) configuredMaxReceiveBuffer=16777215
> 13:15:27,197 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-1) relaxComplianceChecks=false
> 13:15:27,197 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-1) QOP={AUTH}
> 13:15:27,197 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-1) Obtaining GSSCredential for the service from callback handler...
> 13:15:27,197 TRACE [org.wildfly.security] (management I/O-1) No valid cached credential, obtaining new one...
> 13:15:27,198 TRACE [org.wildfly.security] (management I/O-1) Logging in using LoginContext and subject [Subject:
> ]
> 13:15:27,218 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: debug=true
> 13:15:27,218 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: principal=remote/localhost.localdomain(a)JBOSS.ORG
> 13:15:27,218 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: credsType=accept only
> 13:15:27,218 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 config: useDefaultCcache=false (default)
> 13:15:27,219 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 config: useCcache=null
> 13:15:27,219 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 config: useDefaultKeytab=false
> 13:15:27,220 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 config: useKeytab=/home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb.4304838673032362747.keytab
> 13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: forwardable=false (default)
> 13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: renewable=false (default)
> 13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: proxiable=false (default)
> 13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: tryFirstPass=false (default)
> 13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: useFirstPass=false (default)
> 13:15:27,224 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: moduleBanner=false (default)
> 13:15:27,225 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 JAAS config: interactive login? no
> 13:15:27,225 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 Try keytab for principal=remote/localhost.localdomain(a)JBOSS.ORG
> 13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 No Kerberos creds in keytab for principal remote/localhost.localdomain(a)JBOSS.ORG
> 13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 Login successful
> 13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 kprincipal : remote/localhost.localdomain(a)JBOSS.ORG
> 13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 remote/localhost.localdomain(a)JBOSS.ORG added to Subject
> 13:15:27,327 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 KeyTab added to Subject
> 13:15:27,328 INFO [stdout] (management I/O-1) [JGSS_DBG_CRED] management I/O-1 No keys to add to Subject for remote/localhost.localdomain(a)JBOSS.ORG
> 13:15:27,328 TRACE [org.wildfly.security] (management I/O-1) Logging in using LoginContext and subject [Subject:
> Principal: remote/localhost.localdomain(a)JBOSS.ORG
> Private Credential: /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb.4304838673032362747.keytab for remote/localhost.localdomain(a)JBOSS.ORG
> ] succeed
> 13:15:27,329 TRACE [org.wildfly.security] (management I/O-1) Creating GSSName for Principal 'remote/localhost.localdomain(a)JBOSS.ORG'
> 13:15:27,337 TRACE [org.wildfly.security] (management I/O-1) Obtained GSSCredentialCredential [org.wildfly.security.credential.GSSKerberosCredential@b7cba9ed]
> 13:15:27,337 TRACE [org.wildfly.security] (management I/O-1) Handling ServerCredentialCallback: successfully obtained credential type type=class org.wildfly.security.credential.GSSKerberosCredential, algorithm=null, params=null
> 13:15:27,339 TRACE [org.wildfly.security] (management I/O-1) Created SaslServer for mechanism GSSAPI and protocol remote
> 13:15:27,339 TRACE [org.wildfly.security] (management I/O-1) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@7e6923d] for mechanism [GSSAPI]
> 13:15:27,339 TRACE [org.jboss.remoting.endpoint] (management I/O-1) Allocated tick to 9 of endpoint "localhost:MANAGEMENT" <43fd3bb3> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@48dbe42)
> 13:15:27,599 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-6) Negotiated mechanism 1.2.840.113554.1.2.2
> 13:15:27,599 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-6) No response so triggering next state immediately.
> 13:15:27,599 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-6) Not offering a security layer so zero length.
> 13:15:27,601 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-6) Transitioning to receive chosen security layer from client
> 13:15:27,601 TRACE [org.jboss.remoting.remote.server] (management task-6) Server sending authentication challenge
> 13:15:27,601 TRACE [org.jboss.remoting.remote] (management task-6) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Authentication@aa1379f
> 13:15:27,601 TRACE [org.jboss.remoting.endpoint] (management task-6) Resource closed count 00000008 of endpoint "localhost:MANAGEMENT" <43fd3bb3> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@48dbe42)
> 13:15:27,601 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Sent 37 bytes
> 13:15:27,601 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Flushed channel
> 13:15:27,608 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) No buffers in queue for message header
> 13:15:27,608 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Allocated fresh buffers
> 13:15:27,608 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received 37 bytes
> 13:15:27,608 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=33 cap=8192]
> 13:15:27,608 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Received java.nio.HeapByteBuffer[pos=0 lim=33 cap=8192]
> 13:15:27,608 TRACE [org.jboss.remoting.remote.server] (management I/O-1) Server received authentication response
> 13:15:27,608 TRACE [org.jboss.remoting.endpoint] (management I/O-1) Allocated tick to 9 of endpoint "localhost:MANAGEMENT" <43fd3bb3> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@48dbe42)
> 13:15:27,609 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-7) Client selected security layer AUTH, with maxBuffer of 0
> 13:15:27,610 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-7) Authentication ID=jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG, Authorization ID=jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG
> 13:15:27,610 TRACE [org.wildfly.security] (management task-7) Principal assigning: [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG], pre-realm rewritten: [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c], realm name: [fileSystemRealm], post-realm rewritten: [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c], realm rewritten: [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c]
> 13:15:27,611 TRACE [org.wildfly.security] (management task-7) Role mapping: principal [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles []
> 13:15:27,611 TRACE [org.wildfly.security] (management task-7) Authorizing principal jdukec4c36a8b-173f-41e7-af5b-7492f91a404c.
> 13:15:27,611 TRACE [org.wildfly.security] (management task-7) Authorizing against the following attributes: [] => []
> 13:15:27,611 TRACE [org.wildfly.security] (management task-7) Permission mapping: identity [jdukec4c36a8b-173f-41e7-af5b-7492f91a404c] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 13:15:27,611 TRACE [org.wildfly.security] (management task-7) Authorization succeed
> 13:15:27,611 TRACE [org.wildfly.security] (management task-7) RunAs authorization succeed - the same identity
> 13:15:27,611 TRACE [org.wildfly.security] (management task-7) Handling AuthorizeCallback: authenticationID = jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG authorizationID = jdukec4c36a8b-173f-41e7-af5b-7492f91a404c(a)JBOSS.ORG authorized = true
> 13:15:27,613 TRACE [org.jboss.remoting.remote.server] (management task-7) Server sending authentication rejected: java.lang.IllegalArgumentException: Parameter 'gssCredential' may not be null
> at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:70)
> at org.wildfly.common.Assert.checkNotNullParam(Assert.java:48)
> at org.wildfly.security.credential.GSSKerberosCredential.<init>(GSSKerberosCredential.java:53)
> at org.wildfly.security.credential.GSSKerberosCredential.<init>(GSSKerberosCredential.java:43)
> at org.wildfly.security.sasl.gssapi.GssapiServer.evaluateMessage(GssapiServer.java:284)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.gssapi.GssapiServer.evaluateResponse(GssapiServer.java:122)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:468)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$$Lambda$905.00000000201F9C40.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> 13:15:27,614 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-7) dispose
> 13:15:27,614 TRACE [org.wildfly.security] (management task-7) Handling AuthenticationCompleteCallback: fail
> 13:15:27,614 TRACE [org.jboss.remoting.remote] (management task-7) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@18fce815
> 13:15:27,614 TRACE [org.jboss.remoting.endpoint] (management task-7) Resource closed count 00000008 of endpoint "localhost:MANAGEMENT" <43fd3bb3> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@48dbe42)
> 13:15:27,614 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Sent 5 bytes
> 13:15:27,614 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Flushed channel
> 13:15:27,615 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) No buffers in queue for message header
> 13:15:27,615 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Alloca
> {code}
> Test pass just fine on Oracle/OpenJDK JDK
> In stacktrace there is involved code introduced by https://github.com/wildfly-security/wildfly-elytron/commit/faf1aff340c3a2... .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months