[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-7212:
-------------------------------------
But hold on, isn't that what the second set of code I posted was trying to do? If so, then that didn't work, or at least it doesn't solve the issue of having the transaction-reaper come along in 5 minutes and shut things down. Am I missing something about UserTransaction? Thanks.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7226:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7226
> URL: https://issues.jboss.org/browse/WFLY-7226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
> Expcetion in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mapped-regex-realm-mapper" => "MappedRealmMapper")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Dietrich Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Dietrich Schmidt reopened WFLY-7101:
------------------------------------
Compare comment 3.
> Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
> --------------------------------------------------------------
>
> Key: WFLY-7101
> URL: https://issues.jboss.org/browse/WFLY-7101
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0 running under Windows 10 with Java 1.8.0_91
> Reporter: Dietrich Schmidt
> Assignee: Jason Greene
> Attachments: Verklemmung.zip
>
>
> Wildfly 8.2.0 and 10.0.0 work fine with a Singleton Bean, which has a @Postconstruct method and in this method several threads are created with the ManagedExecutorService. These threads call a method in another Singleton EJB, which has been injected.
> This call is blocked in Wildfly 10.1.0 until the Prostconstruct thread has ended.
> I assume that the behaviour of Wildfly 8.2.0 + 10.0.0 is correct and the behaviour of Wildfly 10.1.0 is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Dietrich Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Dietrich Schmidt edited comment on WFLY-7101 at 9/27/16 11:03 AM:
------------------------------------------------------------------
EJB spec 4.8.1 does not apply to this bug, please re-investigate.
Singleton bean A (=ServerImpl) with @startup calls in its @Postconstruct method a method in singleton bean B (=TestReaderImpl) - this works fine.
Now in this @PostConstruct several Threads are created with a ManagedExcecutorService - these threads start normally, but if they call a method iin singleton bean B, they are blocked. This must not happen and is a bug.
was (Author: rumpelstilzchen926):
EJB spec 4.8.1 does not apply to this bug, please re-investigate.
Singleton bean A (=ServerImpl) with @startup calls in its @Postconstruct method a method in singleton bean B (=TestReaderImpl) - this works fine.
Now in this @PostConstruct several Threads are created with a ManagedExcecutorService - these threads start normally, but if the call a method iin singleton bean B, they are blocked. This must not happen and is a bug.
> Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
> --------------------------------------------------------------
>
> Key: WFLY-7101
> URL: https://issues.jboss.org/browse/WFLY-7101
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0 running under Windows 10 with Java 1.8.0_91
> Reporter: Dietrich Schmidt
> Assignee: Jason Greene
> Attachments: Verklemmung.zip
>
>
> Wildfly 8.2.0 and 10.0.0 work fine with a Singleton Bean, which has a @Postconstruct method and in this method several threads are created with the ManagedExecutorService. These threads call a method in another Singleton EJB, which has been injected.
> This call is blocked in Wildfly 10.1.0 until the Prostconstruct thread has ended.
> I assume that the behaviour of Wildfly 8.2.0 + 10.0.0 is correct and the behaviour of Wildfly 10.1.0 is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Dietrich Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Dietrich Schmidt commented on WFLY-7101:
----------------------------------------
EJB spec 4.8.1 does not apply to this bug, please re-investigate.
Singleton bean A (=ServerImpl) with @startup calls in its @Postconstruct method a method in singleton bean B (=TestReaderImpl) - this works fine.
Now in this @PostConstruct several Threads are created with a ManagedExcecutorService - these threads start normally, but if the call a method iin singleton bean B, they are blocked. This must not happen and is a bug.
> Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
> --------------------------------------------------------------
>
> Key: WFLY-7101
> URL: https://issues.jboss.org/browse/WFLY-7101
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0 running under Windows 10 with Java 1.8.0_91
> Reporter: Dietrich Schmidt
> Assignee: Jason Greene
> Attachments: Verklemmung.zip
>
>
> Wildfly 8.2.0 and 10.0.0 work fine with a Singleton Bean, which has a @Postconstruct method and in this method several threads are created with the ManagedExecutorService. These threads call a method in another Singleton EJB, which has been injected.
> This call is blocked in Wildfly 10.1.0 until the Prostconstruct thread has ended.
> I assume that the behaviour of Wildfly 8.2.0 + 10.0.0 is correct and the behaviour of Wildfly 10.1.0 is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1310) Expired fact with activationCount > 0 are not evicted from objectstore
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1310:
--------------------------------------
Summary: Expired fact with activationCount > 0 are not evicted from objectstore
Key: DROOLS-1310
URL: https://issues.jboss.org/browse/DROOLS-1310
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.5.0.CR2
Reporter: Matteo Mortari
Assignee: Mario Fusco
Priority: Minor
Expired fact with activationCount > 0 are not evicted from objectstore: intended behavior for serialization purposes, but for instance side-effects when used in an activation-group scenario where the rules are not 100% dual.
Sized-down reproducer will be submitted at a later time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1309) Rules compilation failure depending on condition ordering
by Edson Tirelli (JIRA)
Edson Tirelli created DROOLS-1309:
-------------------------------------
Summary: Rules compilation failure depending on condition ordering
Key: DROOLS-1309
URL: https://issues.jboss.org/browse/DROOLS-1309
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
When creating rules in guided editor, we are running into validation errors depending on the order of the conditions. The problem is that the order of the conditions is important:
{noformat}
when
COND_X
COND_Y => works
when
COND_Y
COND_X => fails
java.lang.AssertionError: [10,18]: [ERR 101] Line 10:18 no viable alternative at input 'Number' in rule "ATO_Negative_AU_Test"
[0,0]: Parser returned a null Package
{noformat}
Test cases showing the compilation failures (@Test testOrder1 vs
testOrder2) can be found here:
https://gist.github.com/martinweiler/e684a0e75a2c9f4de4dee5a13affb8b0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7190) Group related resources in Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7190?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7190:
-----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> Group related resources in Elytron subsystem
> --------------------------------------------
>
> Key: WFLY-7190
> URL: https://issues.jboss.org/browse/WFLY-7190
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure.
> Suggestion:
> It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7190) Group related resources in Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7190?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7190:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Group related resources in Elytron subsystem
> --------------------------------------------
>
> Key: WFLY-7190
> URL: https://issues.jboss.org/browse/WFLY-7190
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure.
> Suggestion:
> It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months