December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12876) Memory leak in OpenTracing when deployment is redeployed multiple times

by Miroslav Novak (Jira)

Miroslav Novak created WFLY-12876: ------------------------------------- Summary: Memory leak in OpenTracing when deployment is redeployed multiple times Key: WFLY-12876 URL: https://issues.redhat.com/browse/WFLY-12876 Project: WildFly Issue Type: Bug Components: MP OpenTracing Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final Reporter: Miroslav Novak Assignee: Emmanuel Hugonnet Attachments: memory-leak-bad.png, memory-leak-good.png There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. Test and deployment is same as is described in WFLY-10991. Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: {code} /subsystem=microprofile-opentracing-smallrye:remove() {code} the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1036) Adjust tests https://github.com/kiali/kiali/issues/1474

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1036: ------------------------------------- Summary: Adjust tests https://github.com/kiali/kiali/issues/1474 Key: SWSQE-1036 URL: https://issues.redhat.com/browse/SWSQE-1036 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times

by Miroslav Novak (Jira)

[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ] Miroslav Novak commented on WFLY-12486: --------------------------------------- Raising to blocker as MP Opentracing subsystem is enabled by default and even deployment which is not using it is causing OOME when continuously redeployed. > Memory leak in OpenTracing when deployment is redeployed multiple times > ----------------------------------------------------------------------- > > Key: WFLY-12486 > URL: https://issues.redhat.com/browse/WFLY-12486 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final > Reporter: Jan Stourac > Assignee: Emmanuel Hugonnet > Priority: Blocker > Attachments: memory-leak-bad.png, memory-leak-good.png > > > There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. > Test and deployment is same as is described in WFLY-10991. > Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. > I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. > Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12486: ---------------------------------- Priority: Blocker (was: Critical) > Memory leak in OpenTracing when deployment is redeployed multiple times > ----------------------------------------------------------------------- > > Key: WFLY-12486 > URL: https://issues.redhat.com/browse/WFLY-12486 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final > Reporter: Jan Stourac > Assignee: Emmanuel Hugonnet > Priority: Blocker > Attachments: memory-leak-bad.png, memory-leak-good.png > > > There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. > Test and deployment is same as is described in WFLY-10991. > Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. > I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. > Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times

by Miroslav Novak (Jira)

[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ] Miroslav Novak updated WFLY-12486: ---------------------------------- Affects Version/s: 18.0.1.Final > Memory leak in OpenTracing when deployment is redeployed multiple times > ----------------------------------------------------------------------- > > Key: WFLY-12486 > URL: https://issues.redhat.com/browse/WFLY-12486 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final > Reporter: Jan Stourac > Assignee: Emmanuel Hugonnet > Priority: Critical > Attachments: memory-leak-bad.png, memory-leak-good.png > > > There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. > Test and deployment is same as is described in WFLY-10991. > Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. > I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. > Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1035) Wizard - TLS MUTUAL

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1035: ------------------------------------- Summary: Wizard - TLS MUTUAL Key: SWSQE-1035 URL: https://issues.redhat.com/browse/SWSQE-1035 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Client Certificate Private Key -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1034) Wizard - 3scale API Management Rule

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1034: ------------------------------------- Summary: Wizard - 3scale API Management Rule Key: SWSQE-1034 URL: https://issues.redhat.com/browse/SWSQE-1034 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Automate CRUD scenario. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3761) [DMN Designer] Data Types - Constraints - Enumeration constraint entry on edit mode - Fix buttons behavior

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-3761?page=com.atlassian.jira.plug... ] Jozef Marko closed DROOLS-3761. ------------------------------- Resolution: Explained > [DMN Designer] Data Types - Constraints - Enumeration constraint entry on edit mode - Fix buttons behavior > ---------------------------------------------------------------------------------------------------------- > > Key: DROOLS-3761 > URL: https://issues.redhat.com/browse/DROOLS-3761 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.19.0.Final > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Priority: Minor > Labels: drools-tools > Attachments: constraint_unsaved.png, focus_lost.webm, lost_focus_data_types.webm > > > The attached video shows the user interaction with enumeration constraint component. We can see if user fill valid values and clicks somewhere outside of the entry in edit mode, the values are lost. The only way how to save values is to click the *check* button. User should not lost filled in values if he clicks outside of input fields. > Please compare the same behavior with data types list view component. It means [^focus_lost.webm] vs [^lost_focus_data_types.webm] . -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-285) MP Fault Tolerance - Fault Tolerance is activated by deployment without MP FT

by Miroslav Novak (Jira)

Miroslav Novak created WFWIP-285: ------------------------------------ Summary: MP Fault Tolerance - Fault Tolerance is activated by deployment without MP FT Key: WFWIP-285 URL: https://issues.redhat.com/browse/WFWIP-285 Project: WildFly WIP Issue Type: Bug Components: MP Fault Tolerance Reporter: Miroslav Novak Assignee: Radoslav Husar Once microprofile-fault-tolerance extension/subsystem is added then deployment wihtout MP FT activates it: {code} 16:40:40,525 INFO [io.smallrye.faulttolerance.HystrixExtension] (MSC service thread 1-1) MicroProfile: Fault Tolerance activated {code} Actual Result: Deployment without MP Fault Tolerance activates MP FT. Expected Result: Deployment without MP Fault Tolerance must not activate MP FT. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4799) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4799?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4799: ------------------------------------- [~yamer] I think we should save just the the picked option and even do not inform user about losing some values from the unpicked option. For me it seems quite common in this kind of forms . (Radio button group, according your choice subform is changed). [~uxdlc] hello, I think theoretically both has same expressing power, however technically not sure if we will implement parsing on both in the way, user can express the same in both options. For example, I can imagine, in both options user can create list of string, but just in one list of persons, do you see my point? > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4799 > URL: https://issues.redhat.com/browse/DROOLS-4799 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing, Test Scenarios Editor > Reporter: Yeser Amer > Assignee: Elizabeth Clayton > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screen Shot 2019-11-26 at 1.26.54 PM.png, dmn-dt-enumeration-constraint.png, dmn-dt-expression-constraint.png, expression-list_error.png, scesim-list.png > > > I need a clarification regarding the behaviour of the updated Collection Editor, in particular for this section -->https://marvelapp.com/5ab248j/screen/62093042/layer/102496330. > Considering the editor introduces a new way to handle a Collection ("Define List"), can you please give us detailed behaviour for the following case: > - What happen if a user starts to input data inside a section (Define List/Create List) and then switch on the other one? > eg. if I start to define a List using "Define List" option (i.e. an expression) and then I change to "Create List" case. What should happen? > - Currently, after adding a Collection, the Grid cell will show "List (1)". It should be the same for "Define list" (i.e. Expression) case? > In case of additional clarificaiton, I'll update this ticket. > Hope it's clear, if not you can contact me anytime. > Thanks -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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 December 2019