June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12166) Expose management metrics per cache for RHDG clients

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12166: ----------------------------------- Summary: Expose management metrics per cache for RHDG clients Key: WFLY-12166 URL: https://issues.jboss.org/browse/WFLY-12166 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 17.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro As of Infinispan 9.4.0, the HotRod client exposes statistics. When enabled (i.e. statistics-enabled=true), we should register a runtime resource per remote cache that exposes the statistics gathered by https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... as well as a runtime operation to reset the statistics. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12165) Expose management metrics for HotRod caches

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12165: ----------------------------------- Summary: Expose management metrics for HotRod caches Key: WFLY-12165 URL: https://issues.jboss.org/browse/WFLY-12165 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 17.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro As of Infinispan 9.4.0, the HotRod client exposes statistics. When enabled (i.e. statistics-enabled=true), we should register a runtime resource per remote cache that exposes the statistics gathered by https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... as well as a runtime operation to reset the statistics. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-775) Identify uncovered areas

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-775?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-775: ----------------------------------------------- Those files need to removed from coverage tests/data/destination_rules_data.go tests/data/gateway_data.go tests/data/mesh_policy_data.go tests/data/policy_data.go tests/data/service_entry_data.go tests/data/service_role_data.go tests/data/virtual_service_data.go tests/data/workload_data.go kubernetes/kubetest/mock.go kubernetes/kiali_monitoring/mock/mock.go prometheus/prometheustest/mock.go > Identify uncovered areas > ------------------------ > > Key: SWSQE-775 > URL: https://issues.jboss.org/browse/SWSQE-775 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Priority: Major > > We have the code coverage report so we should be able to identify uncovered areas and create tasks to implement automation. > Also we need to check if all files in the report are expected (remove mock/test data files) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3625) [DMN Designer] Remove Stunners Explorer widget from the RHS dock

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3625?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-3625: ---------------------------------------- [~roger.martinez] Or I can simply pass the diagram type ({{DefinitionSet}} or something) and have {{StunnerDocksHandler}} lookup a _provider_ of dock definitions with CDI and the diagram type in the event... this sounds better decoupling. WDYT? > [DMN Designer] Remove Stunners Explorer widget from the RHS dock > ---------------------------------------------------------------- > > Key: DROOLS-3625 > URL: https://issues.jboss.org/browse/DROOLS-3625 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.17.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > > The DMN Editor has a "Decision Navigator" widget (in the LHS dock) that currently shows the content of the whole DRG however it will also become the DRD explorer too. This duplicates Stunner's _default_ Explorer widget in the RHS dock. > The DMN Editor should have Stunner's _default_ widget removed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11601) Weld vs Undertow bootstrap: Race condition

by Matěj Novotný (Jira)

