September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-3948?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3948: ------------------------------------------ I fear making AttachmentList thread safe is something of a sweep-the-problem-under-the-rug approach, as the ConcurrentModificationException is telling us something useful -- we've got a reader executing concurrent with a writer. Presumably what the writer is doing is relevant, so preventing the reader going at the same time doesn't mean the readers see the full set of information. Any readers in a later Phase than writers should be fine; it's the readers in the same phase that are at risk of incorrect reads. The subdeployments execute their DUPs for a phase concurrently. So Scott's point re "Could it help to get the "topLevelDeployment.addToAttachmentList(Attachments.ADDITIONAL_MODULES, module)" call to happen before the subdeployers are called?" is on target. > Potential race condition on deployment of EAR when Class-Path manifest entry is in use > -------------------------------------------------------------------------------------- > > Key: WFCORE-3948 > URL: https://issues.jboss.org/browse/WFCORE-3948 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Stuart Douglas > Priority: Major > > Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-958) Public Nightly Kiali - Fix Build/Deploy

by Matthew Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-958?page=com.atlassian.jira.plugin.... ] Matthew Mahoney resolved SWSQE-958. ----------------------------------- Resolution: Done > Public Nightly Kiali - Fix Build/Deploy > --------------------------------------- > > Key: SWSQE-958 > URL: https://issues.jboss.org/browse/SWSQE-958 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matthew Mahoney > Assignee: Matthew Mahoney > Priority: Minor > Labels: infrastructure > > Need to build kiali, and then bounce the Kiali pod -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4678) Use a more recent version of guava

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4678?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-4678: ---------------------------------------- Assignee: (was: Brian Stansberry) I took a shot at this (see https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO...) but the elytron module transformer tests fail (and perhaps others would too.) Not worth more effort right now to sort it. > Use a more recent version of guava > ---------------------------------- > > Key: WFCORE-4678 > URL: https://issues.jboss.org/browse/WFCORE-4678 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Management, Test Suite > Reporter: Brian Stansberry > Priority: Minor > > The model-test framework uses maven-resolver-provider which transitively pulls in a quite old version of guava, which: > 1) Is different from what full uses (although it's just a testsuite dep in core, so not a big deal) > 2) Gets flagged by vulnerability scanners, which is annoying for a test dep. > So see if managing this version in dependencyManagement to the same version used in full works. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4670) Upgrade JBoss MSC to 1.4.12.Final

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4670?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-4670: ------------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 10.0.0.Beta9) > Upgrade JBoss MSC to 1.4.12.Final > --------------------------------- > > Key: WFCORE-4670 > URL: https://issues.jboss.org/browse/WFCORE-4670 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Katarina Hermanova > Assignee: Richard Opalka > Priority: Major > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4071) (7.1.z) Upgrade wildfly-client-config from 1.0.0 to 1.0.1

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4071?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-4071. -------------------------------------- Fix Version/s: 6.0.0.Final (was: 1.0.1.Final) Resolution: Done This was done via https://github.com/wildfly/wildfly-core/commit/4329283562c751ba5ebfecacdf... which I'm guessing was in 6.0.0.Final. Some 6.0 version for sure. > (7.1.z) Upgrade wildfly-client-config from 1.0.0 to 1.0.1 > --------------------------------------------------------- > > Key: WFCORE-4071 > URL: https://issues.jboss.org/browse/WFCORE-4071 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Affects Versions: 1.0.0.Final > Reporter: Ingo Weiss > Assignee: Vladimir Dosoudil > Priority: Major > Fix For: 6.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3906) Upgrade JBoss Modules to 1.8.6.Final

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-3906?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-3906. -------------------------------------- Resolution: Out of Date Core is on 1.9.1 > Upgrade JBoss Modules to 1.8.6.Final > ------------------------------------ > > Key: WFCORE-3906 > URL: https://issues.jboss.org/browse/WFCORE-3906 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Modules > Reporter: David Lloyd > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4678) Use a more recent version of guava

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4678: ---------------------------------------- Summary: Use a more recent version of guava Key: WFCORE-4678 URL: https://issues.jboss.org/browse/WFCORE-4678 Project: WildFly Core Issue Type: Component Upgrade Components: Management, Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry The model-test framework uses maven-resolver-provider which transitively pulls in a quite old version of guava, which: 1) Is different from what full uses (although it's just a testsuite dep in core, so not a big deal) 2) Gets flagged by vulnerability scanners, which is annoying for a test dep. So see if managing this version in dependencyManagement to the same version used in full works. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4678) Use a more recent version of guava

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4678?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-4678: ------------------------------------- Priority: Minor (was: Major) > Use a more recent version of guava > ---------------------------------- > > Key: WFCORE-4678 > URL: https://issues.jboss.org/browse/WFCORE-4678 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Management, Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > The model-test framework uses maven-resolver-provider which transitively pulls in a quite old version of guava, which: > 1) Is different from what full uses (although it's just a testsuite dep in core, so not a big deal) > 2) Gets flagged by vulnerability scanners, which is annoying for a test dep. > So see if managing this version in dependencyManagement to the same version used in full works. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4513) s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails

