[JBoss JIRA] (WFLY-12077) Transaction could not handle remote EJB invocation even if the transaction is not used remote
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-12077?page=com.atlassian.jira.plugin... ]
Tomasz Adamski commented on WFLY-12077:
---------------------------------------
[~wdfink] [~mmusgrov] [~ochaloup] I have proposed the PR: https://github.com/wildfly/wildfly-transaction-client/pull/76
I have checked that the error in the reproducer does not occur.
> Transaction could not handle remote EJB invocation even if the transaction is not used remote
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-12077
> URL: https://issues.jboss.org/browse/WFLY-12077
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: Regression
> Attachments: reproducer.zip
>
>
> An EJB marked as BMT which start a Tx and invoke a CMT managed Bean annotated with REQUIRES_NEW will fail if the BMT bean will show unexpected Arjuna WARN messages and the Tx seems not finished correctly.
> The same works in former releases.
> WARN [com.arjuna.ats.jta] (default task-2) ARJUNA016129: Could not end XA resource Subordinate XAResource at http-remoting://localhost:8180: javax.transaction.xa.XAException: WFTXN0029: The peer threw an XA exception
> at org.wildfly.transaction.client.provider.remoting.TransactionClientChannel.setRollbackOnly(TransactionClientChannel.java:167)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.end(RemotingRemoteTransactionPeer.java:158)
> at org.wildfly.transaction.client.SubordinateXAResource.end(SubordinateXAResource.java:138)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.doEnd(TransactionImple.java:1088)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.endAssociation(TransactionImple.java:1059)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.endAssociation(XAResourceRecord.java:1286)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:313)
> 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)
> 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:1370)
> 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:109)
> at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83)
> at org.wildfly.transaction.client.LocalUserTransaction.rollback(LocalUserTransaction.java:58)
> at xa.transaction.BeanA.testRemoteCMTxnFailure(BeanA.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: Remote exception javax.transaction.xa.XAException
> Public fields:
> errorCode=-4
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.lambda$handleXaTxnRollbackOnly$3(TransactionServerChannel.java:398)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsObjIntConsumer(SecurityIdentity.java:381)
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.handleXaTxnRollbackOnly(TransactionServerChannel.java:394)
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel$ReceiverImpl.handleMessage(TransactionServerChannel.java:132)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:942)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> ... 1 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-4059) Unable to test dmn context
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4059?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-4059:
-------------------------------------
I check this issue with the PR for DROOLS-3806 and can confirm it will be resolved by changes there.
> Unable to test dmn context
> --------------------------
>
> Key: DROOLS-4059
> URL: https://issues.jboss.org/browse/DROOLS-4059
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.22.0.Final
> Reporter: Jozef Marko
> Assignee: Daniele Zonca
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: Screenshot from 2019-05-21 10-37-01.png, Screenshot from 2019-05-21 10-37-22.png, dmn.zip
>
>
> There is issue with scenario, that verifies dmn context. The attached scenario was created in the way shown in the picture. From the dialog with expected and actual value I clicked *Apply* button to fix scenarios. However after rerun, there is exception that value can not be parsed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (AG-117) Expose configuration option for ConnectionWrapper.trackStatements
by John O'Hara (Jira)
John O'Hara created AG-117:
------------------------------
Summary: Expose configuration option for ConnectionWrapper.trackStatements
Key: AG-117
URL: https://issues.jboss.org/browse/AG-117
Project: Agroal
Issue Type: Bug
Components: pool
Affects Versions: 1.5
Reporter: John O'Hara
Assignee: Luis Barreiro
Please can we expose a configuration option for io.agroal.pool.wrapper.ConnectionWrapper.trackStatements?
At present, the default behaviour is to track prepared statements and close all statements when a connection is returned to the connection pool. There are instances when we do not wish to close prepared statements, when we wish to reuse prepared statements
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4481) CLI control flow improvements
by Kabir Khan (Jira)
Kabir Khan created WFCORE-4481:
----------------------------------
Summary: CLI control flow improvements
Key: WFCORE-4481
URL: https://issues.jboss.org/browse/WFCORE-4481
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Kabir Khan
Assignee: Jean Francois Denise
Working on CLI script for the OpenShift images, I have found numerous limitations in the CLI control flow functionality. I am opening one issue just to record this, if work ever happens on this I think doing whatever as possible as separate (groups of) RFEs is reasonable.
The limitations in order of preference
*Support if/else-if*
At the moment it seems you can only do if/else. On its own this is not very useful, it would also need implementing of 'Combine expressions being tested for' or 'Support nested control structures'
*Combine expressions being tested for*
E.g I can do {{if (outcome == success && result=in-memory) of /subsystem=batch-jberet:read-attribute(name=default-job-repository)}}. It would be good to be able to combine more than one of these along the lines of
{code}
if ((outcome == success) of /subsystem=batch-jberet:read-attribute(name=default-job-repository)) && ((result == 123) of /other=resource:read-attribute(name=some-attr))
{code}
*Support nested control structures
At the moment you can only have one level of each of if/for/try. For example the following is allowed:
{code}
for child in /some=resource:read-children-names(child-type=type)
if (result == []) of /some=resource/type=\$child:read-children-names(child-type=some-type)
try
#do something
end-try
end-if
done
{code}
But I cannot do:
{code}
if (outcome == success) of /some=resource:read-resource
if (outcome == success) of /some=resource/child=thing:read-resource
# do something
end-if
end-if
{code}
The same goes for for and try.
*Variables*
CLI allows you to use `set` to assign a variable. However, apart from substitution into paths and attribute values they are not very useful. It would be nice to be able to use them in if/for statements. It would also be nice to store the results of reads. Something along the lines of
{code}
set (myvar=result && outcome==success) of /some=resource:read-attribute(name=attr-name)
if ($myvar==https)
# do something
else if ($myvar==http)
# do something else
else
# another thing to do
end-if
{code}
*Array support*
I have
{code}
for serverName in /subsystem=undertow:read-children-names(child-type=server)
if (result == []) of /subsystem=undertow/server=\$serverName:read-children-names(child-type=https-listener)
{code}
But I am only able to check if the result is empty. I can't check if it for example contains the string 'https' as one of the entry. Also, apart from being empty we don't really have a way to know the length.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months