June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ] Gabriele Cardosi edited comment on DROOLS-5372 at 6/4/20 10:59 AM: ------------------------------------------------------------------- Most cost-effective solution would be: # 1) create a new _Command_ with API tailored for new kie-pmml (see {code:java} ApplyPmmlModelCommand {code} as example) # 2) verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "_property_" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # 2) inside DMN: ## 1) inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath was (Author: gabriolo): Most cost-effective solution would be: # 1) create a new Command with API tailored for new kie-pmml (see ApplyPmmlModelCommand as example) # 2) verify the behavior when *both* `PMMLAssemblerService`s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "property" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshofit/docker" images wher both modules are expected to be present in the classpath # 2) inside DMN: ## 1) inside `AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...)` add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath > Investigate PMML abstraction/coexistence > ----------------------------------------- > > Key: DROOLS-5372 > URL: https://issues.redhat.com/browse/DROOLS-5372 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > New and old PMML implementations should live together for some time. > USer should be able to choose implementation. > Consider creating a "proxy" pmml-module that > 1) declare PMMLAssemblerService > 2) declare PMMLRuntime > 3) delegate actuial executioin based on some variable to actual implementation (ppml-old - pmml-new, jpmml) > This "wrapper" should also be invoked by ApplyPmmlModelCommandExecutorImpl -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ] Gabriele Cardosi commented on DROOLS-5372: ------------------------------------------ Most cost-effective solution would be: # 1) create a new Command with API tailored for new kie-pmml (see ApplyPmmlModelCommand as example) # 2) verify the behavior when *both* `PMMLAssemblerService`s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "property" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshofit/docker" images wher both modules are expected to be present in the classpath # 2) inside DMN: ## 1) inside `AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...)` add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath > Investigate PMML abstraction/coexistence > ----------------------------------------- > > Key: DROOLS-5372 > URL: https://issues.redhat.com/browse/DROOLS-5372 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > New and old PMML implementations should live together for some time. > USer should be able to choose implementation. > Consider creating a "proxy" pmml-module that > 1) declare PMMLAssemblerService > 2) declare PMMLRuntime > 3) delegate actuial executioin based on some variable to actual implementation (ppml-old - pmml-new, jpmml) > This "wrapper" should also be invoked by ApplyPmmlModelCommandExecutorImpl -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13560) Enhance Elytron AuditLogging Document

by Darran Lofthouse (Jira)

Darran Lofthouse created WFLY-13560: --------------------------------------- Summary: Enhance Elytron AuditLogging Document Key: WFLY-13560 URL: https://issues.redhat.com/browse/WFLY-13560 Project: WildFly Issue Type: Feature Request Components: Documentation, Security Reporter: Darran Lofthouse The audit logging documentation covers the resources that can be defined but really it needs to have further information on how to enable audit logging within the event handling framework. Additionally we should have documentation for the kinds of events we can emit. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields

by Alexandru Ciouca (Jira)

Alexandru Ciouca created WFLY-13559: --------------------------------------- Summary: Header response has changed and missing fields Key: WFLY-13559 URL: https://issues.redhat.com/browse/WFLY-13559 Project: WildFly Issue Type: Bug Affects Versions: 19.1.0.Final Reporter: Alexandru Ciouca Assignee: Brian Stansberry I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19? Response WildFly 18.0.0.final: {code} HTTP/2 500 cache-control: no-store, no-cache, must-revalidate set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN content-type: application/json content-length: 182 link: <http://test.com/afs/rest>; rel="profile" date: Thu, 04 Jun 2020 07:34:10 GMT set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure strict-transport-security: max-age=31536000; includeSubdomains x-xss-protection: 1; mode=block x-content-type-options: nosniff x-frame-options: SAMEORIGIN {code} Response WildFly 19.1.0.final: {code} HTTP/2 200 set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices content-type: application/json content-length: 182 date: Thu, 04 Jun 2020 07:27:57 GMT set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure cache-control: private strict-transport-security: max-age=31536000; includeSubdomains x-xss-protection: 1; mode=block x-content-type-options: nosniff x-frame-options: SAMEORIGIN {code} As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing. I am attaching also the standalone.xml for both versions. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13063) Change default values of id-cache-size or confirmation-window-size for cluster connections

by Michal Petrov (Jira)

