May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1975) Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the newOrder request

by Farah Juma (Jira)

Farah Juma created ELY-1975: ------------------------------- Summary: Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the newOrder request Key: ELY-1975 URL: https://issues.redhat.com/browse/ELY-1975 Project: WildFly Elytron Issue Type: Task Reporter: Farah Juma Assignee: Farah Juma {{AcmeClientSpi#obtainCertificate}} currently determines the order URL that should be used by taking the {{Location}} header from the response to finalizing the order (the ACME protocol specification has an example response that includes this header). This works when obtaining certificates from Let's Encrypt and Boulder. However, it seems that EJBCA does not include the {{Location}} header in the response to finalizing the order. {{AcmeClientSpi#obtainCertificate}} should instead attempt to use the Location header from the response to {{newOrder}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1975) Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the response to newOrder

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1975?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1975: ---------------------------- Summary: Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the response to newOrder (was: Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the newOrder request) > Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the response to newOrder > ----------------------------------------------------------------------------------------------------- > > Key: ELY-1975 > URL: https://issues.redhat.com/browse/ELY-1975 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > > {{AcmeClientSpi#obtainCertificate}} currently determines the order URL that should be used by taking the {{Location}} header from the response to finalizing the order (the ACME protocol specification has an example response that includes this header). This works when obtaining certificates from Let's Encrypt and Boulder. However, it seems that EJBCA does not include the {{Location}} header in the response to finalizing the order. {{AcmeClientSpi#obtainCertificate}} should instead attempt to use the Location header from the response to {{newOrder}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2470) JBDC_PING can face a split-brain issue when restarting a coordinator node

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/JGRP-2470?page=com.atlassian.jira.plugin... ] Radoslav Husar commented on JGRP-2470: -------------------------------------- bq. What's the rationale for reverting JGRP-2199? If the old coord removes all information, the new one will re-insert it (actually multiple times, if configured)... That's the problem – these are not synchronized in any way and thus it's racey. As Masafumi explained, the problem is that if these are ordered in the database in a way 1. the new coordinator reinserted the data and 2. then the stopping coordinators clear table query {{clearTable(String clustername)}} the restarted member won't discovery anything and start a singleton cluster. bq. It seems that a periodic findMembers() triggered by MERGE3 can heal the singleton clusters situation. The findMembers() can insert their own node information when the table is empty. But this happens after the interval calculated by Math.max(min_interval, Util.random(max_interval) + max_interval/2) where min_interval is 10000 and max_interval is 30000 in JBoss EAP by default. And, the actual merge happens after this. So, it could take a long time to heal the singleton clusters situation. We don't even need to go into details on merging partitions, discovery can never lead by design into this as this causes partitions and data loss. > JBDC_PING can face a split-brain issue when restarting a coordinator node > ------------------------------------------------------------------------- > > Key: JGRP-2470 > URL: https://issues.redhat.com/browse/JGRP-2470 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.9, 4.0.22 > Reporter: Masafumi Miura > Assignee: Radoslav Husar > Priority: Major > Fix For: 4.2.5 > > > After [the change|https://github.com/belaban/JGroups/commit/215cdb6] for JGRP-2199, JDBC_PING deletes all entries from the table during the shutdown of the coordinator node. > This behavior has a possibility to cause a split-brain when restarting a coordinator node. Because, as all entries are lost in the following scenario, the restarting node can not find any information about existing nodes from the table and does not form a cluster. > 0. node1 and node2 form a cluster. The node1 is a coordinator. > 1. Trigger a restart of the node1 > 2. The node1 removes their node information from the table > 3. The node2 becomes a new coordinator > 4. The node2 updates their node information in the table > 5. The node1 clears all entries from the table > 6. The node1 starts again > 7. The node1 does not join the existing cluster because there's no node information in the table > Note: If step 5 happens before step 4, the split-brain issue does not happen. However, as step 4 and step 5 happen on different nodes, these steps can happen in parallel. So, the order is undefined. So, for example, if the shutdown of node1 takes a long time, there's a high possibility to face this issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13514) Huge memory leak in WildFly

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFLY-13514?page=com.atlassian.jira.plugi... ] Flavia Rainone commented on WFLY-13514: --------------------------------------- This is probably related to https://github.com/undertow-io/undertow/commit/439001a0ca1fb4b0f44d63b06a... / UNDERTOW-1573. We do have a related discussion on this PR: https://github.com/undertow-io/undertow/pull/862 I'll try reverting the PR and and running the reproducer to validate if it is really the case. It is on my TODO list to investigate, as I mentioned in the PR above, a possible solution to this. Given it affects other scenarios such as JSF + CDI beans, I'll be investigating this next thing on my list. > Huge memory leak in WildFly > --------------------------- > > Key: WFLY-13514 > URL: https://issues.redhat.com/browse/WFLY-13514 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 18.0.1.Final, 19.1.0.Final, 20.0.0.Beta1 > Reporter: Konrad Bak > Assignee: Matěj Novotný > Priority: Critical > > https://github.com/konbk/bug-report-wildfly-oome > The project shows a huge memory leak introduced in recent WildFly versions that can crash a real-world Java EE application in a matter of hours. > When a JSF page contains any component bound to page variable, all CDI beans (regardless of scope) used on that page stay in memory. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13514) Huge memory leak in WildFly

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFLY-13514?page=com.atlassian.jira.plugi... ] Flavia Rainone reassigned WFLY-13514: ------------------------------------- Assignee: Flavia Rainone (was: Matěj Novotný) > Huge memory leak in WildFly > --------------------------- > > Key: WFLY-13514 > URL: https://issues.redhat.com/browse/WFLY-13514 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 18.0.1.Final, 19.1.0.Final, 20.0.0.Beta1 > Reporter: Konrad Bak > Assignee: Flavia Rainone > Priority: Critical > > https://github.com/konbk/bug-report-wildfly-oome > The project shows a huge memory leak introduced in recent WildFly versions that can crash a real-world Java EE application in a matter of hours. > When a JSF page contains any component bound to page variable, all CDI beans (regardless of scope) used on that page stay in memory. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13526) Upgrade WildFly Core 12.0.0.Beta4

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13526?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-13526: ------------------------------- Description: Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Beta4 Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta3...12.0.0.Beta4 was: Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Beta3 Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta2...12.0.0.Beta3 > Upgrade WildFly Core 12.0.0.Beta4 > --------------------------------- > > Key: WFLY-13526 > URL: https://issues.redhat.com/browse/WFLY-13526 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Major > Fix For: 20.0.0.Beta1 > > > Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Beta4 > Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta3...12.0.0.Beta4 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13526) Upgrade WildFly Core 12.0.0.Beta4