[ https://issues.jboss.org/browse/WFLY-11601?page=com.atlassian.jira.plugin... ] Matěj Novotný edited comment on WFLY-11601 at 6/4/19 10:30 AM: --------------------------------------------------------------- The approach I outlined above turns out to be wrong. The {{WeldStartCompletionService}} itself relies on going last (after EE components and in cleanup phase) in order to perform cleanup and optimization for Weld. Trying to add that as a dependency of {{UndertowDeploymentService}} would then mean a circular dependency or at least a delay in undertow service start which is too big (both are bound to another phase anyway). I am pretty sure we don't want to back off the optimization as that reduces the runtime overhead and footprint of CDI-related components. But ATM I just don't know how to solve this on service-bootstrap level. The only thing that comes to mind is splitting the bootstrap even more - basically taking {{WeldStartup#endInitialization()}} and creating two methods, one that does all the remaining bootstrap work (building {{BeanIdentifierIndex}} plus processing {{BeanDeploymentModules}}) and then other that does all the clean ups plus fires initialized event. But that obviously breaks the code of all integrators (pretty much all EE servers out there). Another nasty hack [don't take me seriously on this one] would be to just extract the remaining boot logic into previous step (validation) and leave the end init to be purely cleaning up, but that's not nice and can again break integrators code. I'd like to hear what [~mkouba] has to say. was (Author: manovotn): The approach I outlined above turns out to be wrong. The {{WeldStartCompletionService}} itself relies on going last (after EE components and in cleanup phase) in order to perform cleanup and optimization for Weld. Trying to add that as a dependency of {{UndertowDeploymentService}} would then mean a circular dependency or at least a delay in undertow service start which is too big (both are bound to another phase anyway). I am pretty sure we don't want to back off the optimization as that reduces the runtime overhead and footprint of CDI-related components. But ATM I just don't know how to solve this on service-bootstrap level. The only thing that comes to mind is splitting the bootstrap even more - basically taking {{WeldStartup#endInitialization()}} and creating two methods, one that does all the remaining bootstrap work (building {{BeanIdentifierIndex}} plus processing {{BeanDeploymentModules}}) and then other that does all the clean ups plus fires initialized event. But that obviously breaks the code of all integrators (pretty much all EE servers out there). Another nasty hack would be to just extract the remaining boot logic into previous step (validation) and leave the end init to be purely cleaning up, but that's not nice and can again break integrators code. I'd like to hear what [~mkouba] has to say. > Weld vs Undertow bootstrap: Race condition > ------------------------------------------ > > Key: WFLY-11601 > URL: https://issues.jboss.org/browse/WFLY-11601 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Web (Undertow) > Affects Versions: 15.0.1.Final > Reporter: Stefan Gr > Assignee: Matěj Novotný > Priority: Major > Attachments: TestApp.zip, TestLib.zip, changes.diff, deploy-failed.txt, deploy-mixed-success.txt, deploy-success.txt, test-app-1.0.0.war, weld-core-impl-3.0.5.Final.jar, weld-core-impl-3.0.5.Final.jar > > > WFLY-9732 / WFLY-10784 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI. > You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...]. > In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers. > A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11601) Weld vs Undertow bootstrap: Race condition

by Matěj Novotný (Jira)

[ https://issues.jboss.org/browse/WFLY-11601?page=com.atlassian.jira.plugin... ] Matěj Novotný commented on WFLY-11601: -------------------------------------- The approach I outlined above turns out to be wrong. The {{WeldStartCompletionService}} itself relies on going last (after EE components and in cleanup phase) in order to perform cleanup and optimization for Weld. Trying to add that as a dependency of {{UndertowDeploymentService}} would then mean a circular dependency or at least a delay in undertow service start which is too big (both are bound to another phase anyway). I am pretty sure we don't want to back off the optimization as that reduces the runtime overhead and footprint of CDI-related components. But ATM I just don't know how to solve this on service-bootstrap level. The only thing that comes to mind is splitting the bootstrap even more - basically taking {{WeldStartup#endInitialization()}} and creating two methods, one that does all the remaining bootstrap work (building {{BeanIdentifierIndex}} plus processing {{BeanDeploymentModules}}) and then other that does all the clean ups plus fires initialized event. But that obviously breaks the code of all integrators (pretty much all EE servers out there). Another nasty hack would be to just extract the remaining boot logic into previous step (validation) and leave the end init to be purely cleaning up, but that's not nice and can again break integrators code. I'd like to hear what [~mkouba] has to say. > Weld vs Undertow bootstrap: Race condition > ------------------------------------------ > > Key: WFLY-11601 > URL: https://issues.jboss.org/browse/WFLY-11601 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Web (Undertow) > Affects Versions: 15.0.1.Final > Reporter: Stefan Gr > Assignee: Matěj Novotný > Priority: Major > Attachments: TestApp.zip, TestLib.zip, changes.diff, deploy-failed.txt, deploy-mixed-success.txt, deploy-success.txt, test-app-1.0.0.war, weld-core-impl-3.0.5.Final.jar, weld-core-impl-3.0.5.Final.jar > > > WFLY-9732 / WFLY-10784 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI. > You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...]. > In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers. > A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-776) Investegate Moving To MW AWS Accounts

by Matthew Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-776?page=com.atlassian.jira.plugin.... ] Matthew Mahoney commented on SWSQE-776: --------------------------------------- https://mojo.redhat.com/docs/DOC-117177 https://mojo.redhat.com/docs/DOC-82915 > Investegate Moving To MW AWS Accounts > ------------------------------------- > > Key: SWSQE-776 > URL: https://issues.jboss.org/browse/SWSQE-776 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matthew Mahoney > Assignee: Matthew Mahoney > Priority: Major > Labels: infrastructure > > Service Mesh QE will need to move away from using OS QE/DEV AWS accounts. > Thus, investigate what it takes to move to using MW AWS Accounts (aka: procure and learn what needs to be done to move the team to MW AWS account). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-776) Investegate Moving To MW AWS Accounts

by Matthew Mahoney (Jira)

Matthew Mahoney created SWSQE-776: ------------------------------------- Summary: Investegate Moving To MW AWS Accounts Key: SWSQE-776 URL: https://issues.jboss.org/browse/SWSQE-776 Project: Kiali QE Issue Type: QE Task Reporter: Matthew Mahoney Assignee: Matthew Mahoney Service Mesh QE will need to move away from using OS QE/DEV AWS accounts. Thus, investigate what it takes to move to using MW AWS Accounts (aka: procure and learn what needs to be done to move the team to MW AWS account). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4072) Search query is not empty but all data objects listed

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-4072?page=com.atlassian.jira.plugi... ] Yeser Amer updated DROOLS-4072: ------------------------------- Story Points: 3 > Search query is not empty but all data objects listed > ----------------------------------------------------- > > Key: DROOLS-4072 > URL: https://issues.jboss.org/browse/DROOLS-4072 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.23.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Attachments: search.webm > > > In the attached video is shown sequence of steps that shows search query is ignored. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4072) Search query is not empty but all data objects listed

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-4072?page=com.atlassian.jira.plugi... ] Yeser Amer updated DROOLS-4072: ------------------------------- Sprint: 2019 Week 23-25 > Search query is not empty but all data objects listed > ----------------------------------------------------- > > Key: DROOLS-4072 > URL: https://issues.jboss.org/browse/DROOLS-4072 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.23.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > Attachments: search.webm > > > In the attached video is shown sequence of steps that shows search query is ignored. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 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 June 2019