[Red Hat JIRA] (WFLY-14439) The org.apache.thrift module is in the wildfly-ee feature pack
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-14439?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-14439:
------------------------------------
Description:
The org.apache.thrift module is only shipped because io.jaegertracing uses it. So it should be in the 'wildfly' galleon pack, not 'wildfly-ee'.
This likely just means moving the module.xml file to microprofile/galleon-common.
was:The org.apache.thrift module is only shipped because io.jaegertracing uses it. So it should be in the 'wildfly' galleon pack, not 'wildfly-ee'.
> The org.apache.thrift module is in the wildfly-ee feature pack
> --------------------------------------------------------------
>
> Key: WFLY-14439
> URL: https://issues.redhat.com/browse/WFLY-14439
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 22.0.1.Final
> Reporter: Brian Stansberry
> Assignee: Jason Lee
> Priority: Major
> Fix For: 23.0.0.Beta1
>
>
> The org.apache.thrift module is only shipped because io.jaegertracing uses it. So it should be in the 'wildfly' galleon pack, not 'wildfly-ee'.
> This likely just means moving the module.xml file to microprofile/galleon-common.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (DROOLS-5992) Fix target definition
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5992?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5992:
-----------------------------------
Involved: (was: Michael Anstis)
> Fix target definition
> ---------------------
>
> Key: DROOLS-5992
> URL: https://issues.redhat.com/browse/DROOLS-5992
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Critical
> Labels: TrustyAI
>
> Current PMML trusty implementation has the following assumption
> 1) there is always one, and only one, "target" MiningField
> 2) target are defined only inside MiningSchema
> About 1:
> 1) it is not mandatory to have a "target" MiningField - i.e. a MiningSchema may define none
> 2) there could be more then one "target" MiningField
> About 2:
> Target may also be defined inside "Targets" tag
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (DROOLS-5992) Fix target definition
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5992?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5992:
-------------------------------------
Involved: Michael Anstis
> Fix target definition
> ---------------------
>
> Key: DROOLS-5992
> URL: https://issues.redhat.com/browse/DROOLS-5992
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Critical
> Labels: TrustyAI
>
> Current PMML trusty implementation has the following assumption
> 1) there is always one, and only one, "target" MiningField
> 2) target are defined only inside MiningSchema
> About 1:
> 1) it is not mandatory to have a "target" MiningField - i.e. a MiningSchema may define none
> 2) there could be more then one "target" MiningField
> About 2:
> Target may also be defined inside "Targets" tag
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14434) Heap usage continuously growing and exhausting available heap memory in production
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-14434?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFLY-14434:
-------------------------------------
WF releases are only patched until the next final release is available, after which they are no longer maintained.
That means your options are to patch yourself, or upgrade.
> 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)
3 years, 3 months
[Red Hat JIRA] (SWSQE-1290) Change email report content from Jenkins master's jobs
by Tiago Moreira Vieira (Jira)
[ https://issues.redhat.com/browse/SWSQE-1290?page=com.atlassian.jira.plugi... ]
Tiago Moreira Vieira updated SWSQE-1290:
----------------------------------------
Description:
Our jobs report only contain the title of the job but it doesn't say what the job does. When a job fail, it is hard to know what the job is, therefore hard to know what the failure actually means.
For instance, ocp_4_7_ossm_2_0_2: is this a interop test for OCP 4.7 with 2.0.2 from production? From stage?
Or, another example: ocp_4_6_ossm_2_0_2_0_1 - is it the same job as above but with OCP 4.6? If so, why the name differs? If not, what does it mean then?
It would be nice to have a more meaninful message such as "The acceptance test on OCP 4.6 with the production version of OSSM 2.0.2-1 failed." Or, "The installation test on OCP 4.7 failed for the nightly build 2.0-123456789"
was:Some jobs from our master Jenkins are sending emails with the name job, status and version - but it is necessary to report what kind of issue occurred (when it fails), to help on the investigation.
> Change email report content from Jenkins master's jobs
> ------------------------------------------------------
>
> Key: SWSQE-1290
> URL: https://issues.redhat.com/browse/SWSQE-1290
> Project: Kiali QE
> Issue Type: Task
> Reporter: Leonardo Ieggli
> Assignee: Leonardo Ieggli
> Priority: Major
> Labels: infrastructure
>
> Our jobs report only contain the title of the job but it doesn't say what the job does. When a job fail, it is hard to know what the job is, therefore hard to know what the failure actually means.
>
> For instance, ocp_4_7_ossm_2_0_2: is this a interop test for OCP 4.7 with 2.0.2 from production? From stage?
> Or, another example: ocp_4_6_ossm_2_0_2_0_1 - is it the same job as above but with OCP 4.6? If so, why the name differs? If not, what does it mean then?
>
> It would be nice to have a more meaninful message such as "The acceptance test on OCP 4.6 with the production version of OSSM 2.0.2-1 failed." Or, "The installation test on OCP 4.7 failed for the nightly build 2.0-123456789"
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-13978) YAML support for system properties
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/WFLY-13978?page=com.atlassian.jira.plugi... ]
Toni Rikkola commented on WFLY-13978:
-------------------------------------
The Business Central standalone jar has advised the users to go with the YAML file. Having this support in the future would be helpful for BC users who upgrade.
[BAPL-1856] Migrate standalone Business Central from Thorntail to EAP Bootable Jar - Red Hat Issue Tracker
> YAML support for system properties
> -----------------------------------
>
> Key: WFLY-13978
> URL: https://issues.redhat.com/browse/WFLY-13978
> Project: WildFly
> Issue Type: Feature Request
> Components: Management
> Reporter: Marc Gabriel-Willem
> Assignee: Brian Stansberry
> Priority: Major
> Labels: WildFly
>
> Hi,
> In order to facilitate the migration from Thorntail to WildFly bootable JAR based solution I could be very nice to support YAML configuration file for system properties.
> Currently using the --properties WF parameter properties file only can be provided.
> The smallrye-config-source-yaml project does not help for system properties.
> It means all existing YAML files need to be converted to properties format and it hurts the Thorntail->WildFly migration.
> I hope this feature could be analysed..and integrated ;)
> BR,
> Marc
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-3915) Dynamic configuration of outbound SSL connections
by Mahendran Rajendran (Jira)
[ https://issues.redhat.com/browse/WFLY-3915?page=com.atlassian.jira.plugin... ]
Mahendran Rajendran edited comment on WFLY-3915 at 2/18/21 6:40 AM:
--------------------------------------------------------------------
[~chris.dolphy] is this feature request is added to new versions? we have requirement to connect two mq server from eap with different certificates presented to each mq server. this was possible with websphere application server but not working in EAP 7.2.x.
was (Author: JIRAUSER155059):
[~chris.dolphy] is this feature request is added to new versions? we have requirement to connect two mq server from eap with different certificates presented to each mq server. this was possible with websphere application server but not workign in EAP 7.2.x.
> Dynamic configuration of outbound SSL connections
> -------------------------------------------------
>
> Key: WFLY-3915
> URL: https://issues.redhat.com/browse/WFLY-3915
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: James Livingston
> Assignee: Darran Lofthouse
> Priority: Major
>
> WebSphere has a feature called "Dynamic outbound SSL configuration" (http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websph...), which allows the configuration of SSL parameters for connections which are not opened directly by the container.
> That can be useful for configuring the SSL usage of components such as resource adapters, JDBC drivers, and application-packaged web service libraries. For example the truststore/keystore could be configured different for all requests to the database host, so that the global javax.net.ssl settings to not need to be modified if the driver does not itself provide a way to configure it.
> I believe that it is implemented by using javax.net.ssl.SSLContext.setDefault() to replace the standard socket factory. The socket factory could then look at the passed hostname/port, and potentially the calling application to configure the SSL socket appropriately before returning it to the caller.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-3915) Dynamic configuration of outbound SSL connections
by Mahendran Rajendran (Jira)
[ https://issues.redhat.com/browse/WFLY-3915?page=com.atlassian.jira.plugin... ]
Mahendran Rajendran commented on WFLY-3915:
-------------------------------------------
[~chris.dolphy] is this feature request is added to new versions? we have requirement to connect two mq server from eap with different certificates presented to each mq server. this was possible with websphere application server but not workign in EAP 7.2.x.
> Dynamic configuration of outbound SSL connections
> -------------------------------------------------
>
> Key: WFLY-3915
> URL: https://issues.redhat.com/browse/WFLY-3915
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: James Livingston
> Assignee: Darran Lofthouse
> Priority: Major
>
> WebSphere has a feature called "Dynamic outbound SSL configuration" (http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websph...), which allows the configuration of SSL parameters for connections which are not opened directly by the container.
> That can be useful for configuring the SSL usage of components such as resource adapters, JDBC drivers, and application-packaged web service libraries. For example the truststore/keystore could be configured different for all requests to the database host, so that the global javax.net.ssl settings to not need to be modified if the driver does not itself provide a way to configure it.
> I believe that it is implemented by using javax.net.ssl.SSLContext.setDefault() to replace the standard socket factory. The socket factory could then look at the passed hostname/port, and potentially the calling application to configure the SSL socket appropriately before returning it to the caller.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months