by Filippe Spolti (Jira)

[ https://issues.jboss.org/browse/DROOLS-4513?page=com.atlassian.jira.plugi... ] Filippe Spolti commented on DROOLS-4513: ---------------------------------------- [~hiroko] thanks for the detailed info. I made some changes on the xsd and a throw instruction was added, that way we can: - have the listeners in any order. - if the validation fails for some reason, the reason will be printed, like this example: {code:java} XSD validation failed against the new schema (cvc-elt.1.a: Cannot find the declaration of element 'kmodule'.) and against the old schema (cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://jboss.org/kie/6.0.0/kmodule":listeners}'. One of '{"http://jboss.org/kie/6.0.0/kmodule":ksession}' is expected.). {code} > s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails > ------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-4513 > URL: https://issues.jboss.org/browse/DROOLS-4513 > Project: Drools > Issue Type: Bug > Components: build, kie server > Affects Versions: 7.14.0.Final, 7.18.0.Final, 7.24.0.Final > Environment: OpenShift 3.11 with rhdm72-prod-immutable-kieserver.yaml/rhdm73-prod-immutable-kieserver.yaml > Reporter: Hiroko Miura > Assignee: Filippe Spolti > Priority: Major > Labels: support > Attachments: ruleTest.zip > > > If multiple ksession are defined in kmodule.xml and Event Lister is set more than one ksession, s2i build fails at KieServerContainerVerifier with the following error. > {noformat} > [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT > java.lang.RuntimeException: Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT > at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186) > at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:172) > at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:65) > at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:53) > at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:40) > at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:119) > at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:101) > at org.jboss.modules.Module.run(Module.java:352) > at org.jboss.modules.Module.run(Module.java:320) > at org.jboss.modules.Main.main(Main.java:593) > [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - com.redhat.gss:ruleTest:1.0.0-SNAPSHOT not verified. > ERROR Aborting due to error code 1 from kie server container verification > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AG-69) Pool-less mode

by Luis Barreiro (Jira)

[ https://issues.jboss.org/browse/AG-69?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-69. ----------------------------- Fix Version/s: 1.6 Resolution: Done This feature is implemented in two ways: * A new setting {{flushOnClose}} that forces connections to be flush as they are returned to the pool * An alternative {{AgroalDataSoure}} implementation, {{AGROAL_POOLLESS}}. This allows for a number of optimizations as connections are never really in the pool. > Pool-less mode > -------------- > > Key: AG-69 > URL: https://issues.jboss.org/browse/AG-69 > Project: Agroal > Issue Type: Feature Request > Components: pool > Reporter: Jesper Pedersen > Assignee: Luis Barreiro > Priority: Major > Fix For: 1.6 > > > In scenarios where multiple pools access the same data source instance you may end up in a situation where the combined number of max-pool-size is greater than the maximum number of connections in the data source. > Introduce a pool-less mode, where the underlying connection is closed upon return to the pool if the pool size is greater than min-pool-size. > This will allow you to configure Agroal to > {{.mode("pool-less").minSize(0).maxSize(1)}} > that only use 1 connection that is returned upon close. This is especially useful for service-mesh scenarios where each service is short-lived, and process one transaction. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 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 September 2019