November 2019 - jboss-jira - Jboss List Archives

[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)

5 years, 1 month

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)

5 years, 1 month

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)

5 years, 1 month

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)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-1019) Review maistra installation job

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1019: ------------------------------------ Summary: Review maistra installation job Key: SWSQE-1019 URL: https://issues.jboss.org/browse/SWSQE-1019 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta We need to use correct deployment template based on version for both downstream and upstream builds. This is partially done by https://issues.jboss.org/browse/SWSQE-1017 Also we might want to consider not using those templates at all for downstream builds and always use OLM. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-1017) We need to update deployment templates for operators

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-1017?page=com.atlassian.jira.plugin... ] Filip Brychta resolved SWSQE-1017. ---------------------------------- Resolution: Done https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/commit/... > We need to update deployment templates for operators > ---------------------------------------------------- > > Key: SWSQE-1017 > URL: https://issues.jboss.org/browse/SWSQE-1017 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Blocker > Labels: infrastructure > > https://github.com/kiali/kiali/issues/1987 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4738) Avoid double SessionContext init call during startup

by Massimiliano Dessi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4738?page=com.atlassian.jira.plugi... ] Massimiliano Dessi resolved DROOLS-4738. ---------------------------------------- Resolution: Out of Date Fixed in others PRs > Avoid double SessionContext init call during startup > ---------------------------------------------------- > > Key: DROOLS-4738 > URL: https://issues.jboss.org/browse/DROOLS-4738 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > Labels: HADrools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3975) Increase size of donut chart in Test Scenario coverage report

by Daniele Zonca (Jira)

[ https://issues.jboss.org/browse/DROOLS-3975?page=com.atlassian.jira.plugi... ] Daniele Zonca closed DROOLS-3975. --------------------------------- Resolution: Done > Increase size of donut chart in Test Scenario coverage report > ------------------------------------------------------------- > > Key: DROOLS-3975 > URL: https://issues.jboss.org/browse/DROOLS-3975 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Minor > Labels: ScenarioSimulation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-1018) Molecule Tests don't run on Jenkins Slaves

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-1018?page=com.atlassian.jira.plugin... ] Filip Brychta commented on SWSQE-1018: -------------------------------------- Prepared VM jenkins slave. Please try to run tests, it's configured to use that slave. > Molecule Tests don't run on Jenkins Slaves > ------------------------------------------ > > Key: SWSQE-1018 > URL: https://issues.jboss.org/browse/SWSQE-1018 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Filip Brychta > Priority: Major > Attachments: olm.log > > > Running a simple > {code:bash} > molecule test -s olm-test > {code} > inside kiali/operator/ folder doesn't work on Jenkins slaves. > Before updating from Ansible 2.8 to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... > After updating to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2421) Don't log an IllegalArgumentException when receiving an invalid delta view

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2421?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2421: --------------------------- Fix Version/s: 4.1.9 > Don't log an IllegalArgumentException when receiving an invalid delta view > -------------------------------------------------------------------------- > > Key: JGRP-2421 > URL: https://issues.jboss.org/browse/JGRP-2421 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.6 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.9 > > > When the cluster is unstable but not because of the network (e.g. excessive load and long GC pauses), a suspected node can keep receiving view updates long after it was excluded from the view. > The first view triggers a warning about not being a member, but because later delta-views cannot be reconstructed, their warnings look much worse, even though they're about the same thing. > {noformat} > 11:31:05,281 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-79,edg-perf03-47882) edg-perf03-47882: not member of view [edg-perf01-21541|6]; discarding it > 11:31:16,267 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-80,edg-perf03-47882) edg-perf03-47882: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([edg-perf01-21541|6]) doesn't match the current view-id ([edg-perf01-21541|5]); discarding delta view [edg-perf01-21541|7], ref-view=[edg-perf01-21541|6], left=[edg-perf06-47720] > {noformat} > Maybe GMS could keep track of when it receives a view in which it is not a member and stop processing delta views from that node? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

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