by Jeff Mesnil (Jira)

Jeff Mesnil created WFLY-13526: ---------------------------------- Summary: Upgrade WildFly Core 12.0.0.Beta4 Key: WFLY-13526 URL: https://issues.redhat.com/browse/WFLY-13526 Project: WildFly Issue Type: Component Upgrade Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 20.0.0.Beta1 Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Beta3 Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta2...12.0.0.Beta3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4973) NPE due to timeout in LongOutputTestCase

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4973?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4973: -------------------------------- Fix Version/s: 12.0.0.CR1 (was: 12.0.0.Beta4) > NPE due to timeout in LongOutputTestCase > ---------------------------------------- > > Key: WFCORE-4973 > URL: https://issues.redhat.com/browse/WFCORE-4973 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 12.0.0.CR1 > > > [ERROR] Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 50.287 s <<< FAILURE! - in org.jboss.as.test.integration.management.cli.LongOutputTestCase > [ERROR] testDisabledOutputPagingViaXml(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.961 s <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertNotNull(Assert.java:712) > at org.junit.Assert.assertNotNull(Assert.java:722) > at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394) > at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaXml(LongOutputTestCase.java:380) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) > [ERROR] testDisabledOutputPagingViaArgument(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.849 s <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertNotNull(Assert.java:712) > at org.junit.Assert.assertNotNull(Assert.java:722) > at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394) > at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaArgument(LongOutputTestCase.java:368) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4963) During Phase.CONFIGURE_MODULE populate SecurityMetaData with the name of any Virtual SecurityDomain

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4963?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4963: -------------------------------- Fix Version/s: 12.0.0.CR1 (was: 12.0.0.Beta4) > During Phase.CONFIGURE_MODULE populate SecurityMetaData with the name of any Virtual SecurityDomain > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-4963 > URL: https://issues.redhat.com/browse/WFCORE-4963 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 12.0.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

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

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4670?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4670: -------------------------------- Fix Version/s: 12.0.0.CR1 (was: 12.0.0.Beta4) > Upgrade JBoss MSC to 1.4.12.Final > --------------------------------- > > Key: WFCORE-4670 > URL: https://issues.redhat.com/browse/WFCORE-4670 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Katarina Hermanova > Assignee: Richard Opalka > Priority: Major > Fix For: 12.0.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 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 May 2020