[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5284 at 5/31/20 10:22 PM:
---------------------------------------------------------------------
Fixed by https://github.com/mvel/mvel/pull/233/commits/d9d0a93a0a25514b6e777ebb9b3...
Drools will need to consume mvel 2.4.8.Final or later.
-> Done with RHDM-1339 : https://github.com/kiegroup/droolsjbpm-build-bootstrap/commit/ddd2fc36417...
was (Author: tkobayashi):
Fixed by https://github.com/mvel/mvel/pull/233/commits/d9d0a93a0a25514b6e777ebb9b3...
Drools will need to consume mvel 2.4.8.Final or later.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
- 1
- 0
[JBoss JIRA] (WFLY-13542) Container does not enforce bean-managed concurrency for timeout methods
by Fábio Silva (Jira)
[ https://issues.redhat.com/browse/WFLY-13542?page=com.atlassian.jira.plugi... ]
Fábio Silva updated WFLY-13542:
-------------------------------
Steps to Reproduce:
Sample bean:
{code:java}
import java.util.concurrent.locks.ReentrantLock;
import javax.ejb.Asynchronous;
import javax.ejb.ConcurrencyManagement;
import javax.ejb.ConcurrencyManagementType;
import javax.ejb.Schedule;
import javax.ejb.Singleton;
@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class MySingleton {
private static final ReentrantLock locker = new ReentrantLock();
@Schedule(persistent = false, second = "0/1", minute = "*", hour = "*")
public void requestEntry() {
long id = Thread.currentThread().getId();
if (locker.tryLock()) {
System.out.println("Please come in, " + id + "!");
doSomething();
locker.unlock();
} else {
System.err.println("Please wait outside, " + id + "!");
}
}
private void doSomething() {
int timeout = (int) (Math.random() * 8000 + 1000);
try {
Thread.sleep(timeout);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
{code}
was:
Sample bean:
{code:java}
import java.util.concurrent.locks.ReentrantLock;
import javax.ejb.Asynchronous;
import javax.ejb.ConcurrencyManagement;
import javax.ejb.ConcurrencyManagementType;
import javax.ejb.Schedule;
import javax.ejb.Singleton;
@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class MySingleton {
private static final ReentrantLock locker = new ReentrantLock();
@Schedule(persistent = false, second = "0/1", minute = "*", hour = "*")
public void requestEntry() {
long id = Thread.currentThread().getId();
if (locker.tryLock()) {
System.out.println("Please come in, " + id + "!");
doSomething();
locker.unlock();
} else {
System.err.println("Please wait outside, " + id + "!");
}
}
private void doSomething() {
int timeout = (int) (Math.random() * 8000 + 1000);
try {
Thread.sleep(timeout);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
{code}
> Container does not enforce bean-managed concurrency for timeout methods
> -----------------------------------------------------------------------
>
> Key: WFLY-13542
> URL: https://issues.redhat.com/browse/WFLY-13542
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.1.0.Final
> Reporter: Fábio Silva
> Assignee: Cheng Fang
> Priority: Major
>
> Bean-managed concurrency for @Singleton EJBs is not enforced for timeout methods annotated with @Schedule. When a timeout is fired while the previous one is still running, the timeout method is not called. Instead, WildFly logs a warning like the following:
> {code:java}
> 20:58:54,000 WARN [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0043: A previous execution of timer [id=aa716284-ef7b-4bb3-a356-a8ca187255c4 timedObjectId=myweb.myweb.MySingleton auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@303bd2d5 previousRun=Sun May 31 20:57:10 BRT 2020 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sun May 31 20:58:54 BRT 2020 timerState=IN_TIMEOUT info=null] ScheduleExpression [second=0/1;minute=*;hour=*;dayOfMonth=*;month=*;dayOfWeek=*;year=*;timezoneID=null;start=null;end=null] is still in progress, skipping this overlapping scheduled execution at: Sun May 31 20:58:54 BRT 2020.
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
- 1
- 0
[JBoss JIRA] (WFLY-13542) Container does not enforce bean-managed concurrency for timeout methods
by Fábio Silva (Jira)
Fábio Silva created WFLY-13542:
----------------------------------
Summary: Container does not enforce bean-managed concurrency for timeout methods
Key: WFLY-13542
URL: https://issues.redhat.com/browse/WFLY-13542
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 19.1.0.Final
Reporter: Fábio Silva
Assignee: Cheng Fang
Bean-managed concurrency for @Singleton EJBs is not enforced for timeout methods annotated with @Schedule. When a timeout is fired while the previous one is still running, the timeout method is not called. Instead, WildFly logs a warning like the following:
{code:java}
20:58:54,000 WARN [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0043: A previous execution of timer [id=aa716284-ef7b-4bb3-a356-a8ca187255c4 timedObjectId=myweb.myweb.MySingleton auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@303bd2d5 previousRun=Sun May 31 20:57:10 BRT 2020 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sun May 31 20:58:54 BRT 2020 timerState=IN_TIMEOUT info=null] ScheduleExpression [second=0/1;minute=*;hour=*;dayOfMonth=*;month=*;dayOfWeek=*;year=*;timezoneID=null;start=null;end=null] is still in progress, skipping this overlapping scheduled execution at: Sun May 31 20:58:54 BRT 2020.
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
- 1
- 0