January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2429) MsgStats num_bytes_sent should be incremented by the Message::size

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/JGRP-2429?page=com.atlassian.jira.plugin... ] Dan Berindei commented on JGRP-2429: ------------------------------------ [~belaban] is the fact that "number of bytes sent" means "number of payload bytes sent" documented anywhere? I'm pretty sure in {{doSend()}} {{length}} is the number of actual bytes sent, **not** the payload length. > MsgStats num_bytes_sent should be incremented by the Message::size > ------------------------------------------------------------------ > > Key: JGRP-2429 > URL: https://issues.redhat.com/browse/JGRP-2429 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 4.1.9 > > > MsgStats num_bytes_sent should be incremented by the Message::size > Today it is incremented by the Message:length that is the length of the payload, it doesn't include the headers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4902) Can not use mod operators (%) in when closures.

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4902?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-4902: -------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > Can not use mod operators (%) in when closures. > ----------------------------------------------- > > Key: DROOLS-4902 > URL: https://issues.redhat.com/browse/DROOLS-4902 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.31.0.Final > Reporter: xb l > Assignee: Mario Fusco > Priority: Major > > When I study drools , I write a rule use divide operator > {code:java} > rule "Buzz" salience 2 > when > $n: Number( this / 5 == 3 ) > then > System.out.println("Buzz"); > end > {code} > It's OK. > But: > {code:java} > rule "Buzz" salience 2 > when > $n: Number( this % 5 == 0 ) > then > System.out.println("Buzz"); > end > {code} > Report parser error: Unable to Analyse Expression this % 5 == 0: -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ] Jean Francois Denise updated WFCORE-4785: ----------------------------------------- Attachment: after-reload.hprof > PathAddress leaked on reload > ---------------------------- > > Key: WFCORE-4785 > URL: https://issues.redhat.com/browse/WFCORE-4785 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jean Francois Denise > Assignee: Jeff Mesnil > Priority: Major > Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml > > > Boot server, connect CLI and reload. > As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). > Attached heapdump, server.log and configuration used (reduced standalone.xml). > server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. > server.log contains stacktrace of PathAddress allocation. > You will notice: > 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. > 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. > 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. > 4) We have 3 remaining PathAddress 149, 600 and 789 > 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. > So we have a leak of 1 PathAddress instance, instance 149. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ] Jean Francois Denise updated WFCORE-4785: ----------------------------------------- Attachment: nominal.hprof > PathAddress leaked on reload > ---------------------------- > > Key: WFCORE-4785 > URL: https://issues.redhat.com/browse/WFCORE-4785 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jean Francois Denise > Assignee: Jeff Mesnil > Priority: Major > Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml > > > Boot server, connect CLI and reload. > As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). > Attached heapdump, server.log and configuration used (reduced standalone.xml). > server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. > server.log contains stacktrace of PathAddress allocation. > You will notice: > 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. > 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. > 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. > 4) We have 3 remaining PathAddress 149, 600 and 789 > 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. > So we have a leak of 1 PathAddress instance, instance 149. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ] Jean Francois Denise updated WFCORE-4785: ----------------------------------------- Attachment: server.log > PathAddress leaked on reload > ---------------------------- > > Key: WFCORE-4785 > URL: https://issues.redhat.com/browse/WFCORE-4785 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jean Francois Denise > Assignee: Jeff Mesnil > Priority: Major > Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml > > > Boot server, connect CLI and reload. > As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). > Attached heapdump, server.log and configuration used (reduced standalone.xml). > server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. > server.log contains stacktrace of PathAddress allocation. > You will notice: > 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. > 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. > 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. > 4) We have 3 remaining PathAddress 149, 600 and 789 > 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. > So we have a leak of 1 PathAddress instance, instance 149. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ] Jean Francois Denise updated WFCORE-4785: ----------------------------------------- Attachment: standalone-minimal2.xml > PathAddress leaked on reload > ---------------------------- > > Key: WFCORE-4785 > URL: https://issues.redhat.com/browse/WFCORE-4785 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jean Francois Denise > Assignee: Jeff Mesnil > Priority: Major > Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml > > > Boot server, connect CLI and reload. > As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). > Attached heapdump, server.log and configuration used (reduced standalone.xml). > server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. > server.log contains stacktrace of PathAddress allocation. > You will notice: > 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. > 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. > 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. > 4) We have 3 remaining PathAddress 149, 600 and 789 > 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. > So we have a leak of 1 PathAddress instance, instance 149. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload

