November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12831) Upgrade HAL to 3.2.4.Final

by Harald Pehl (Jira)

[ https://issues.jboss.org/browse/WFLY-12831?page=com.atlassian.jira.plugin... ] Harald Pehl updated WFLY-12831: ------------------------------- Description: Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.4.Final (was: Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.4.Final FYI: HAL 3.2.2.Final contained i18n issues and was skipped.) > Upgrade HAL to 3.2.4.Final > -------------------------- > > Key: WFLY-12831 > URL: https://issues.jboss.org/browse/WFLY-12831 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Major > Fix For: 19.0.0.Beta1 > > > Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.4.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12831) Upgrade HAL to 3.2.4.Final

by Harald Pehl (Jira)

[ https://issues.jboss.org/browse/WFLY-12831?page=com.atlassian.jira.plugin... ] Harald Pehl updated WFLY-12831: ------------------------------- Description: Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.4.Final FYI: HAL 3.2.2.Final contained i18n issues and was skipped. was: Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.3.Final FYI: HAL 3.2.2.Final contained i18n issues and was skipped. > Upgrade HAL to 3.2.4.Final > -------------------------- > > Key: WFLY-12831 > URL: https://issues.jboss.org/browse/WFLY-12831 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Major > Fix For: 19.0.0.Beta1 > > > Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.4.Final > FYI: HAL 3.2.2.Final contained i18n issues and was skipped. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12831) Upgrade HAL to 3.2.4.Final

by Harald Pehl (Jira)

[ https://issues.jboss.org/browse/WFLY-12831?page=com.atlassian.jira.plugin... ] Harald Pehl updated WFLY-12831: ------------------------------- Summary: Upgrade HAL to 3.2.4.Final (was: Upgrade HAL to 3.2.3.Final) > Upgrade HAL to 3.2.4.Final > -------------------------- > > Key: WFLY-12831 > URL: https://issues.jboss.org/browse/WFLY-12831 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Major > Fix For: 19.0.0.Beta1 > > > Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.3.Final > FYI: HAL 3.2.2.Final contained i18n issues and was skipped. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12826) Upgrade galleon to 4.2.1.Final, galleon-plugins to 4.2.2.Final

by Oleksiy Lubyanskyy (Jira)

[ https://issues.jboss.org/browse/WFLY-12826?page=com.atlassian.jira.plugin... ] Oleksiy Lubyanskyy reassigned WFLY-12826: ----------------------------------------- Assignee: Oleksiy Lubyanskyy (was: Jean Francois Denise) > Upgrade galleon to 4.2.1.Final, galleon-plugins to 4.2.2.Final > -------------------------------------------------------------- > > Key: WFLY-12826 > URL: https://issues.jboss.org/browse/WFLY-12826 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Jean Francois Denise > Assignee: Oleksiy Lubyanskyy > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12826) Upgrade galleon to 4.2.1.Final, galleon-plugins to 4.2.2.Final

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFLY-12826?page=com.atlassian.jira.plugin... ] Jean Francois Denise updated WFLY-12826: ---------------------------------------- Summary: Upgrade galleon to 4.2.1.Final, galleon-plugins to 4.2.2.Final (was: Upgrade galleon and galleon-plugins to 4.1.2.Final) > Upgrade galleon to 4.2.1.Final, galleon-plugins to 4.2.2.Final > -------------------------------------------------------------- > > Key: WFLY-12826 > URL: https://issues.jboss.org/browse/WFLY-12826 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12808) Upgrade Weld from 3.1.2.Final to 3.1.3.Final

by Matěj Novotný (Jira)

[ https://issues.jboss.org/browse/WFLY-12808?page=com.atlassian.jira.plugin... ] Matěj Novotný updated WFLY-12808: --------------------------------- Fix Version/s: 19.0.0.Beta1 > Upgrade Weld from 3.1.2.Final to 3.1.3.Final > -------------------------------------------- > > Key: WFLY-12808 > URL: https://issues.jboss.org/browse/WFLY-12808 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Affects Versions: 18.0.1.Final > Reporter: Chao Wang > Assignee: Matěj Novotný > Priority: Major > Labels: downstream_dependency > Fix For: 19.0.0.Beta1 > > > Upgrade Weld to 3.1.3.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12808) Upgrade Weld from 3.1.2.Final to 3.1.3.Final

by Matěj Novotný (Jira)

[ https://issues.jboss.org/browse/WFLY-12808?page=com.atlassian.jira.plugin... ] Matěj Novotný updated WFLY-12808: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/12830 > Upgrade Weld from 3.1.2.Final to 3.1.3.Final > -------------------------------------------- > > Key: WFLY-12808 > URL: https://issues.jboss.org/browse/WFLY-12808 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Affects Versions: 18.0.1.Final > Reporter: Chao Wang > Assignee: Matěj Novotný > Priority: Major > Labels: downstream_dependency > > Upgrade Weld to 3.1.3.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12808) Upgrade Weld from 3.1.2.Final to 3.1.3.Final

by Matěj Novotný (Jira)

[ https://issues.jboss.org/browse/WFLY-12808?page=com.atlassian.jira.plugin... ] Matěj Novotný commented on WFLY-12808: -------------------------------------- Weld release is out, notes are [here|http://weld.cdi-spec.org/news/2019/11/28/weld-313Final/] and I've files a PR with update against WFLY. > Upgrade Weld from 3.1.2.Final to 3.1.3.Final > -------------------------------------------- > > Key: WFLY-12808 > URL: https://issues.jboss.org/browse/WFLY-12808 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Affects Versions: 18.0.1.Final > Reporter: Chao Wang > Assignee: Matěj Novotný > Priority: Major > Labels: downstream_dependency > > Upgrade Weld to 3.1.3.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times

by Kabir Khan (Jira)

[ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFWIP-276: ---------------------------------- I have investigated very briefly how this could work. The hook is after the call to extensibleConfigurationPersister.load() here https://github.com/wildfly/wildfly-core/blob/11.0.0.Beta3/server/src/main... My initial idea was to look for a user specified file (in my play I used a system property to specify the file location) containing the CLI commands and to parse those and add those to the bootOps. However, this is too naive. The reason is that the CLI scripts make heavy use of CLI control flow, batching and things like that. So it seems to me that if we tell it to use 'additional' operations from a CLI file, we would need to add a hidden operation handler and add an operation to bootOps to invoke this operation. We would need to make sure this gets executed at the end of the MODEL stage. If it can be removed after boot that would be great (there is a call a few lines further down from what I pasted to registerModelControllerServiceInitializationBootStep() which sounds like it is doing something like that). The handler for this operation could then take specified CLI script(s) and use CLI running in some kind of mode where it calls the local ModelController directly rather than remotely. I don't know if we have what we need to do that already? If we do, I believe this would be able to adjust the configuration parsed from the standalone.xml config file with control flow and everything. > Boot time of application built via S2I is much longer than in before-Galleon times > ---------------------------------------------------------------------------------- > > Key: WFWIP-276 > URL: https://issues.jboss.org/browse/WFWIP-276 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Critical > Attachments: test-app.zip > > > As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. > This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): > ||17.0-6||pod time||EAP boot||config time > |#1 | 8283|6128|2155 > |#2 | 9446|7548|1898 > |#3 | 8767|6871| 1896 > |#4 | 8568|6272| 2296 > |#5 | 8000 |6362|1638 > ||average ||8613ms||6636ms||1977ms > ||18.0-7||pod time||EAP boot||config time > |#1 |13769|5716|8053 > |#2 |13362|5952|7410 > |#3 |14261|6093|8168 > |#4 |14322|6135|8187 > |#5 |13921|6326|7595 > ||average||13927ms||6044ms||7883ms > pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) > EAP boot = time of boot EAP itself == {{started in ..}} > config time = the difference of previou timess = anything before EAP boot begins > Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. > This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. > The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.... ] Jean Francois Denise commented on WFWIP-276: -------------------------------------------- A possible way to solve this performance issue would be to not start CLI JVM and embedded server. The running server would handle the configuration at boot time. This needs a deep analysis, but mainly the startup sequence would become: * /opt/eap/bin/openshift-launch.sh * Launch scripts generate CLI script in well known location (already the case). * Server starts, a hook (TBD) applies the CLI script (require CLI operation to ModelNode parsing). > Boot time of application built via S2I is much longer than in before-Galleon times > ---------------------------------------------------------------------------------- > > Key: WFWIP-276 > URL: https://issues.jboss.org/browse/WFWIP-276 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Critical > Attachments: test-app.zip > > > As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. > This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): > ||17.0-6||pod time||EAP boot||config time > |#1 | 8283|6128|2155 > |#2 | 9446|7548|1898 > |#3 | 8767|6871| 1896 > |#4 | 8568|6272| 2296 > |#5 | 8000 |6362|1638 > ||average ||8613ms||6636ms||1977ms > ||18.0-7||pod time||EAP boot||config time > |#1 |13769|5716|8053 > |#2 |13362|5952|7410 > |#3 |14261|6093|8168 > |#4 |14322|6135|8187 > |#5 |13921|6326|7595 > ||average||13927ms||6044ms||7883ms > pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) > EAP boot = time of boot EAP itself == {{started in ..}} > config time = the difference of previou timess = anything before EAP boot begins > Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. > This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. > The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2019