[JBoss JIRA] (DROOLS-5559) Kie-workbench and kie-server going OOM with subsequent build and deployment
by Sachin Kamath (Jira)
[ https://issues.redhat.com/browse/DROOLS-5559?page=com.atlassian.jira.plug... ]
Sachin Kamath updated DROOLS-5559:
----------------------------------
Priority: Critical (was: Major)
> Kie-workbench and kie-server going OOM with subsequent build and deployment
> ---------------------------------------------------------------------------
>
> Key: DROOLS-5559
> URL: https://issues.redhat.com/browse/DROOLS-5559
> Project: Drools
> Issue Type: Bug
> Components: Examples (Workbench), kie server
> Affects Versions: 7.31.0.Final
> Reporter: Sachin Kamath
> Assignee: David Gutierrez
> Priority: Critical
>
> Hi Team,
> We are using kie-workbench and kie-server for managing the rules using decision table spreadsheet. What we see is that, with continuous build and deployments being done, the servers are going out of memory. This is resulting in instability of the environment and frequent restarts are required to fix the issue.
> Here are the parameters:
> *kie-workbench* :
> Xms: 20G
> Xmx: 20G
> Metaspace Xmx:8G Xms:8G
> Using G1GC algorithm.
> *kie-server:*
> Xms: 4G
> Xmx: 4G
> Metaspace: Xmx:2G Xms:2G
> Using G1GC algorithm.
> *Steps for replication :*
> # Excel sheet has 50k rows.
> # Build the artifacts and deploy with version V1. The first deployment would be successful.
> # Change the version to V2 and deploy once again. Now we will have version V1 and V2 both in the kie-servers but V2 would be serving he requests.
> # Before deploying version V3, remove version V1. Build and deploy V3.
> # Now when deploying version V4, after removing the version V2, the kie-servers are going out of memory.
> Even though we are making sure that only last 2 valid versions are present, the servers are going out of memory. After restarting the servers, the last two valid versions V3 and V4 are successfully deployed again. The error in kie-servers clearly says Java heap space issue. But the point here is, it is fine after restart. I could sense there is some other problem. With visual VM, i could see that the memory consumption gradually increases with deployment of different versions but its not released as we remove the old version.
> Any pointers would be helpful here.
> Im really unsure if its a bug or im missing some parameters around it.
>
> Thanks
> Sachin
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-5414) DMN Validation rule check DecisionService at least 1 outputDecision
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5414?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5414:
-----------------------------------
Description:
it is redundant to XSD
!screenshot-1.png|thumbnail!
but the DMN specification version 1.3 contains a bug in the XSD implementation https://issues.omg.org/browse/DMN14-93 so this would solve until it is resolved at the DMN specification level with the XSD correction.
was:
it is redundant to XSD
!screenshot-1.png|thumbnail!
however given the low effort is good to implement anyway for those use-case where XSD validation is skipped.
> DMN Validation rule check DecisionService at least 1 outputDecision
> -------------------------------------------------------------------
>
> Key: DROOLS-5414
> URL: https://issues.redhat.com/browse/DROOLS-5414
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
> Labels: good-first-issue
> Attachments: screenshot-1.png
>
>
> it is redundant to XSD
> !screenshot-1.png|thumbnail!
> but the DMN specification version 1.3 contains a bug in the XSD implementation https://issues.omg.org/browse/DMN14-93 so this would solve until it is resolved at the DMN specification level with the XSD correction.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ]
Chao Wang commented on WFLY-13793:
----------------------------------
hmm.. queue/topic prefix is hardcoded as part of queue/topic name
https://github.com/wildfly/wildfly/blob/20.0.1.Final/messaging-activemq/s...
https://github.com/wildfly/wildfly/blob/20.0.1.Final/messaging-activemq/s...
Hi [~ehugonnet], what's your thought on this? should it be allowed to configure the prefix of external jms queue/topic as {{enable-amq1-prefix}} does ?
> Attribute enable-amq1-prefix doesn't work (remote artemis)
> ----------------------------------------------------------
>
> Key: WFLY-13793
> URL: https://issues.redhat.com/browse/WFLY-13793
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Management
> Affects Versions: 20.0.1.Final
> Reporter: Nicolas De Amicis
> Assignee: Chao Wang
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error:
> {quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}}
> \{{{}}
> \{{ "outcome" => "failed",}}
> \{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}}
> {{OPIC, TOPIC, QUEUE, XA_QUEUE]",}}
> \{{ "rolled-back" => true}}
> {{}}}
> {quote}
> If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue.
> I also tried to add the attribute manually but it seems it doesn't work:
> {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}}
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months