[JBoss JIRA] (JBJCA-1353) Parallelize flush of pools
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1353?page=com.atlassian.jira.plugin... ]
Stefano Maestri commented on JBJCA-1353:
----------------------------------------
I don't see any problem in this. As commented in [~jmesnil]'s PR it seems it makes a Byteman test failing (Timeout failure). Otherwise LGTM
> Parallelize flush of pools
> --------------------------
>
> Key: JBJCA-1353
> URL: https://issues.jboss.org/browse/JBJCA-1353
> Project: IronJacamar
> Issue Type: Enhancement
> Reporter: Jeff Mesnil
> Assignee: Flavia Rainone
>
> 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] (JBJCA-1353) Parallelize flush of pools
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1353?page=com.atlassian.jira.plugin... ]
Stefano Maestri edited comment on JBJCA-1353 at 7/24/17 9:44 AM:
-----------------------------------------------------------------
I don't see any problem in this. As commented in [~jmesnil]'s PR it seems it makes a Byteman test failing (Timeout failure). Otherwise LGTM
PR:
https://github.com/ironjacamar/ironjacamar/pull/631
was (Author: maeste):
I don't see any problem in this. As commented in [~jmesnil]'s PR it seems it makes a Byteman test failing (Timeout failure). Otherwise LGTM
> Parallelize flush of pools
> --------------------------
>
> Key: JBJCA-1353
> URL: https://issues.jboss.org/browse/JBJCA-1353
> Project: IronJacamar
> Issue Type: Enhancement
> Reporter: Jeff Mesnil
> Assignee: Flavia Rainone
>
> 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] (JBJCA-1353) Parallelize flush of pools
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1353?page=com.atlassian.jira.plugin... ]
Stefano Maestri edited comment on JBJCA-1353 at 7/24/17 9:44 AM:
-----------------------------------------------------------------
[~flavia.rainone]: I don't see any problem in this. As commented in [~jmesnil]'s PR it seems it makes a Byteman test failing (Timeout failure). Otherwise LGTM
PR:
https://github.com/ironjacamar/ironjacamar/pull/631
was (Author: maeste):
I don't see any problem in this. As commented in [~jmesnil]'s PR it seems it makes a Byteman test failing (Timeout failure). Otherwise LGTM
PR:
https://github.com/ironjacamar/ironjacamar/pull/631
> Parallelize flush of pools
> --------------------------
>
> Key: JBJCA-1353
> URL: https://issues.jboss.org/browse/JBJCA-1353
> Project: IronJacamar
> Issue Type: Enhancement
> Reporter: Jeff Mesnil
> Assignee: Flavia Rainone
>
> 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-3093) Unclear failure description when removing elytron policy referenced as the default-policy
by Martin Stefanko (JIRA)
Martin Stefanko created WFCORE-3093:
---------------------------------------
Summary: Unclear failure description when removing elytron policy referenced as the default-policy
Key: WFCORE-3093
URL: https://issues.jboss.org/browse/WFCORE-3093
Project: WildFly Core
Issue Type: Bug
Components: Security
Affects Versions: 3.0.0.Beta28
Reporter: Martin Stefanko
Assignee: Martin Stefanko
when user wants to remove a jacc-policy referenced as default-policy, for example
{code}
/profile=full/subsystem=elytron/policy=policy1:read-resource
{
"outcome" => "success",
"result" => {
"custom-policy" => undefined,
"default-policy" => "policy-teste",
"jacc-policy" => [
{
"name" => "policy-teste",
"module" => "modulo-policy",
"configuration-factory" => "OutroFactory1",
"policy" => "PolicyM2"
},
{
"name" => "policy123",
"module" => "modulo-123",
"configuration-factory" => "OutroFactory1",
"policy" => "PolicyM2"
},
{
"name" => "outro_policy123",
"module" => "modulo-123",
"configuration-factory" => "OutroFactory1",
"policy" => "PolicyM2"
}
]
}
}
{code}
{code}
/profile=full/subsystem=elytron/policy=policy1:list-remove(name=jacc-policy,index=0)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "Could find policy provider with name [policy-teste]"},
"rolled-back" => true
}
{code}
The message should say the jacc-policy is used as default-policy.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JBJCA-1353) Parallelize flush of pools
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1353?page=com.atlassian.jira.plugin... ]
Flavia Rainone commented on JBJCA-1353:
---------------------------------------
I am not sure if there is an issue involved in parallelizing, but I'm investigating and seeing what can be done. [~maeste], please let me know if you see any problem that will prevent us from doing this optimization.
> Parallelize flush of pools
> --------------------------
>
> Key: JBJCA-1353
> URL: https://issues.jboss.org/browse/JBJCA-1353
> Project: IronJacamar
> Issue Type: Enhancement
> Reporter: Jeff Mesnil
> Assignee: Flavia Rainone
>
> 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] (JBJCA-1353) Parallelize flush of pools
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1353?page=com.atlassian.jira.plugin... ]
Flavia Rainone reassigned JBJCA-1353:
-------------------------------------
Assignee: Flavia Rainone
> Parallelize flush of pools
> --------------------------
>
> Key: JBJCA-1353
> URL: https://issues.jboss.org/browse/JBJCA-1353
> Project: IronJacamar
> Issue Type: Enhancement
> Reporter: Jeff Mesnil
> Assignee: Flavia Rainone
>
> 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] (ELY-1047) CS tool, meaningless error msg when I create credential store storage file under OracleJDK and access to it under IBMJDK.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1047?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev resolved ELY-1047.
--------------------------------
Resolution: Rejected
JBEAP-10051 is rejected
> CS tool, meaningless error msg when I create credential store storage file under OracleJDK and access to it under IBMJDK.
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1047
> URL: https://issues.jboss.org/browse/ELY-1047
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> When I create credential store storage file under OracleJDK or OpenJDK and then I want to access to it under IBMJDK I get meaningless error message about this.
> I expect some error message about that you must use to access same JDK as was used for creation storage file.
> *How to reproduce*
> Create credential store storage file with OracleJDK (or openJDK)
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --add moje --secret asdfasdf --location="PATH/TO/store01.jceks" --uri "cr-store://store01.jceks?modifiable=true;create=true;keyStoreType=JCEKS" --password=pass123 --summary
> {code}
> Try to list aliases with IBMJDK
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --aliases --location="/PATH/TO/store01.jceks" --uri "cr-store://store01.jceks?modifiable=true;create=true;keyStoreType=JCEKS" --password=pass123 --summary
> ELY09526: Unable to initialize credential store
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1673) Add tests for uncovered areas for AST nodes in kie-dmn-feel module
by Tibor Zimányi (JIRA)
Tibor Zimányi created DROOLS-1673:
-------------------------------------
Summary: Add tests for uncovered areas for AST nodes in kie-dmn-feel module
Key: DROOLS-1673
URL: https://issues.jboss.org/browse/DROOLS-1673
Project: Drools
Issue Type: Enhancement
Components: dmn engine
Affects Versions: 7.1.0.Final
Reporter: Tibor Zimányi
Assignee: Tibor Zimányi
Fix For: 7.2.0.Final
There are new uncovered lines in kie-dmn-feel module AST classes. There should be tests added for all possible uncovered lines.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months