[JBoss JIRA] (WFWIP-134) Bad WARN messages: AMQ222211: Storage is back to stable now...
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFWIP-134?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet resolved WFWIP-134.
-------------------------------------
Resolution: Out of Date
> Bad WARN messages: AMQ222211: Storage is back to stable now...
> --------------------------------------------------------------
>
> Key: WFWIP-134
> URL: https://issues.redhat.com/browse/WFWIP-134
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Francesco Nigro
> Priority: Major
>
> There are unwanted WARN messages:
> {code}
> 13:47:48,158 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 15.0.0.Alpha1-SNAPSHOT (WildFly Core 7.0.0.Alpha4) started in 8017ms - Started 495 of 723 services (489 services are lazy, passive or on-demand)
> 13:47:50,235 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222183: Blocking message production on address 'jms.queue.InQueue'; size is currently: 10,635,300 bytes; max-size-bytes on address: 10,485,760, global-max-size is 10,635,300
> 13:47:52,642 WARN [org.apache.activemq.artemis.core.server] (Thread-4 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage.
> 13:47:57,642 WARN [org.apache.activemq.artemis.core.server] (Thread-15 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage.
> ...
> {code}
> when server has configured {{global-max-memory-size}} and address-full-policy to BLOCK. Once {{global-max-memory-size}} then starts to log above warnings which with max-disk-usage. Which is not correct as no disk limitation was reached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4607) DMN DT Analysis for symbols
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-4607?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-4607:
-----------------------------------
Sprint: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 07-09 (from Feb 10) (was: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 04-06 (from Jan 20))
> DMN DT Analysis for symbols
> ---------------------------
>
> Key: DROOLS-4607
> URL: https://issues.redhat.com/browse/DROOLS-4607
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> Extend analysis to symbolic processing in the possible cases
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4606) DMN alpha network
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-4606?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-4606:
-----------------------------------
Sprint: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 07-09 (from Feb 10) (was: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 04-06 (from Jan 20))
> DMN alpha network
> -----------------
>
> Key: DROOLS-4606
> URL: https://issues.redhat.com/browse/DROOLS-4606
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> Start refactoring work to support alpha network
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4950) Different behavior of collection unary checks
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4950?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-4950:
-------------------------------
Sprint: 2020 Week 04-06 (from Jan 20)
> Different behavior of collection unary checks
> ---------------------------------------------
>
> Key: DROOLS-4950
> URL: https://issues.redhat.com/browse/DROOLS-4950
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Critical
> Labels: drools-tools
> Attachments: MySpace_simplenumbers.zip, Screenshot from 2020-01-17 13-56-02.png, Screenshot from 2020-01-17 13-56-10.png
>
>
> Issue was spotted during DROOLS-4698 review. However it can be handled separately.
> There is issue that user can define collection unary test with UI editor [1] but also as plain text [2]. The problem is the result is different.
> [1]
> !Screenshot from 2020-01-17 13-56-02.png|thumbnail!
> [2]
> !Screenshot from 2020-01-17 13-56-10.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4645) High memory consumption with JIT
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4645?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4645:
--------------------------------
Sprint: 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 04-06 (from Jan 20) (was: 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 01-03 (from Dec 30))
> High memory consumption with JIT
> --------------------------------
>
> Key: DROOLS-4645
> URL: https://issues.redhat.com/browse/DROOLS-4645
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.29.0.Final
> Reporter: Radovan Synek
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: Screenshot from 2019-10-15 10-30-27.png, Screenshot from 2019-10-15 10-31-53.png
>
>
> Employee Rostering example for OptaPlanner shows excessive memory consumption, which is connected with Drools score calculation.
> Please see the reproducer - running it without drools JIT finishes on time with 3GB of memory while with drools JIT being active it fails due to "GC overhead limit exceeded" despite the fact it god twice as much memory.
> Logging (add -Dlogback.level.org.optaplanner=trace to the execute_jit.sh script) showed there is a huge pillar move changing ~hundreds of entities which takes seconds to calculate score. During this move's evaluation, the memory consumption increases to a point when GC takes over and later fails.
> Memory sampling and heap dump investigation showed there are ~10^7 objects of org.drools.core.reteoo.FromNodeLeftTuple class, taking more memory than any other data type in the VM.
> See the attached screenshots.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months