[ https://issues.redhat.com/browse/WFLY-13063?page=com.atlassian.jira.plugi... ] Michal Petrov reassigned WFLY-13063: ------------------------------------ Assignee: Michal Petrov (was: Justin Bertram) > Change default values of id-cache-size or confirmation-window-size for cluster connections > ------------------------------------------------------------------------------------------ > > Key: WFLY-13063 > URL: https://issues.redhat.com/browse/WFLY-13063 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 19.0.0.Beta2 > Reporter: Simon Priadka > Assignee: Michal Petrov > Priority: Major > > When establishing a new messaging cluster, default values of *id-cache-size* and *confirmation-window-size* are producing a *WARN* with following message: > {code} > 2020-02-04 21:35:20,228 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-client-global-threads)) AMQ224078: The size of duplicate cache detection (<id_cache-size/>) appears to be too large 20,000. It should be no greater than the number of messages that can be squeezed into confirmation window buffer (<confirmation-window-size/>) 1,048,576. > {code} > According to the [method|https://github.com/apache/activemq-artemis/blob/3743bc9d9f39b0731f...] validating these values, this variable combination is "invalid" -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13063) Change default values of id-cache-size or confirmation-window-size for cluster connections

by Michal Petrov (Jira)

[ https://issues.redhat.com/browse/WFLY-13063?page=com.atlassian.jira.plugi... ] Michal Petrov commented on WFLY-13063: -------------------------------------- Looking at this more the change that introduced the size check also changed other confirmation windows sizes so this looks like an oversight on their part. I'm going to change the value. > Change default values of id-cache-size or confirmation-window-size for cluster connections > ------------------------------------------------------------------------------------------ > > Key: WFLY-13063 > URL: https://issues.redhat.com/browse/WFLY-13063 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 19.0.0.Beta2 > Reporter: Simon Priadka > Assignee: Justin Bertram > Priority: Major > > When establishing a new messaging cluster, default values of *id-cache-size* and *confirmation-window-size* are producing a *WARN* with following message: > {code} > 2020-02-04 21:35:20,228 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-client-global-threads)) AMQ224078: The size of duplicate cache detection (<id_cache-size/>) appears to be too large 20,000. It should be no greater than the number of messages that can be squeezed into confirmation window buffer (<confirmation-window-size/>) 1,048,576. > {code} > According to the [method|https://github.com/apache/activemq-artemis/blob/3743bc9d9f39b0731f...] validating these values, this variable combination is "invalid" -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2482) Check if the largest thread pool is cluster-size + delta

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2482?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2482: -------------------------------- When running {{UPerf}} with {{<CLEAR_FLAGS internal="true" oob="true"/>}} (which makes *all* messages regular), then the largest thread pool size is ~5. This points to {{OOB}} and/or {{INTERNAL}} messages being the culprit: these are forwarded to the thread pool by {{MaxOneThreadPerSender}}, regardless of sender. Next step: find out what OOB or INTERNAL messages are received (UNICAST3 ACKs?) and see if the high number of these messages is correct. > Check if the largest thread pool is cluster-size + delta > -------------------------------------------------------- > > Key: JGRP-2482 > URL: https://issues.redhat.com/browse/JGRP-2482 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Final > > > When running UPerf in a cluster of 4, we see {{thread_pool_size_largest=39}}. Verify that MaxOneThreadPerSender works as expected: the largest thread pool size should be 4+delta (timer threads, retransmission): ~6. > It looks as if {{MPerf}} behaves (~6 threads), but {{UPerf}} doesn't: ~26 threads -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13558) Upgrade WildFly Core 12.0.1.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13558?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-13558: ------------------------------- Description: Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.1.Final Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Final...12.0.1.Final was: Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Final Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta4...12.0.0.Final > Upgrade WildFly Core 12.0.1.Final > --------------------------------- > > Key: WFLY-13558 > URL: https://issues.redhat.com/browse/WFLY-13558 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 20.0.0.Final > > > Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.1.Final > Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Final...12.0.1.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13558) Upgrade WildFly Core 12.0.1.Final

by Jeff Mesnil (Jira)

Jeff Mesnil created WFLY-13558: ---------------------------------- Summary: Upgrade WildFly Core 12.0.1.Final Key: WFLY-13558 URL: https://issues.redhat.com/browse/WFLY-13558 Project: WildFly Issue Type: Component Upgrade Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 20.0.0.Final Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Final Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta4...12.0.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5413) Verifier breaks for multi template key BRL actions

by Jozef Marko (Jira)

Jozef Marko created DROOLS-5413: ----------------------------------- Summary: Verifier breaks for multi template key BRL actions Key: DROOLS-5413 URL: https://issues.redhat.com/browse/DROOLS-5413 Project: Drools Issue Type: Bug Components: Guided Decision Table Editor Affects Versions: 7.39.0.Final Reporter: Jozef Marko Assignee: Toni Rikkola Attachments: MySpace_whenandwhere.zip, Screenshot from 2020-06-04 15-12-33.png The Verifier feature throws an error when opening a table that contains specific combination of template keys in BRL action column. It seems as issue of one of columns bound to the template key is Date type. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2020