[JBoss JIRA] (WFLY-9138) Warning message mistake
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9138?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-9138.
----------------------------------
Resolution: Duplicate Issue
https://issues.jboss.org/browse/WFLY-7228
> Warning message mistake
> -----------------------
>
> Key: WFLY-9138
> URL: https://issues.jboss.org/browse/WFLY-9138
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.Final
> Reporter: Baturman Şen
> Assignee: Stuart Douglas
> Priority: Trivial
>
> I am not native english speaker but, following warning message should be fixed.
> {panel:title=Original Message}
> 09:52:31,242 WARN [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0013: Deployment deployment "xxxx" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations)
> {panel}
> {panel:title=Fixed Message}
> 09:52:31,242 WARN [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0013: Deployment "xxxx" contains CDI annotations but no bean archive was found. (No beans.xml nor class with bean defining annotations)
> {panel}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 1 month
[JBoss JIRA] (WFCORE-3103) Embedded server doesn't close open file handles
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3103:
----------------------------------------
Assignee: Ken Wills (was: Brian Stansberry)
[~luck3y] I'm going to pass this one over to you.
https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... has my experiment on that, but the testsuite does not pass. To get meaningful behavior with it you have to run with David's jboss-modules branch with the MODULES-301 commit in it.
For sure https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... or something like it has to happen, otherwise we close the boot module loader which is wrongness. But when I make that change things blow up.
> Embedded server doesn't close open file handles
> -----------------------------------------------
>
> Key: WFCORE-3103
> URL: https://issues.jboss.org/browse/WFCORE-3103
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules
> Reporter: Jan Blizňák
> Assignee: Ken Wills
>
> When embedded server is started programatically (eg. via CLI wrapper) with specified jboss home, JARs from that path are opened via classloader. But these open handles are never released even after embedded server is stopped.
> This causes problem in situation eg. when you want to delete that jboss home. This is exactly one of the scenarios used in EAP installer, you are not allowed to delete open files on Windows - see JBEAP-1404.
> I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking
> Run it with:
> mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=ModulesFileLockingTestCase
> Manual steps to reproduce in Java code:
> * start a CLI wrapper
> * start embed-server from given server path
> * stop embed-server
> * terminate CLI wrapper
> * try to delete given server path
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 1 month
[JBoss JIRA] (DROOLS-1685) Improve performance of rules using "or" in LHS
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1685?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1685:
-------------------------------------
The rulesets you pasted are not totally equivalent. In the first one you have
{code}
entity.entityTypeId in ( 291262 )
{code}
while in second
{code}
entity.entityTypeId == 291262
{code}
I think this could make a huge difference performance wise because only the second constraint can be indexed. If your problem persists after having fixed this difference please send a complete reproducer so I could further investigate this problem.
> Improve performance of rules using "or" in LHS
> ----------------------------------------------
>
> Key: DROOLS-1685
> URL: https://issues.jboss.org/browse/DROOLS-1685
> Project: Drools
> Issue Type: Enhancement
> Components: core engine, kie server
> Affects Versions: 6.5.0.Final
> Reporter: Russell Morrisey
> Assignee: Mario Fusco
>
> The following two rulesets produce the same output, but their performance differs dramatically.
> My understanding is that the two rulesets should be equivalent to one another. It seems like the 'or' operation must be handled inefficiently by the engine. Is there anything that can be improved the engine's performance in this case?
> Ruleset #1 takes ~3 seconds to execute on my local machine (for a dataset with 3 entities, 1 service ordered each). Ruleset #2 runs in ~200 ms.
> *Ruleset 1*
> {code:java}
> rule "Rule183"
> dialect "mvel"
> when
> $entity : Entity( )
> ( $service : ServiceOrdered( serviceId == "FORM" , entity == $entity , entity.entityTypeId in ( 291262, 291275, 291277 ) ) or $service : ServiceOrdered( serviceId == "DISSO" , entity == $entity , entity.entityTypeId in ( 291262 ) , stateId == 290864 ) )
> $r1 : QuestionDefinition( id == 590 )
> then
> Question fact0 = new Question();
> fact0.setQuestionDefinition( $r1 );
> fact0.setEntity( $entity );
> insert( fact0 );
> end
> {code}
> *Ruleset 2*
> {code:java}
> rule "Rule183"
> dialect "mvel"
> when
> $entity : Entity( )
> $service : ServiceOrdered( serviceId == "FORM" , entity == $entity , entity.entityTypeId in ( 291262, 291275, 291277 ) )
> $r1 : QuestionDefinition( id == 590 )
> then
> Question fact0 = new Question();
> fact0.setQuestionDefinition( $r1 );
> fact0.setEntity( $entity );
> insert( fact0 );
> end
> {code}
> {code}
> rule "Rule183-2"
> dialect "mvel"
> when
> $entity : Entity( )
> $service : ServiceOrdered( serviceId == "DISSO" , entity == $entity , entity.entityTypeId == 291262 , stateId == 290864 )
> $r1 : QuestionDefinition( id == 590 )
> then
> Question fact0 = new Question();
> fact0.setQuestionDefinition( $r1 );
> fact0.setEntity( $entity );
> insert( fact0 );
> end
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 1 month
[JBoss JIRA] (ELY-1308) Alias from dependent credential store is not avalaible on server start
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1308?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1308:
----------------------------
Need Info from: (was: Peter Skopek)
> Alias from dependent credential store is not avalaible on server start
> ----------------------------------------------------------------------
>
> Key: ELY-1308
> URL: https://issues.jboss.org/browse/ELY-1308
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.1.0.CR2
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 1.2.0.Beta1
>
>
> BouncyCastle external CredentialStore fail to store secret:
> {code}
> KeyStoreCredentialStore: flushing failed: java.lang.NullPointerException
> at org.bouncycastle.jcajce.provider.BaseCipher.engineGetParameters(Unknown Source)
> at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1020)
> at javax.crypto.Cipher.init(Cipher.java:1245)
> at javax.crypto.Cipher.init(Cipher.java:1186)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.saveSecretKey(KeyStoreCredentialStore.java:1299)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.store(KeyStoreCredentialStore.java:1283)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.flush(KeyStoreCredentialStore.java:779)
> at org.wildfly.security.credential.store.CredentialStore.flush(CredentialStore.java:364)
> at org.wildfly.extension.elytron.CredentialStoreResourceDefinition.storeSecret(CredentialStoreResourceDefinition.java:517)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 1 month
[JBoss JIRA] (ELY-1313) Alias from dependent credential store is not avalaible on server start
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1313?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1313:
----------------------------
Need Info from: (was: Peter Skopek)
> Alias from dependent credential store is not avalaible on server start
> ----------------------------------------------------------------------
>
> Key: ELY-1313
> URL: https://issues.jboss.org/browse/ELY-1313
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.1.0.CR2
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> *This is backport of ELY-1308*
> BouncyCastle external CredentialStore fail to store secret:
> {code}
> KeyStoreCredentialStore: flushing failed: java.lang.NullPointerException
> at org.bouncycastle.jcajce.provider.BaseCipher.engineGetParameters(Unknown Source)
> at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1020)
> at javax.crypto.Cipher.init(Cipher.java:1245)
> at javax.crypto.Cipher.init(Cipher.java:1186)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.saveSecretKey(KeyStoreCredentialStore.java:1299)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.store(KeyStoreCredentialStore.java:1283)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.flush(KeyStoreCredentialStore.java:779)
> at org.wildfly.security.credential.store.CredentialStore.flush(CredentialStore.java:364)
> at org.wildfly.extension.elytron.CredentialStoreResourceDefinition.storeSecret(CredentialStoreResourceDefinition.java:517)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 1 month
[JBoss JIRA] (WFLY-8492) Cannot cleanly shutdown server disconnected inbound/outbound connections
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8492?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-8492.
-------------------------------
Resolution: Done
> Cannot cleanly shutdown server disconnected inbound/outbound connections
> ------------------------------------------------------------------------
>
> Key: WFLY-8492
> URL: https://issues.jboss.org/browse/WFLY-8492
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 11.0.0.Beta1
>
>
> Customer impact: Server will not be possible to cleanly shutdown and must be killed. No simple management operation command which EAP provides can be used. Similar issue was reported by customers/users in the past and had to be solved by support.
> Test Scenario:
> * Start server 1 with queues InQueue and OutQueue
> * Start server 2 with MDB consuming messages from InQueue and for each message sending 1 new message to OutQueue in XA transaction
> * Send messages to InQueue to server 1
> * When MDB is processing messages then cleanly shutdown server 1
> * Cleanly shutdown server 2 with MDB
> Result:
> Server 2 does not shutdown.
> Expected Result:
> Server 2 with MDB will shutdown fast ( < 1 min).
> Investigation:
> Thread dump (attached) on server 2 shows types of waiting threads:
> {code}
> "Thread-6 (ActiveMQ-client-global-threads-304296137)" #193 daemon prio=5 os_prio=0 tid=0x00007fc63c6d4000 nid=0x924 waiting on condition [0x00007fc5d6e0c000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fda5f5f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.waitForFailOver(ChannelImpl.java:250)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:356)
> - locked <0x00000000fda5f618> (a java.lang.Object)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:318)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(ActiveMQSessionContext.java:383)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1173)
> at org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperStatImpl.end(XAResourceWrapperStatImpl.java:96)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:337)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1674)
> - locked <0x00000000fdb54128> (a com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:124)
> at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1298)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:134)
> at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:99)
> at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:73)
> at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:69)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.handle(AbstractInvocationHandler.java:60)
> at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:135)
> at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
> at org.jboss.qa.hornetq.apps.mdb.MdbWithRemoteOutQueueToContaniner1$$$endpoint1.afterDelivery(Unknown Source)
> at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:314)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> and:
> {code}
> "Thread-21 (ActiveMQ-client-global-threads-304296137)" #196 daemon prio=5 os_prio=0 tid=0x00007fc62c040800 nid=0x928 waiting on condition [0x00007fc5d6a08000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fd4bc8a8> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.waitOnLatch(ActiveMQClientProtocolManager.java:136)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:819)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:744)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:504)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$500(ClientSessionFactoryImpl.java:72)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1165)
> at org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:67)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:207)
> at org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:215)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:996)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Those threads should be notified of server shutdown and "gracefully" stop do what they're doing. In case 1st thread:
> {{at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.waitForFailOver(ChannelImpl.java:250)}}
> there is problem in code:
> {code}
> failoverCondition.await();
> {code}
> This should be silently interrupted when component is stopping.
> 2nd thread has problem that while() cycle does not finish when component is stopping:
> {code}
> while (clientProtocolManager.isAlive()) {
> ...
> try {
> if (clientProtocolManager.waitOnLatch(interval)) {
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 1 month