August 2017 - jboss-jira - Jboss List Archives

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3185: ------------------------------------------ https://github.com/wildfly/wildfly-core/compare/master...bstansberry:par-... shows the work on this. > 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: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha1 > > > 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. > The obvious way to do that 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 gain, there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

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

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3185: ---------------------------------------- Summary: 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: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 4.0.0.Alpha1 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. The obvious way to do that 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 gain, there is some value in incorporating it, as avoiding unnecessary thread creation improves the impression of the efficiency and good design of the software. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1082) Documentation is missing in elytron-1_0.xsd

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-1082?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev reassigned ELY-1082: ---------------------------------- Assignee: Ilia Vassilev > Documentation is missing in elytron-1_0.xsd > ------------------------------------------- > > Key: ELY-1082 > URL: https://issues.jboss.org/browse/ELY-1082 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta34 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Priority: Critical > > XSD file {{elytron-1_0.xsd}} [1] includes almost no documentation. If this XSD is included in server distribution (as {{docs/schema/elytron-1_0.xsd}}) then it affects user experience. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9229) Allow multiple CommandDispatcher instances per service

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9229?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-9229: ------------------------------- Summary: Allow multiple CommandDispatcher instances per service (was: Allow multiple CommandDispatcher senders per service, while restricting to 1 receiver per service per node) > Allow multiple CommandDispatcher instances per service > ------------------------------------------------------ > > Key: WFLY-9229 > URL: https://issues.jboss.org/browse/WFLY-9229 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 11.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2408) Description of Elytron oauth2-introspection resource is copy/pasted from jwt

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2408?page=com.atlassian.jira.plugi... ] Ilia Vassilev reassigned WFCORE-2408: ------------------------------------- Assignee: Ilia Vassilev > Description of Elytron oauth2-introspection resource is copy/pasted from jwt > ---------------------------------------------------------------------------- > > Key: WFCORE-2408 > URL: https://issues.jboss.org/browse/WFCORE-2408 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Labels: user_experience > > Description of {{oauth2-introspection}} resource from Elytron {{token-realm}} is copy/pasted from description of {{jwt}}. > It is similar as WFLY-7573, but its description (and also its linked fix) talks only about description of attributes. This Jira is related to description of whole resource which currently says: > "A token validator to be used in conjunction with a token-based realm that handles security tokens based on the JWT/JWS standard." -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3184) Unused controllingThread after PR #2694

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3184?page=com.atlassian.jira.plugi... ] Rostislav Svoboda updated WFCORE-3184: -------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2714 > Unused controllingThread after PR #2694 > --------------------------------------- > > Key: WFCORE-3184 > URL: https://issues.jboss.org/browse/WFCORE-3184 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 3.0.0.Beta31 > Reporter: Rostislav Svoboda > Assignee: Rostislav Svoboda > Priority: Trivial > > Unused controllingThread after PR #2694 - https://github.com/wildfly/wildfly-core/pull/2694 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2367) Misleading description of identity-realm

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2367?page=com.atlassian.jira.plugi... ] Ilia Vassilev reassigned WFCORE-2367: ------------------------------------- Assignee: Ilia Vassilev > Misleading description of identity-realm > ---------------------------------------- > > Key: WFCORE-2367 > URL: https://issues.jboss.org/browse/WFCORE-2367 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Tymel > Assignee: Ilia Vassilev > > There is a misleading description of {{identity-realm}} in DMR [1]. It says _"A security realm definition where identities are represented in the management model."_ whereas an XSD documentation says _"Realm definition for a realm which contains a single pre-defined identity."_. > In general, the XSD description looks clearer to me. Moreover, the {{identities}} word may be misleading since {{identity-realm}}'s purpose is to _"to store one identity, with one attribute and no credential"_ [3]. Thus I would suggest to also change the description of {{attribute-values}} from > _"The values associated with the identities attribute."_ to something like _"The values associated with the identity attributes."_ > Suggestions for improvement: > * Change description {{identity-realm}} according to XSD > * Change description of {{attribute-values}} attr (in both DMR and XSD) > * to consider: unify descriptions in XSD and DMR > [1] /subsystem=elytron/identity-realm=somerealm:read-resource-description > [2] https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... > [3] HipChats's WildFly Elytron chat room on Nov 21 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3184) Unused controllingThread after PR #2694

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFCORE-3184: ----------------------------------------- Summary: Unused controllingThread after PR #2694 Key: WFCORE-3184 URL: https://issues.jboss.org/browse/WFCORE-3184 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 3.0.0.Beta31 Reporter: Rostislav Svoboda Assignee: Rostislav Svoboda Priority: Trivial Unused controllingThread after PR #2694 - https://github.com/wildfly/wildfly-core/pull/2694 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9229) Allow multiple CommandDispatcher senders per service, while restricting to 1 receiver per service per node

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-9229: ---------------------------------- Summary: Allow multiple CommandDispatcher senders per service, while restricting to 1 receiver per service per node Key: WFLY-9229 URL: https://issues.jboss.org/browse/WFLY-9229 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 11.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8207) Upgrade JGroups to 4.0

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8207?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-8207: ------------------------------------ [~sannegrinovero] Thanks for pointing that out. > Upgrade JGroups to 4.0 > ---------------------- > > Key: WFLY-8207 > URL: https://issues.jboss.org/browse/WFLY-8207 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Fix For: 12.0.0.Alpha1 > > > Final of 4.0 just out: > http://belaban.blogspot.cz/2017/02/jgroups-400final.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 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 August 2017