[JBoss JIRA] (WFLY-13063) Change default values of id-cache-size or confirmation-window-size for cluster connections
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13063?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13063:
----------------------------------
Component/s: JMS
(was: Clustering)
Fixing component. This is not a clustering component issue, but JMS component issue.
[~ehugonnet] FYI.
> 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: JMS
> 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, 7 months
[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 12:18 PM:
-------------------------------------------------------------------
Most cost-effective solution could be:
# create a new _Command_ with API tailored for new kie-pmml (see
{code:java}
ApplyPmmlModelCommand
{code}
as example)
# verify the behavior when *both*
{code:java}
PMMLAssemblerService
{code}
s (from old and new kie-pmml) are present in the classpath ( "openshift/docker" images):
## only one is invoked; evaluate how this may be managed when both modules are expected to be present in the classpath
# different issue for the PMMLRuntime, since it is defined and used in the new kie-pmml but not in the old one
# inside DMN:
## 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 could be:
# create a new _Command_ with API tailored for new kie-pmml (see
{code:java}
ApplyPmmlModelCommand
{code}
as example)
# verify the behavior when *both*
{code:java}
PMMLAssemblerService
{code}
s (from old and new kie-pmml) are present in the classpath:
## only one is invoked; evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath
# inside DMN:
## 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
> 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, 7 months