[JBoss JIRA] (WFWIP-279) FaultTolerance subsystem gets MP Config properties values too many times
by Ivan Straka (Jira)
Ivan Straka created WFWIP-279:
---------------------------------
Summary: FaultTolerance subsystem gets MP Config properties values too many times
Key: WFWIP-279
URL: https://issues.redhat.com/browse/WFWIP-279
Project: WildFly WIP
Issue Type: Bug
Components: MP Config, MP Fault Tolerance
Reporter: Ivan Straka
Assignee: Radoslav Husar
I have a fail safe service that would normally return a value provided by a provider A and areturn a value from provider B on fallback (in case the provider A throws an exception). Providers return values based on MP Config property. Source of the properties is a ConfigSource class that reads a .property file.
The issue is ConfigSource#getProperties method is called too may times that results to Too many open files exception:
{code:java}
13:41:48,959 ERROR [stderr] (MSC service thread 1-4) java.io.FileNotFoundException: /home/istraka/repositories/github/eap-microprofile-test-suite/microprofile-metrics/target/test-classes/org/jboss/eap/qe/microprofile/metrics/integration/ft/ft-custom-metric.properties (Too many open files)
13:41:48,960 ERROR [stderr] (MSC service thread 1-4) at java.io.FileInputStream.open0(Native Method)
13:41:48,960 ERROR [stderr] (MSC service thread 1-4) at java.io.FileInputStream.open(FileInputStream.java:195)
13:41:48,960 ERROR [stderr] (MSC service thread 1-4) at java.io.FileInputStream.<init>(FileInputStream.java:138)
13:41:48,960 ERROR [stderr] (MSC service thread 1-4) at java.io.FileInputStream.<init>(FileInputStream.java:93)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.eap.qe.microprofile.metrics.integration.ft.FTCustomConfigSource.getProperties(FTCustomConfigSource.java:25)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.eap.qe.microprofile.metrics.integration.ft.FTCustomConfigSource.getValue(FTCustomConfigSource.java:37)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.config.SmallRyeConfig.getValue(SmallRyeConfig.java:84)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.config.SmallRyeConfig.getOptionalValue(SmallRyeConfig.java:106)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.faulttolerance.config.FaultToleranceOperation.getConfigStatus(FaultToleranceOperation.java:250)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.faulttolerance.config.FaultToleranceOperation.getConfig(FaultToleranceOperation.java:209)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.faulttolerance.config.FaultToleranceOperation.of(FaultToleranceOperation.java:51)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.faulttolerance.HystrixExtension.collectFaultToleranceOperations(HystrixExtension.java:112)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at java.lang.reflect.Method.invoke(Method.java:498)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:168)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at javax.enterprise.inject.spi.ObserverMethod.notify(ObserverMethod.java:124)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.util.Observers.notify(Observers.java:166)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:285)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.ProcessManagedBeanImpl.fire(ProcessManagedBeanImpl.java:31)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessBean(ContainerLifecycleEvents.java:246)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessBean(ContainerLifecycleEvents.java:240)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireProcessBeanEvents(AbstractBeanDeployer.java:128)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:331)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:264)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:453)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:86)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:97)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at java.lang.Thread.run(Thread.java:748)
{code}
There is no issue with ConfigSource class as it reads the file correctly on the first time.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (REMJMX-168) JMX proxy connection is released sooner than the client asks for closing it
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/REMJMX-168?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka updated REMJMX-168:
------------------------------------
Description:
We started to hit the issue on Narayana transaction recovery testing. Reported as JBEAP-18109. It seems to be caused by changes made at REMJMX-160.
What we hit:
It seems the JMX connection *is closed* too soon - before the client decides to release it.
The client creates a JMX proxy. Then it does not use it for a while. And then it runs the JMX calls again. Such attempt then fails.
Our test does:
* The transaction recovery test creates the JMX proxy at some point to verify content of object store.
* Then there is some idle time where the JMX proxy is not utilized.
* When the testsuite tries to verify the content of object store once again on the same JMX proxy that attempt fails.
>From investigation it seems that it could be caused by the fact that {{Executors.newCachedThreadPool}} (https://github.com/jbossas/remoting-jmx/blob/3.0.3.Final/src/main/java/or...) is used for thread creation. The JMX thread is idle more than 60 seconds and the thread pool may dispose the threads after that time (after 60s, see https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors....).
When I used the {{Executors.newFixedThreadPool}} (https://github.com/ochaloup/remoting-jmx/commit/7ec37c8a09f4d8229ee8263ad...) the issue disappeared.
was:
We started to hit the issue on Narayana transaction recovery testing. Reported as JBEAP-18109. It seems to be caused by changes made at REMJMX-160.
What we hit:
It seems the JMX connection *is closed* too soon - before the client decides to release it.
When client creates a JMX proxy, then does not use it for a while and then it runs the JMX calls again such attempt fails.
Our test does:
* The transaction recovery test creates the JMX proxy at some point to verify content of object store.
* Then there is some idle time where the JMX proxy is not utilized.
* When the testsuite tries to verify the content of object store once again on the same JMX proxy that attempt fails.
>From investigation it seems that it could be caused by the fact that {{Executors.newCachedThreadPool}} (https://github.com/jbossas/remoting-jmx/blob/3.0.3.Final/src/main/java/or...) is used for thread creation. The JMX thread is idle more than 60 seconds and the thread pool may dispose the threads after that time (after 60s, see https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors....).
When I used the {{Executors.newFixedThreadPool}} (https://github.com/ochaloup/remoting-jmx/commit/7ec37c8a09f4d8229ee8263ad...) the issue disappeared.
> JMX proxy connection is released sooner than the client asks for closing it
> ---------------------------------------------------------------------------
>
> Key: REMJMX-168
> URL: https://issues.redhat.com/browse/REMJMX-168
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 3.0.2.Final, 3.0.3.Final
> Reporter: Ondrej Chaloupka
> Assignee: Darran Lofthouse
> Priority: Major
>
> We started to hit the issue on Narayana transaction recovery testing. Reported as JBEAP-18109. It seems to be caused by changes made at REMJMX-160.
> What we hit:
> It seems the JMX connection *is closed* too soon - before the client decides to release it.
> The client creates a JMX proxy. Then it does not use it for a while. And then it runs the JMX calls again. Such attempt then fails.
> Our test does:
> * The transaction recovery test creates the JMX proxy at some point to verify content of object store.
> * Then there is some idle time where the JMX proxy is not utilized.
> * When the testsuite tries to verify the content of object store once again on the same JMX proxy that attempt fails.
> From investigation it seems that it could be caused by the fact that {{Executors.newCachedThreadPool}} (https://github.com/jbossas/remoting-jmx/blob/3.0.3.Final/src/main/java/or...) is used for thread creation. The JMX thread is idle more than 60 seconds and the thread pool may dispose the threads after that time (after 60s, see https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors....).
> When I used the {{Executors.newFixedThreadPool}} (https://github.com/ochaloup/remoting-jmx/commit/7ec37c8a09f4d8229ee8263ad...) the issue disappeared.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (DROOLS-3957) Make verifier panel use docks
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-3957?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-3957:
--------------------------------
Description:
Pretty sure we had a ticket for this, but could not find it. Here it is.
h3. Acceptance test
On both Firefox and Chrome (/)
- Opening multiple decision tables, switching between them
- Repeated reopening of guided decision table
- Opening other asset that uses docks - scenario, data object
Selenium tests updated https://github.com/jboss-integration/bxms-qe-tests/pull/2971
was:
Pretty sure we had a ticket for this, but could not find it. Here it is.
h3. Acceptance test
On both Firefox and Chrome (/)
- Opening multiple decision tables, switching between them
- Repeated reopening of guided decision table
- Opening other asset that uses docks - scenario, data object
> Make verifier panel use docks
> -----------------------------
>
> Key: DROOLS-3957
> URL: https://issues.redhat.com/browse/DROOLS-3957
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
> Attachments: v&v.webm
>
>
> Pretty sure we had a ticket for this, but could not find it. Here it is.
> h3. Acceptance test
> On both Firefox and Chrome (/)
> - Opening multiple decision tables, switching between them
> - Repeated reopening of guided decision table
> - Opening other asset that uses docks - scenario, data object
> Selenium tests updated https://github.com/jboss-integration/bxms-qe-tests/pull/2971
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (DROOLS-4837) Abstract reflective accesses from RuleUnitDescription
by Edoardo Vacchi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4837?page=com.atlassian.jira.plug... ]
Edoardo Vacchi updated DROOLS-4837:
-----------------------------------
Fix Version/s: 7.31.0.Final
> Abstract reflective accesses from RuleUnitDescription
> -----------------------------------------------------
>
> Key: DROOLS-4837
> URL: https://issues.redhat.com/browse/DROOLS-4837
> Project: Drools
> Issue Type: Feature Request
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Priority: Major
> Labels: drools-core
> Fix For: 7.31.0.Final
>
>
> RuleUnitDescription interface returns `Method`s; in Kogito we need a way to abstract over class definitions so that a RuleUnit can be materialized at later stages of the compilation process.
> with this JIRA, we introduce an abstraction over RuleUnitDescription, so that different implementations can be provided. The default implementation is reflective (uses Methods), but a non-reflective implementation will be allowed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months