June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5401) Suppress RuntimeException in ExecModelLambdaPostProcessor

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5401?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5401: -------------------------------------- Priority: Minor (was: Major) > Suppress RuntimeException in ExecModelLambdaPostProcessor > --------------------------------------------------------- > > Key: DROOLS-5401 > URL: https://issues.redhat.com/browse/DROOLS-5401 > Project: Drools > Issue Type: Enhancement > Components: executable model > Affects Versions: 7.38.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Minor > > When we hit an issue in ExecModelLambdaPostProcessor, we would silently fall back to non-externalized lambda. So we don't need to throw RuntimeException. Instead, we can detect non-externalized lambda with option "drools.check.nonExternalisedLambda" (DROOLS-5346). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5401) Suppress RuntimeException in ExecModelLambdaPostProcessor

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5401?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5401: -------------------------------------- Description: When we hit an issue in ExecModelLambdaPostProcessor, we would silently fall back to non-externalized lambda. So we don't need to throw RuntimeException. Instead, we can detect non-externalized lambda with option "drools.check.nonExternalisedLambda" (DROOLS-5346). (was: When we hit an issue in ExecModelLambdaPostProcessor, we would silently fall back to non-externalized lambda. So we don't need to throw RuntimeException.) > Suppress RuntimeException in ExecModelLambdaPostProcessor > --------------------------------------------------------- > > Key: DROOLS-5401 > URL: https://issues.redhat.com/browse/DROOLS-5401 > Project: Drools > Issue Type: Enhancement > Components: executable model > Affects Versions: 7.38.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > When we hit an issue in ExecModelLambdaPostProcessor, we would silently fall back to non-externalized lambda. So we don't need to throw RuntimeException. Instead, we can detect non-externalized lambda with option "drools.check.nonExternalisedLambda" (DROOLS-5346). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5401) Suppress RuntimeException in ExecModelLambdaPostProcessor

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5401: ----------------------------------------- Summary: Suppress RuntimeException in ExecModelLambdaPostProcessor Key: DROOLS-5401 URL: https://issues.redhat.com/browse/DROOLS-5401 Project: Drools Issue Type: Enhancement Components: executable model Affects Versions: 7.38.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi When we hit an issue in ExecModelLambdaPostProcessor, we would silently fall back to non-externalized lambda. So we don't need to throw RuntimeException. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-10173?page=com.atlassian.jira.plugi... ] Cheng Fang commented on WFLY-10173: ----------------------------------- This test has a success rate of 96.7% in recent WF CI jobs. So I'll think more of a reliable way of testing singleton wait time. > EjbInvocationStatisticsTestCase fails on Windows: wait-time=0 > ------------------------------------------------------------- > > Key: WFLY-10173 > URL: https://issues.redhat.com/browse/WFLY-10173 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 12.0.0.Final > Reporter: Jan Kalina > Assignee: Cheng Fang > Priority: Major > Fix For: 20.0.0.Final > > > Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message). > For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases. > I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0 - need to use longer sleeps to fulfill the test) > {code} > [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase > [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179) > at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379) > ... > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1979) Elytron needs to deal with JEPS 244 in the org.wildfly.security.ssl package

by Brian Stansberry (Jira)

Brian Stansberry created ELY-1979: ------------------------------------- Summary: Elytron needs to deal with JEPS 244 in the org.wildfly.security.ssl package Key: ELY-1979 URL: https://issues.redhat.com/browse/ELY-1979 Project: WildFly Elytron Issue Type: Bug Components: SSL Affects Versions: 1.12.0.Final Reporter: Brian Stansberry JEPS 244, available in JDK 9 or later and in JDK 8 since the 251 release[1] has added new methods to some of the javax.net.ssl classes that elytron wraps in org.wildfly.security.ssl. But the elytron classes do not handle those new methods. I believe the relevant change is at [2] and updates the SSLEngine, SSLParameters and SSLSocket classes (plus various non-javax classes.) If Elytron were to require 251 or later to build perhaps this could be a simple matter of adding new methods to the wrappers and calling the delegate, under the expectation that at runtime the wrapper methods would not be invoked in a JVM < 251. Or the wrappers could use reflection and throw a UOE if the methods are not available. [1] https://www.oracle.com/technetwork/java/javase/8u251-relnotes-5972664.htm... [2] https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13551) Upgrade wildfly-naming-client to 1.0.13.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13551?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13551: ------------------------------------ Description: Pick up https://issues.redhat.com/browse/WFNC-57 https://github.com/wildfly/wildfly-naming-client/compare/1.0.12.Final...1... was:Pick up https://issues.redhat.com/browse/WFNC-57 > Upgrade wildfly-naming-client to 1.0.13.Final > --------------------------------------------- > > Key: WFLY-13551 > URL: https://issues.redhat.com/browse/WFLY-13551 > Project: WildFly > Issue Type: Component Upgrade > Components: Naming > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 20.0.0.Final > > > Pick up https://issues.redhat.com/browse/WFNC-57 > https://github.com/wildfly/wildfly-naming-client/compare/1.0.12.Final...1... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13051) provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService

by nimo stephan (Jira)

[ https://issues.redhat.com/browse/WFLY-13051?page=com.atlassian.jira.plugi... ] nimo stephan commented on WFLY-13051: ------------------------------------- Ok thanks for the information. >If you really need to remove tasks when canceled (instead of when these expire) The problem is that even if the task is expired it will be within the scheduled queue for the next time and then will be fired again when I use {code:java} // no possibility to cancel tasks after it was submitted executor.scheduleWithFixedDelay(..) {code} Hence there is a need to cancel the task..the spec lacks for such cases.. However, thanks for that info..maybe you can keep this in mind when discussing to improve the spec.. > provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService > ------------------------------------------------------------------ > > Key: WFLY-13051 > URL: https://issues.redhat.com/browse/WFLY-13051 > Project: WildFly > Issue Type: Enhancement > Components: Concurrency Utilities > Affects Versions: 19.0.0.Beta1 > Reporter: nimo stephan > Assignee: Eduardo Martins > Priority: Major > > Using > {code:java} > @Resource > private ManagedScheduledExecutorService executor; > {code} > provides no possiblity to setRemoveOnCancelPolicy to true. > A casting within a method: > {code:java} > ((ScheduledThreadPoolExecutor) executor).setRemoveOnCancelPolicy(true); > {code} > throws the error: > {code:java} > Caused by: javax.ejb.EJBException: java.lang.ClassCastException: class org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter cannot be cast to class java.util.concurrent.ScheduledThreadPoolExecutor (org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter is in unnamed module of loader 'org.glassfish.javax.enterprise.concurrent' @a93b7af; java.util.concurrent.ScheduledThreadPoolExecutor is in module java.base of loader 'bootstrap') > at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:246) > at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:388) > at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68) > {code} > Please provide option to cast or if not possible to add the property > {code:java} > setRemoveOnCancelPolicy() > {code} > within the object ManagedScheduledExecutorService. Because without it, we cannot remove a task from the queue with "future.cancel(false)". -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13514) Huge memory leak in WildFly

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13514?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13514: ----------------------------------------- Thanks so much [~konbk] for the report, [~manovotn] for the analysis and [~flavia.rainone] for the fix! > Huge memory leak in WildFly > --------------------------- > > Key: WFLY-13514 > URL: https://issues.redhat.com/browse/WFLY-13514 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF, Web (Undertow) > Affects Versions: 18.0.1.Final, 19.1.0.Final, 20.0.0.Beta1 > Reporter: Konrad Bak > Assignee: Flavia Rainone > Priority: Blocker > Fix For: 20.0.0.Final > > > https://github.com/konbk/bug-report-wildfly-oome > The project shows a huge memory leak introduced in recent WildFly versions that can crash a real-world Java EE application in a matter of hours. > When a JSF page contains any component bound to page variable, all CDI beans (regardless of scope) used on that page stay in memory. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13514) Huge memory leak in WildFly

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13514?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFLY-13514. ------------------------------------- Resolution: Done > Huge memory leak in WildFly > --------------------------- > > Key: WFLY-13514 > URL: https://issues.redhat.com/browse/WFLY-13514 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF, Web (Undertow) > Affects Versions: 18.0.1.Final, 19.1.0.Final, 20.0.0.Beta1 > Reporter: Konrad Bak > Assignee: Flavia Rainone > Priority: Blocker > Fix For: 20.0.0.Final > > > https://github.com/konbk/bug-report-wildfly-oome > The project shows a huge memory leak introduced in recent WildFly versions that can crash a real-world Java EE application in a matter of hours. > When a JSF page contains any component bound to page variable, all CDI beans (regardless of scope) used on that page stay in memory. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1151) Automate Workload logs Side by Side

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1151?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1151: ---------------------------------- Sprint: Kiali Sprint #40 > Automate Workload logs Side by Side > ----------------------------------- > > Key: SWSQE-1151 > URL: https://issues.redhat.com/browse/SWSQE-1151 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2020