April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4437) Deprecate RuntimeCapability.fromBaseCapability(String) and buildDynamicCapabilityName(String, String)

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFCORE-4437?page=com.atlassian.jira.plugi... ] Paul Ferraro reassigned WFCORE-4437: ------------------------------------ Assignee: Jeff Mesnil (was: Paul Ferraro) > Deprecate RuntimeCapability.fromBaseCapability(String) and buildDynamicCapabilityName(String, String) > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-4437 > URL: https://issues.jboss.org/browse/WFCORE-4437 > Project: WildFly Core > Issue Type: Task > Components: Management > Affects Versions: 9.0.0.Beta3 > Reporter: Paul Ferraro > Assignee: Jeff Mesnil > Priority: Major > > These methods predate the dynamic capability name mapping functionality and should be phased out. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3185: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2935, https://github.com/wildfly/wildfly-core/pull/3753 (was: https://github.com/wildfly/wildfly-core/pull/2935) > Run parallel boot tasks in coarser grained chunks > ------------------------------------------------- > > Key: WFCORE-3185 > URL: https://issues.jboss.org/browse/WFCORE-3185 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete. > The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working. > My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.) > The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem. > Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results. > -Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.- > Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software. > > _In particular, with a default thread stack size of 1024K, allocating an extra 50+ threads at boot means the process will consume an extra 50MB of RSS beyond what it would otherwise need. That memory should eventually be returned to the OS, and it's possible that later use of the server will result in a peak memory use after boot that's higher than what's needed at boot, but still, in a memory constrained environment (think cloud with applications trying to live in a smaller memory budget), requesting an extra 50MB beyond what provides benefit is not immaterial._ -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ] James Perkins reopened WFCORE-3185: ----------------------------------- > Run parallel boot tasks in coarser grained chunks > ------------------------------------------------- > > Key: WFCORE-3185 > URL: https://issues.jboss.org/browse/WFCORE-3185 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete. > The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working. > My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.) > The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem. > Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results. > -Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.- > Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software. > > _In particular, with a default thread stack size of 1024K, allocating an extra 50+ threads at boot means the process will consume an extra 50MB of RSS beyond what it would otherwise need. That memory should eventually be returned to the OS, and it's possible that later use of the server will result in a peak memory use after boot that's higher than what's needed at boot, but still, in a memory constrained environment (think cloud with applications trying to live in a smaller memory budget), requesting an extra 50MB beyond what provides benefit is not immaterial._ -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3185: ---------------------------------- Fix Version/s: (was: 9.0.0.Beta3) > Run parallel boot tasks in coarser grained chunks > ------------------------------------------------- > > Key: WFCORE-3185 > URL: https://issues.jboss.org/browse/WFCORE-3185 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > Currently parallel boot works by executing one task per Extension.initializeParsers call, one per Extension.initialize call and 2 per subsystem, one for execution of Stage.MODEL ops and one for Stage.RUNTIME ops. The Extension.initializeParsers tasks complete before boot proceeds to the point where any Extension.initialize tasks run, and the Extension.initialize tasks complete before the Stage.MODEL tasks run. The Stage.MODEL tasks do the large bulk of their work before the Stage.RUNTIME tasks run, but they do block waiting for the Stage.RUNTIME tasks and the rest of the boot to complete. > The rough effect of all this is we are allocating 2 threads per subsystem to do parallel boot, and at various points we have 1 thread per subsystem concurrently working. For a brief period (doing Stage.DONE of the post-extension boot op) we have 2 threads per subsystem concurrently working. > My measurements show that all of this concurrent work reduces boot time about 400ms on my machine, using the full WildFly standalone-full.xml config. However, this approach uses a lot of threads. So the task here is to look into how to get the same or better boot speed while using fewer threads. (Note the threads will expire and be gc'd after boot.) > The obvious way to do this is to look at each of the 4 task types discussed in the first paragraph and group things into larger units of work than a single extension/subsystem. > Initial work on doing this shows that using more coarse grained chunks does not result in reduced boot time, but also seems not to increase boot time. Further measurement is needed to confirm this though, and small tweaks may show different results. > -Another thing to consider is allowing the Stage.MODEL tasks to complete without waiting for the overall boot op to complete. This might reduce the max number of threads involved and perhaps will allow a tiny bit more parallelization of work. The key here is ensuring the Stage.MODEL tasks are not able to affect the state of the final system in an invalid way. That could be problematic or fragile, so it's just something to consider, and if done must be done with great care.- > Even if this work produces no reduction in boot time, if it produces no increase there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software. > > _In particular, with a default thread stack size of 1024K, allocating an extra 50+ threads at boot means the process will consume an extra 50MB of RSS beyond what it would otherwise need. That memory should eventually be returned to the OS, and it's possible that later use of the server will result in a peak memory use after boot that's higher than what's needed at boot, but still, in a memory constrained environment (think cloud with applications trying to live in a smaller memory budget), requesting an extra 50MB beyond what provides benefit is not immaterial._ -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3720) [DMN Designer] Included Models - Set the data types count in the IncludedModel entity

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-3720?page=com.atlassian.jira.plugi... ] Guilherme Gomes updated DROOLS-3720: ------------------------------------ Sprint: 2019 Week 17-19 > [DMN Designer] Included Models - Set the data types count in the IncludedModel entity > ------------------------------------------------------------------------------------- > > Key: DROOLS-3720 > URL: https://issues.jboss.org/browse/DROOLS-3720 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > When a model is imported, set the data types count in the {{IncludedModel}} entity. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3721) [DMN Designer] Included Models - Set the DRG elements count in the IncludedModel entity

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-3721?page=com.atlassian.jira.plugi... ] Guilherme Gomes updated DROOLS-3721: ------------------------------------ Sprint: 2019 Week 17-19 > [DMN Designer] Included Models - Set the DRG elements count in the IncludedModel entity > --------------------------------------------------------------------------------------- > > Key: DROOLS-3721 > URL: https://issues.jboss.org/browse/DROOLS-3721 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > When a model is imported, set the DRG elements count in the {{IncludedModel}} entity. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3892) [DMN Designer] Data Types tab - Add a nested row to a new Structured data type by default

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-3892?page=com.atlassian.jira.plugi... ] Guilherme Gomes updated DROOLS-3892: ------------------------------------ Summary: [DMN Designer] Data Types tab - Add a nested row to a new Structured data type by default (was: DMN (DEV): Add a nested row to a new Structured data type by default) > [DMN Designer] Data Types tab - Add a nested row to a new Structured data type by default > ----------------------------------------------------------------------------------------- > > Key: DROOLS-3892 > URL: https://issues.jboss.org/browse/DROOLS-3892 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screen Shot 2019-04-03 at 4.15.11 PM.png > > > Usability enhancement request: Reduce the number of clicks / actions to add a nested element. > Solution description: > When the user creates a data type, of the type "Structured" a child row will get added to the list automatically. The child row will be in Edit mode by default. Design demo to illustrate. https://redhat.invisionapp.com/share/FERHG55ZAPH -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3892) DMN (DEV): Add a nested row to a new Structured data type by default

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-3892?page=com.atlassian.jira.plugi... ] Guilherme Gomes updated DROOLS-3892: ------------------------------------ Story Points: 3 > DMN (DEV): Add a nested row to a new Structured data type by default > -------------------------------------------------------------------- > > Key: DROOLS-3892 > URL: https://issues.jboss.org/browse/DROOLS-3892 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screen Shot 2019-04-03 at 4.15.11 PM.png > > > Usability enhancement request: Reduce the number of clicks / actions to add a nested element. > Solution description: > When the user creates a data type, of the type "Structured" a child row will get added to the list automatically. The child row will be in Edit mode by default. Design demo to illustrate. https://redhat.invisionapp.com/share/FERHG55ZAPH -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3934) [DMN Designer] Included Models - Boxed Expressions does not work for imported DRG Elements

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-3934?page=com.atlassian.jira.plugi... ] Guilherme Gomes updated DROOLS-3934: ------------------------------------ Issue Type: Bug (was: Task) > [DMN Designer] Included Models - Boxed Expressions does not work for imported DRG Elements > ------------------------------------------------------------------------------------------ > > Key: DROOLS-3934 > URL: https://issues.jboss.org/browse/DROOLS-3934 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > Currently, users are not able to see a boxed expression from an imported node. > The DMNMarshaller must fetch information about external boxed expressions, and users must be able to see those boxed expressions in the DMN editor. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3934) [DMN Designer] Included Models - Boxed Expressions does not work for imported DRG Elements

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-3934?page=com.atlassian.jira.plugi... ] Guilherme Gomes updated DROOLS-3934: ------------------------------------ Summary: [DMN Designer] Included Models - Boxed Expressions does not work for imported DRG Elements (was: [DMN Designer] Included Models - Boxed Expressions - Fetch information about imported Boxed Expressions in the DMNMarshaller) > [DMN Designer] Included Models - Boxed Expressions does not work for imported DRG Elements > ------------------------------------------------------------------------------------------ > > Key: DROOLS-3934 > URL: https://issues.jboss.org/browse/DROOLS-3934 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > Currently, users are not able to see a boxed expression from an imported node. > The DMNMarshaller must fetch information about external boxed expressions, and users must be able to see those boxed expressions in the DMN editor. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019