[Red Hat JIRA] (DROOLS-5819) executable-model test failure in test-compiler-integration PolymorphismTest
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5819?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5819:
--------------------------------------
Sprint: 2021 Week 07-09 (from Feb 15)
Story Points: 1
> executable-model test failure in test-compiler-integration PolymorphismTest
> ---------------------------------------------------------------------------
>
> Key: DROOLS-5819
> URL: https://issues.redhat.com/browse/DROOLS-5819
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.46.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> org.drools.mvel.integrationtests.PolymorphismTest in test-compiler-integration fails with some tests when executable-model is enabled. See TODO comment in the test class. Once fixed (or the test failure is justified), we can remove the TODO comment and let the test run with executable-model.
> Currently, executable-model is disabled:
> {code:java}
> // TODO: ....
> return TestParametersUtil.getKieBaseCloudConfigurations(false);
> {code}
> If the test failure contains multiple bugs, we may split this JIRA into multiple JIRAs.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFLY-14445) Migrate subsystem to the current MSC services style removing the deprecated ones
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFLY-14445:
-------------------------------------------
Summary: Migrate subsystem to the current MSC services style removing the deprecated ones
Key: WFLY-14445
URL: https://issues.redhat.com/browse/WFLY-14445
Project: WildFly
Issue Type: Task
Components: Mail
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
Since MSC 1.4.0.Final, there is a new set of interfaces and programming model for the JBoss Modular Service Container. The mail subsystem is still using the legacy style, the task here is to migrate them to the new programming style. This could be done after WF23.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFLY-14434) Heap usage continuously growing and exhausting available heap memory in production
by Manas Panda (Jira)
[ https://issues.redhat.com/browse/WFLY-14434?page=com.atlassian.jira.plugi... ]
Manas Panda commented on WFLY-14434:
------------------------------------
You are saying there is no official patches available for this issue and suggesting to backport pull requests from WF21 containing fixes to WF18 code and build our self.
The final fix is available in WF22.
> Heap usage continuously growing and exhausting available heap memory in production
> ----------------------------------------------------------------------------------
>
> Key: WFLY-14434
> URL: https://issues.redhat.com/browse/WFLY-14434
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Manas Panda
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: Heap_Size_keeps_increasing.jpg, Heap_dump_analysis_1.jpg
>
>
> # Problem description:
> Critical issue of heap usage continuously growing and exhausting available heap memory in production. As you can see in below heap dump org.infinispan.container.impl.DefaultDataContainer is growing as the time passes and not garbage collected by GC. This increase in heap happening after upgrading from Wildfly 10.1 to Wildfly 18.0.1. There is no change in JDK in both cases ( Wildfly 10.1 and Wildfly 18.0.1).
> 2. Web application environment
> * OS: RHEL 7.5
> * Wildfly 18.0.1
> * JDK 1.8
> * Wildfly is being run in cluster mode
> * Integrated with Keycloak 3.4.3 for SSO ( SAML)
> * Enabled Wildfly clustering mode
> * G1GC garbage collector used. And 20gigs of heap allocated ( -Xmx)
> * Environment of Web App on Wildfly 10.1 is same ( except Wildfly 18) with same hardware
> * Web application uses Spring web framework and security
> 3. Heap dump analysis
> * We have few web users logging in and every second and external application consuming few API’s exposed by same application.
> * As you can see infinispan.container.impl.DefaultDataContainer Has already grown 14gigs.
> * Please note that web application does not use infinispan directly.
> * The heap does not grow in wildfly 10.1 and its normal ( garbage gets collected and size gets reduced after GC)
> Please find the snapshot as attached.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFCORE-4970) Changing the JVM settings at host level does not put the servers in restart-required
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFCORE-4970?page=com.atlassian.jira.plug... ]
Yeray Borges Santana edited comment on WFCORE-4970 at 2/17/21 5:13 AM:
-----------------------------------------------------------------------
[~parsharma] My understanding of Brian's suggestion by inspecting the possibilities of using [arbitrary descriptors|https://docs.wildfly.org/22/Admin_Guide.html#arbitrary-descri...] was to use this additional metadata to describe that certain attribute modifications need to restart the managed servers JVMs.
If that's correct and since all the attributes need a JVM restart, I think it would be enough to enhance the resource description itself and describe there that changes in the attributes of these resources will require to restart of the managed servers to make the changes effective.
The point here seems to be that the following resources change the configuration of the managed servers JVM:
/host=*/jvm=
/host=\*/server-config=*/jvm=
/server-group=*/jvm=
However, modifying this configuration should not affect the HC process. If we flag the jvm attributes with setRestartJvm, then the HC process-state will get a restart-required. What is required is to restart the affected managed servers to make the changes effective, but not the HC itself.
was (Author: yersan):
[~parsharma] My understanding of Brian's suggestion by inspecting the possibilities of using [arbitrary descriptors|https://docs.wildfly.org/22/Admin_Guide.html#arbitrary-descri...] was to use this additional metadata to describe that certain attribute modifications need to restart the managed servers JVMs.
If that's correct and since all the attributes need a JVM restart, I think it would be enough to enhance the resource description itself and describe there that changes in the attributes of these resources will require to restart of the managed servers to make the changes effective.
The point here seems to be that the following resources change the configuration of the managed servers JVM:
/host=*/jvm=
/host=*/server-config=*/jvm=
/server-group=*/jvm=
However, modifying this configuration should not affect the HC process. If we flag the jvm attributes with setRestartJvm, then the HC process-state will get a restart-required. What is required is to restart the affected managed servers to make the changes effective, but not the HC itself.
> Changing the JVM settings at host level does not put the servers in restart-required
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-4970
> URL: https://issues.redhat.com/browse/WFCORE-4970
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.0.Beta2
> Reporter: Yeray Borges Santana
> Assignee: Parul Sharma
> Priority: Minor
>
> Operations like the following one should put the servers in restart required to indicate the user changes will be applied after restarting the servers:
> {noformat}
> [domain@localhost:9990 /] /host=master/jvm=default:write-attribute(name=heap-size, value=256m)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month