December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9597?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9597: ---------------------------------------- Part of the reason I filed WFCORE-3441 is I wanted consideration of this kind thing before people started just blindly moving to a Supplier in order to make a deprecation warn go away. There are a number of intersecting factors to balance in all this. 1) If the parsers and marshallers are basically stateless objects, the class space for the Supplier is more than the cost of an object. 2) A PersistentResourceXMLParser implementation may or may not be stateless, depending on how it is coded. Some store the PersistentResourceXMLDescription in a static field (making the class itself somewhat heavy but an instance stateless), some in an instance field, and some calculate it on the fly. 3) For the current version of a parser, it's actually important to boot time that a PersistentResourceXMLDescription be created during Extension.initializeParsers and not deferred to when parsing happens. Extension.initializeParsers is done concurrently while parsing is single threaded, and creating the PersistentResourceXMLDescription ends up being the trigger that loads most of the extensions management model classes, creates AttributeDefinitions etc. Likely the most efficient way to do this with a PersistentResourceXMLParser is: {code} class FooExtension implements Extension { private volatile PersistentResourceXmlParser currentParserMarshaller; private PersistentResourceXmlParser getCurrentParserMarshaller() { PersistentResourceXmlParser result = currentParserMarshaller; if (result == null) { result = currentParserMarshaller = new FooParser3_0(); } return result; } public void initializeParsers(ExtensionParsingContext context) { .... register legacy parsers using the Supplier API context.setSubsystemXmlMapping("foo", FOO_3_URI, getCurrentParserMarshaller()); } public void initialize(ExtensionContext context) { .... do the other stuff subsystem.registerXMLElementWriter(getCurrentParserMarshaller()); } } {code} That's kind of fussy code, but oh well. > UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9597 > URL: https://issues.jboss.org/browse/WFLY-9597 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > > The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422c... > Most likely the same issue is in multiple places. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9597?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-9597: ------------------------------------ N.B. this likely affects other subsystems that make use of PersistentResourceXMLParser, and has a negative impact on WF's memory footprint. This becomes increasingly significant as a consequence of https://issues.jboss.org/browse/WFCORE-3441 > UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9597 > URL: https://issues.jboss.org/browse/WFLY-9597 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > > The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422c... > Most likely the same issue is in multiple places. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-9597: ------------------------------------ Summary: UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer Key: WFLY-9597 URL: https://issues.jboss.org/browse/WFLY-9597 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Radoslav Husar Assignee: Tomaz Cerar The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422c... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9597?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9597: --------------------------------- Description: The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422c... Most likely the same issue is in multiple places. was:The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422c... > UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9597 > URL: https://issues.jboss.org/browse/WFLY-9597 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > > The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422c... > Most likely the same issue is in multiple places. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8697) Address DeploymentUnitProcessor leaks in the codebase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8697?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8697: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1500297|https://bugzilla.redhat.com/show_bug.cgi?id=1500297] from POST to MODIFIED > Address DeploymentUnitProcessor leaks in the codebase > ----------------------------------------------------- > > Key: WFLY-8697 > URL: https://issues.jboss.org/browse/WFLY-8697 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Beta1 > > > In order to get singleton deployments fully working, we need to address the numerous {{org.jboss.as.server.deployment.DeploymentUnitProcessor#undeploy}} implementation leaks. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1300) Pem.parsePemX509Certificate() cannot parse files with non-PEM content

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1300?page=com.atlassian.jira.plugin.s... ] Jan Kalina reassigned ELY-1300: ------------------------------- Assignee: Martin Mazanek (was: Jan Kalina) > Pem.parsePemX509Certificate() cannot parse files with non-PEM content > --------------------------------------------------------------------- > > Key: ELY-1300 > URL: https://issues.jboss.org/browse/ELY-1300 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Martin Mazanek > > Add a test like this to `PemTest`: > {code} > @Test > public void testParsePemX509Certificate01() throws Exception { > URL url = PemTest.class.getResource("/ca/certs/01.pem"); > byte[] bytes = Files.readAllBytes(Paths.get(url.toURI())); > assertNotNull(Pem.parsePemX509Certificate(CodePointIterator.ofUtf8Bytes(bytes))); > } > {code} > Note that {{ca/certs/01.pem}} should start with non-PEM content > {code} > Certificate: > Data: > ... > {code} > followed by the PEM content: > {code} > -----BEGIN CERTIFICATE----- > {code} > Run the test > {code} > mvn clean test -Dtest=PemTest#testParsePemX509Certificate01 > {code} > Expected: Not quite sure if the parser should accept this. In any case, the following code works on Oracle/OpenJDK (while it does not on IBM JDK): > {code} > CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509"); > InputStream is = X509EvidenceVerificationSuiteChild.class.getResourceAsStream("/ca/certs/01.pem"); > Assert.assertNotNull((X509Certificate) certificateFactory.generateCertificate(is)); > {code} > Actual: > {code} > testParsePemX509Certificate01(org.wildfly.security.util.PemTest) Time elapsed: 0.116 sec <<< ERROR! > java.lang.IllegalArgumentException: ELY03010: Malformed PEM content at offset 1 > at org.wildfly.security.pem.Pem.parsePemContent(Pem.java:79) > at org.wildfly.security.pem.Pem.parsePemX509Certificate(Pem.java:272) > at org.wildfly.security.util.PemTest.testParsePemX509Certificate01(PemTest.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1300) Pem.parsePemX509Certificate() cannot parse files with non-PEM content

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1300?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1300: --------------------------------- [~dlofthouse] This could be good isolated starting point for new intern [~mmazanek] - he say he is be interested, would be ok to assing to him? > Pem.parsePemX509Certificate() cannot parse files with non-PEM content > --------------------------------------------------------------------- > > Key: ELY-1300 > URL: https://issues.jboss.org/browse/ELY-1300 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Jan Kalina > > Add a test like this to `PemTest`: > {code} > @Test > public void testParsePemX509Certificate01() throws Exception { > URL url = PemTest.class.getResource("/ca/certs/01.pem"); > byte[] bytes = Files.readAllBytes(Paths.get(url.toURI())); > assertNotNull(Pem.parsePemX509Certificate(CodePointIterator.ofUtf8Bytes(bytes))); > } > {code} > Note that {{ca/certs/01.pem}} should start with non-PEM content > {code} > Certificate: > Data: > ... > {code} > followed by the PEM content: > {code} > -----BEGIN CERTIFICATE----- > {code} > Run the test > {code} > mvn clean test -Dtest=PemTest#testParsePemX509Certificate01 > {code} > Expected: Not quite sure if the parser should accept this. In any case, the following code works on Oracle/OpenJDK (while it does not on IBM JDK): > {code} > CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509"); > InputStream is = X509EvidenceVerificationSuiteChild.class.getResourceAsStream("/ca/certs/01.pem"); > Assert.assertNotNull((X509Certificate) certificateFactory.generateCertificate(is)); > {code} > Actual: > {code} > testParsePemX509Certificate01(org.wildfly.security.util.PemTest) Time elapsed: 0.116 sec <<< ERROR! > java.lang.IllegalArgumentException: ELY03010: Malformed PEM content at offset 1 > at org.wildfly.security.pem.Pem.parsePemContent(Pem.java:79) > at org.wildfly.security.pem.Pem.parsePemX509Certificate(Pem.java:272) > at org.wildfly.security.util.PemTest.testParsePemX509Certificate01(PemTest.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2239) AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2239?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2239: --------------------------- Fix Version/s: 4.0.10 (was: 4.0.9) > AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE) > ------------------------------------------------------------------ > > Key: JGRP-2239 > URL: https://issues.jboss.org/browse/JGRP-2239 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.6 > Environment: Infinispan 9.1.1 + JGroups 4.0.6.Final + Vert.x 3.5.0 > Reporter: Boris Sh > Assignee: Bela Ban > Fix For: 4.0.10 > > > Hello, > I am using the following configuration: > {code:java} > <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> > <UDP /> > <PING /> > <MERGE3 /> > <FD /> > <VERIFY_SUSPECT /> > <ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128" > sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048" > asym_algorithm="RSA" /> > <pbcast.NAKACK2 /> > <UNICAST3 /> > <pbcast.STABLE /> > <FRAG2 /> > <AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth" > keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias" > cipher_type="RSA" /> > <pbcast.GMS /> > </config> > {code} > I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly. > Initially, when these nodes join the cluster, everything is fine. > The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs): > {code:java} > org.jgroups.protocols.FD up > WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK > WARNING: node-26978: unrecognized cipher; discarding message from node-27291 > org.jgroups.protocols.Encrypt handleEncryptedMessage > WARNING: node-26978: unrecognized cipher; discarding message from node-27291 > org.jgroups.protocols.Encrypt handleEncryptedMessage > WARNING: node-26978: unrecognized cipher; discarding message from node-36734 > org.jgroups.protocols.Encrypt handleEncryptedMessage > {code} > so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher". > In cluster coordinator logs I see the following: > {code:java} > INFO: ISPN100000: Node node-26978 joined the cluster > **** > WARN: node-27291: unrecognized cipher; discarding message from node-26978 > org.jgroups.logging.Slf4jLogImpl error > ERROR: key requester node-26978 is not in current view [***]; ignoring key request > org.jgroups.logging.Slf4jLogImpl warn > WARN: node-27291: unrecognized cipher; discarding message from node-26978 > INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734] > {code} > My understanding of what has happened: > For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens. > How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, as the key doesn't change. > Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use. > So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2232: --------------------------- Fix Version/s: 4.0.10 (was: 4.0.9) > Using NATIVE_S3_PING old members doesn't seem to get removed > ------------------------------------------------------------ > > Key: JGRP-2232 > URL: https://issues.jboss.org/browse/JGRP-2232 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.7 > Environment: Spring Boot / Boxfuse / AWS > Reporter: Jesper Blomquist > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.10 > > > According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us. > Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!). > Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age): > 967 elements: > i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old) > i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old) > i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old) > i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old) > i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old) > i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old) > i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old) > i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old) > i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old) > i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old) > i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old) > i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old) > ... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2228) ASYM_ENCRYPT: test with encrypt_entire_msg=true

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2228?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2228: --------------------------- Fix Version/s: 4.0.10 (was: 4.0.9) > ASYM_ENCRYPT: test with encrypt_entire_msg=true > ----------------------------------------------- > > Key: JGRP-2228 > URL: https://issues.jboss.org/browse/JGRP-2228 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.10 > > Attachments: asym-encrypt.xml, asym-encrypt.xml > > > * Start a few nodes with {{ASYM_ENCRYPT}} and {{encrypt_entire_msg}} set to {{true}} > * Kill and restart a member > * Apparently, restarting is not possible, as the new member won't be able to join the cluster > -> Verify this is true and - if yes - fix it -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 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 December 2017