[Red Hat JIRA] (WFLY-14372) Multiple metrics collections
by Jason Lee (Jira)
[ https://issues.redhat.com/browse/WFLY-14372?page=com.atlassian.jira.plugi... ]
Jason Lee commented on WFLY-14372:
----------------------------------
Turns out, I was mistaken. :) With improved debugging logging, I can see where we are, indeed, scanning things at least twice, and sometimes 4 times. When a MP Metrics app is installed and the server (re)started/reloaded, we can see the two DPUs (WF metrics and MP Metrics) each scan the app. The two subsystem add processes also scan the system, resulting in the duplicate scans. The "four" part comes in with the application: there are two scans from the DPU, and two more attempts from the subsystems, though these additional scans are shallow and do not recurse into the application.
To fix the situation, we should make sure that the WF subsystem add and the WF metrics DPUs do not scan when the MP Metrics module is added, perhaps using the Capabilities system to identify the scenario. We may also need to prevent the subsystem add scans skip deployments, allowing the DPUs to handle that. I'll need to verify that with Brian, though.
I'm converting this ticket to a Bug to track the changes.
> Multiple metrics collections
> ----------------------------
>
> Key: WFLY-14372
> URL: https://issues.redhat.com/browse/WFLY-14372
> Project: WildFly
> Issue Type: Task
> Components: MP Metrics
> Reporter: Brian Stansberry
> Assignee: Jason Lee
> Priority: Critical
>
> See discussion on https://github.com/wildfly/wildfly/pull/13871
> Do we have MetricsCollector collecting the container metrics multiple times?
> I haven't thought hard about this, but doesn't the Stage.VERIFY collection in MetricsSubsystemAdd end up re-collecting all the deployment=* subtree metrics already collected in Stage.RUNTIME via DeploymentMetricProcessor/DeploymentMetricService? It walks the whole resource tree from the root.
> If the MP Metrics subsystem is installed, isn't MicroProfileMetricsSubsystemAdd and that subsystem's DeploymentMetricProcessor/DeploymentMetricService also collecting the same set of metrics?
> I'm filing this as a Task because maybe all that's needed is to investigate and answer those questions reporting that all is well. But if all isn't well this should converted to a Bug.
> Also, as discussed on PR #13871, https://github.com/wildfly/wildfly/blob/22.0.0.Final/metrics/src/main/jav... is probably not the best idiom given the code is iterating over runtime-only resources, where the cost of hasChildren can be high.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5877) Support MVEL BLiteral in the exec model
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5877?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5877:
----------------------------------------
if it doesn't reproduce error, the better! (y)
> Support MVEL BLiteral in the exec model
> ---------------------------------------
>
> Key: DROOLS-5877
> URL: https://issues.redhat.com/browse/DROOLS-5877
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> It seems like it's already supported in the consequence
>
> [https://github.com/kiegroup/drools/blob/6408b5e1caa1e5c5fe94e45f82e1bedfb...]
>
>
> {code:java}
> package com.myspace.check20201202;
> //from row number: 1
> rule "Row 1 MatteoTable"
> dialect "mvel"
> when
> f1 : Person( age >= 18B )
> then
> f1.setMinor( false );
> end
> //from row number: 2
> rule "Row 2 MatteoTable"
> dialect "mvel"
> when
> f1 : Person( age < 18B )
> then
> f1.setMinor( true );
> end
> package com.myspace.check20201202;
> import java.math.BigDecimal;
> /**
> * This class was automatically generated by the data modeler tool.
> */
> public class Person implements java.io.Serializable {
> static final long serialVersionUID = 1L;
> private java.lang.String name;
> private BigDecimal age;
> private java.lang.Boolean minor;
> public Person() {
> }
> public java.lang.String getName() {
> return this.name;
> }
> public void setName(java.lang.String name) {
> this.name = name;
> }
> public java.lang.Boolean getMinor() {
> return this.minor;
> }
> public void setMinor(java.lang.Boolean minor) {
> this.minor = minor;
> }
> public java.math.BigDecimal getAge() {
> return this.age;
> }
> public void setAge(java.math.BigDecimal age) {
> this.age = age;
> }
> public Person(java.lang.String name, java.math.BigDecimal age,
> java.lang.Boolean minor) {
> this.name = name;
> this.age = age;
> this.minor = minor;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFCORE-5274) The reload operation for credential-store appears broken.
by Darran Lofthouse (Jira)
Darran Lofthouse created WFCORE-5274:
----------------------------------------
Summary: The reload operation for credential-store appears broken.
Key: WFCORE-5274
URL: https://issues.redhat.com/browse/WFCORE-5274
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Darran Lofthouse
The operation obtains a reference to the credential store service and manually stops it before starting it again:
{code:java}
credentialStoreService.stop(null);
credentialStoreService.start(null); {code}
This does mean the credential store referenced by the service will have been reloaded and replaced but any services which obtained their own reference to the credential store will have an old reference.
It may be better if the credential store SPIs had their own direct reload method, alternatively maybe a call to initialise should be used instead to trigger a re-initialisation of the store.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5877) Support MVEL BLiteral in the exec model
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5877?page=com.atlassian.jira.plug... ]
Luca Molteni resolved DROOLS-5877.
----------------------------------
Resolution: Cannot Reproduce
Cannot reproduce on 7.50.0-SNAPSHOT with this test
{code:java}
@Test
public void testBigDecimalLiterals() {
String str =
"import " + Person.class.getCanonicalName() + "\n" +
"global java.util.List withMoney;\n" +
"global java.util.List withoutMoney;\n" +
"rule \"rule1\"\n" +
" dialect \"mvel\"\n" +
" when\n" +
" $pwm : Person( money >= 1000B )\n" +
" then\n" +
" withMoney.add($pwm)\n" +
"end\n" +
"\n" +
"rule \"rule2\"\n" +
" dialect \"mvel\"\n" +
" when\n" +
" $pnm : Person( money < 1000B )\n" +
" then\n" +
" withoutMoney.add($pnm)\n" +
"end";
KieSession ksession = getKieSession(str);
List<Person> withMoney = new ArrayList<>();
ksession.setGlobal("withMoney", withMoney);
List<Person> withoutMoney = new ArrayList<>();
ksession.setGlobal("withoutMoney", withoutMoney);
Person luca = new Person("luca", BigDecimal.valueOf(1000));
Person leonardo = new Person("Leonardo", BigDecimal.valueOf(999));
ksession.insert(luca);
ksession.insert(leonardo);
ksession.fireAllRules();
assertThat(withMoney).containsOnly(luca);
assertThat(withoutMoney).containsOnly(leonardo);
}
{code}
[~tari_manga] we should verify the original decision table against 7.50.0-SNAPSHOT
> Support MVEL BLiteral in the exec model
> ---------------------------------------
>
> Key: DROOLS-5877
> URL: https://issues.redhat.com/browse/DROOLS-5877
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> It seems like it's already supported in the consequence
>
> [https://github.com/kiegroup/drools/blob/6408b5e1caa1e5c5fe94e45f82e1bedfb...]
>
>
> {code:java}
> package com.myspace.check20201202;
> //from row number: 1
> rule "Row 1 MatteoTable"
> dialect "mvel"
> when
> f1 : Person( age >= 18B )
> then
> f1.setMinor( false );
> end
> //from row number: 2
> rule "Row 2 MatteoTable"
> dialect "mvel"
> when
> f1 : Person( age < 18B )
> then
> f1.setMinor( true );
> end
> package com.myspace.check20201202;
> import java.math.BigDecimal;
> /**
> * This class was automatically generated by the data modeler tool.
> */
> public class Person implements java.io.Serializable {
> static final long serialVersionUID = 1L;
> private java.lang.String name;
> private BigDecimal age;
> private java.lang.Boolean minor;
> public Person() {
> }
> public java.lang.String getName() {
> return this.name;
> }
> public void setName(java.lang.String name) {
> this.name = name;
> }
> public java.lang.Boolean getMinor() {
> return this.minor;
> }
> public void setMinor(java.lang.Boolean minor) {
> this.minor = minor;
> }
> public java.math.BigDecimal getAge() {
> return this.age;
> }
> public void setAge(java.math.BigDecimal age) {
> this.age = age;
> }
> public Person(java.lang.String name, java.math.BigDecimal age,
> java.lang.Boolean minor) {
> this.name = name;
> this.age = age;
> this.minor = minor;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14380) Cant configure Let's Encrypt simple steps
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-14380?page=com.atlassian.jira.plugi... ]
Farah Juma commented on WFLY-14380:
-----------------------------------
{quote}
Another small thing is that when it finished the server was rebooted instead of only reload the certificate...
{quote}
When using the {{security enable-ssl-http-server}} command, the server will be automatically reloaded for you since this command is also configuring an {{ssl-context}} for your server and updating Undertow to make use of this newly configured {{ssl-context}}. When it is time to renew your certificate, you will only need to re-initialize your {{key-manager}}.
> Cant configure Let's Encrypt simple steps
> -----------------------------------------
>
> Key: WFLY-14380
> URL: https://issues.redhat.com/browse/WFLY-14380
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 22.0.0.Final
> Reporter: erick leal
> Priority: Major
> Attachments: Capturar-1.PNG, Capturar.PNG, Capturar5-1.PNG, Capturar5.PNG, ddd.PNG
>
>
> I'm tyring to configure Let's Encrypt in my server, and I followed instructions that said to simple type security enable-ssl-http-server --interactive --lets-encrypt
> But I believe because I'm in Windows I ran into the issue described in the picture below
> !Capturar.PNG!
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14408) CLI journal-import command fails if in-vm connector has a server-id other than "0"
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-14408?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet updated WFLY-14408:
-------------------------------------
Labels: artemis messaging (was: artemis cli messaging)
> CLI journal-import command fails if in-vm connector has a server-id other than "0"
> ----------------------------------------------------------------------------------
>
> Key: WFLY-14408
> URL: https://issues.redhat.com/browse/WFLY-14408
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 22.0.0.Final
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
> Labels: artemis, messaging
>
> If the in-vm-connector / in-vm-acceptor for the default / live messaging-activemq server is configured with a server-id higher than "0":
> {code}
> <in-vm-connector name="in-vm-connector1" server-id="1"/>
> {code}
> then performing an import-journal operation from the cli fails with a rather unhelpful "Cannot connect to server(s)" message:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=ServerLive:import-journal(file=/home/jboss/messages.xml) { "outcome" => "failed", "failure-description" => "AMQ219007: Cannot connect to server(s). Tried with all available servers.", "rolled-back" => true }
> {code}
> After much debugging, resetting the server-id to "0" on the live server in-vm acceptor and connector and from "2" to "1" on the backup resolved the issue and the import succeeded.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14408) journal-import command fails if in-vm connector has a server-id other than "0"
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-14408?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet updated WFLY-14408:
-------------------------------------
Summary: journal-import command fails if in-vm connector has a server-id other than "0" (was: CLI journal-import command fails if in-vm connector has a server-id other than "0")
> journal-import command fails if in-vm connector has a server-id other than "0"
> ------------------------------------------------------------------------------
>
> Key: WFLY-14408
> URL: https://issues.redhat.com/browse/WFLY-14408
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 22.0.0.Final
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
> Labels: artemis, messaging
>
> If the in-vm-connector / in-vm-acceptor for the default / live messaging-activemq server is configured with a server-id higher than "0":
> {code}
> <in-vm-connector name="in-vm-connector1" server-id="1"/>
> {code}
> then performing an import-journal operation from the cli fails with a rather unhelpful "Cannot connect to server(s)" message:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=ServerLive:import-journal(file=/home/jboss/messages.xml) { "outcome" => "failed", "failure-description" => "AMQ219007: Cannot connect to server(s). Tried with all available servers.", "rolled-back" => true }
> {code}
> After much debugging, resetting the server-id to "0" on the live server in-vm acceptor and connector and from "2" to "1" on the backup resolved the issue and the import succeeded.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months