by Jean Francois Denise (Jira)

Jean Francois Denise created WFCORE-4785: -------------------------------------------- Summary: PathAddress leaked on reload Key: WFCORE-4785 URL: https://issues.redhat.com/browse/WFCORE-4785 Project: WildFly Core Issue Type: Bug Components: Management Reporter: Jean Francois Denise Assignee: Jeff Mesnil Boot server, connect CLI and reload. As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). Attached heapdump, server.log and configuration used (reduced standalone.xml). server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. server.log contains stacktrace of PathAddress allocation. You will notice: 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. 4) We have 3 remaining PathAddress 149, 600 and 789 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. So we have a leak of 1 PathAddress instance, instance 149. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12927) wildfly 8.2 huge memory allocation during and after deployement

by sandev sandev (Jira)

[ https://issues.redhat.com/browse/WFLY-12927?page=com.atlassian.jira.plugi... ] sandev sandev updated WFLY-12927: --------------------------------- Issue Type: Bug (was: Feature Request) > wildfly 8.2 huge memory allocation during and after deployement > --------------------------------------------------------------- > > Key: WFLY-12927 > URL: https://issues.redhat.com/browse/WFLY-12927 > Project: WildFly > Issue Type: Bug > Reporter: sandev sandev > Assignee: Brian Stansberry > Priority: Major > Attachments: threads.png > > > I am using wildfly 8.2.1 final to deploy java ee 7 maven web application wars about 30 war with dependence between them using rmi remote ejb. I found that the server consumes a lot of memory special on startup of the server to 8 g my java opt are -xms 8g -xmx 8g -metaspacesize 1g .so I use java "visualvm" to understand what is happening. I found that the most consumed memory is for 2 types of threads at deploy: MSC service thread and after deploy finish: DeployementScanner-threads in additional that no user use the server or the deployed application this server was just for test > my question is why wildfly starts with about 3g and after some time the memory growth to ~= 8g without any action on the server its idle any help to solve this problem please -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4779) Upgrade Woodstox from 5.0.3 to 6.0.3

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4779?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4779: -------------------------------- Component/s: Management (was: Build System) > Upgrade Woodstox from 5.0.3 to 6.0.3 > ------------------------------------ > > Key: WFCORE-4779 > URL: https://issues.redhat.com/browse/WFCORE-4779 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Management > Reporter: Ilia Vassilev > Assignee: Jeff Mesnil > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12927) wildfly 8.2 huge memory allocation during and after deployement

by sandev sandev (Jira)

[ https://issues.redhat.com/browse/WFLY-12927?page=com.atlassian.jira.plugi... ] sandev sandev updated WFLY-12927: --------------------------------- Attachment: threads.png > wildfly 8.2 huge memory allocation during and after deployement > --------------------------------------------------------------- > > Key: WFLY-12927 > URL: https://issues.redhat.com/browse/WFLY-12927 > Project: WildFly > Issue Type: Feature Request > Reporter: sandev sandev > Assignee: Brian Stansberry > Priority: Major > Attachments: threads.png > > > I am using wildfly 8.2.1 final to deploy java ee 7 maven web application wars about 30 war with dependence between them using rmi remote ejb. I found that the server consumes a lot of memory special on startup of the server to 8 g my java opt are -xms 8g -xmx 8g -metaspacesize 1g .so I use java "visualvm" to understand what is happening. I found that the most consumed memory is for 2 types of threads at deploy: MSC service thread and after deploy finish: DeployementScanner-threads in additional that no user use the server or the deployed application this server was just for test > my question is why wildfly starts with about 3g and after some time the memory growth to ~= 8g without any action on the server its idle any help to solve this problem please -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 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 January 2020