[JBoss JIRA] (JGRP-2400) FRAG4: cache marshalled output with FragmentedMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2400?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2400:
--------------------------------
Premarshalling an object is conceptually similar to what the previous fragmentation protocols (\{{FRAG2}}, {{FRAG3}}) do, and causes unneeded/unwanted eager marshalling and memory allocation.
Serializing an object into PartialOutputStream, and the latter discarding the serialized bytes which don't fit into a range, is cheap.
> FRAG4: cache marshalled output with FragmentedMessage
> -----------------------------------------------------
>
> Key: JGRP-2400
> URL: https://issues.redhat.com/browse/JGRP-2400
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> FRAG4 marshals a long message (that has *no array*) into smaller fragments, e.g. when frag_size==200, a 500 byte message is marshalled into 3 FragmentedMessages of sizes 200, 200 and 100.
> The first FragmentedMessage marshals the entire original message, but only writes the first 200 bytes to the output stream.
> The second FragmentedMessage also marshals the entire original message, and writes the second 200 bytes.
> The third message writes only the last 100 bytes.
> This means that the original message is marshalled 3 times.
> It might be faster to create an object that wraps the original message *and* a byte array, which represents the marshalled object. When marshalled for the first time, the byte array is created. The second and third time, no marshalling is performed, but instead, the FragmentedMessages access the byte array directly (at the given offsets/lengths).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (JGRP-2400) FRAG4: cache marshalled output with FragmentedMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2400?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2400.
----------------------------
Resolution: Won't Fix
See last comment
> FRAG4: cache marshalled output with FragmentedMessage
> -----------------------------------------------------
>
> Key: JGRP-2400
> URL: https://issues.redhat.com/browse/JGRP-2400
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> FRAG4 marshals a long message (that has *no array*) into smaller fragments, e.g. when frag_size==200, a 500 byte message is marshalled into 3 FragmentedMessages of sizes 200, 200 and 100.
> The first FragmentedMessage marshals the entire original message, but only writes the first 200 bytes to the output stream.
> The second FragmentedMessage also marshals the entire original message, and writes the second 200 bytes.
> The third message writes only the last 100 bytes.
> This means that the original message is marshalled 3 times.
> It might be faster to create an object that wraps the original message *and* a byte array, which represents the marshalled object. When marshalled for the first time, the byte array is created. The second and third time, no marshalling is performed, but instead, the FragmentedMessages access the byte array directly (at the given offsets/lengths).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFWIP-344) Bootable JAR - SSL 8443 port doesn't work by default
by Marek Kopecky (Jira)
[ https://issues.redhat.com/browse/WFWIP-344?page=com.atlassian.jira.plugin... ]
Marek Kopecky updated WFWIP-344:
--------------------------------
Attachment: ssl-war.war
> Bootable JAR - SSL 8443 port doesn't work by default
> ----------------------------------------------------
>
> Key: WFWIP-344
> URL: https://issues.redhat.com/browse/WFWIP-344
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Kabir Khan
> Priority: Blocker
> Attachments: ssl-war.war
>
>
> RFE jira: EAP7-1385
> SSL 8443 port doesn't work by default on bootable jar
> *Steps to reproduce:*
> * start bootable jar (hollow jar) with jaxrs-server, microprofile-config, datasources, h2-default-datasource layers (you can check the same on WF)
> * deploy deployment with this simple deployment:
> {code:java}
> @Path("/ssl")
> public class SslResource {
> @Path("/hello")
> @GET
> public String hello() {
> return "Hello World!";
> }
> }
> {code}
> * Make HTTP call by this client (use [this client.truststore|https://github.com/resteasy/Resteasy/blob/3.12/testsuit...]):
> {code:java}
> truststore = KeyStore.getInstance("jks");
> try (InputStream in = new FileInputStream("/home/path/client.truststore")) {
> truststore.load(in, "123456".toCharArray());
> }
> resteasyClientBuilder = (ResteasyClientBuilder) ClientBuilder.newBuilder();
> resteasyClientBuilder.setIsTrustSelfSignedCertificates(false);
> resteasyClientBuilder = resteasyClientBuilder.disableTrustManager();
> client = resteasyClientBuilder.trustStore(truststore).build();
> Response response = client.target("https://127.0.0.1:8443/ssl-war/ssl/hello").request().get();
> System.out.println("Response status: " + response.getStatus() + " (expected is 200)");
> if (response.getStatus() == 200) {
> System.out.println("Output: " + response.readEntity(String.class));
> }
> {code}
> * See the results:
> ** "Connection refused (Connection refused)" on bootable jar
> ** 200 response code on WF
> cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFWIP-344) Bootable JAR - SSL 8443 port doesn't work by default
by Marek Kopecky (Jira)
[ https://issues.redhat.com/browse/WFWIP-344?page=com.atlassian.jira.plugin... ]
Marek Kopecky updated WFWIP-344:
--------------------------------
Description:
RFE jira: EAP7-1385
SSL 8443 port doesn't work by default on bootable jar
*Steps to reproduce:*
* start bootable jar (hollow jar) with jaxrs-server, microprofile-config, datasources, h2-default-datasource layers (you can check the same on WF)
* deploy deployment with this simple deployment ([^ssl-war.war]):
{code:java}
@Path("/ssl")
public class SslResource {
@Path("/hello")
@GET
public String hello() {
return "Hello World!";
}
}
{code}
* Make HTTP call by this client (use [this client.truststore|https://github.com/resteasy/Resteasy/blob/3.12/testsuit...]):
{code:java}
truststore = KeyStore.getInstance("jks");
try (InputStream in = new FileInputStream("/home/path/client.truststore")) {
truststore.load(in, "123456".toCharArray());
}
resteasyClientBuilder = (ResteasyClientBuilder) ClientBuilder.newBuilder();
resteasyClientBuilder.setIsTrustSelfSignedCertificates(false);
resteasyClientBuilder = resteasyClientBuilder.disableTrustManager();
client = resteasyClientBuilder.trustStore(truststore).build();
Response response = client.target("https://127.0.0.1:8443/ssl-war/ssl/hello").request().get();
System.out.println("Response status: " + response.getStatus() + " (expected is 200)");
if (response.getStatus() == 200) {
System.out.println("Output: " + response.readEntity(String.class));
}
{code}
* See the results:
** "Connection refused (Connection refused)" on bootable jar
** 200 response code on WF
cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal]
was:
RFE jira: EAP7-1385
SSL 8443 port doesn't work by default on bootable jar
*Steps to reproduce:*
* start bootable jar (hollow jar) with jaxrs-server, microprofile-config, datasources, h2-default-datasource layers (you can check the same on WF)
* deploy deployment with this simple deployment:
{code:java}
@Path("/ssl")
public class SslResource {
@Path("/hello")
@GET
public String hello() {
return "Hello World!";
}
}
{code}
* Make HTTP call by this client (use [this client.truststore|https://github.com/resteasy/Resteasy/blob/3.12/testsuit...]):
{code:java}
truststore = KeyStore.getInstance("jks");
try (InputStream in = new FileInputStream("/home/path/client.truststore")) {
truststore.load(in, "123456".toCharArray());
}
resteasyClientBuilder = (ResteasyClientBuilder) ClientBuilder.newBuilder();
resteasyClientBuilder.setIsTrustSelfSignedCertificates(false);
resteasyClientBuilder = resteasyClientBuilder.disableTrustManager();
client = resteasyClientBuilder.trustStore(truststore).build();
Response response = client.target("https://127.0.0.1:8443/ssl-war/ssl/hello").request().get();
System.out.println("Response status: " + response.getStatus() + " (expected is 200)");
if (response.getStatus() == 200) {
System.out.println("Output: " + response.readEntity(String.class));
}
{code}
* See the results:
** "Connection refused (Connection refused)" on bootable jar
** 200 response code on WF
cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal]
> Bootable JAR - SSL 8443 port doesn't work by default
> ----------------------------------------------------
>
> Key: WFWIP-344
> URL: https://issues.redhat.com/browse/WFWIP-344
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Kabir Khan
> Priority: Blocker
> Attachments: ssl-war.war
>
>
> RFE jira: EAP7-1385
> SSL 8443 port doesn't work by default on bootable jar
> *Steps to reproduce:*
> * start bootable jar (hollow jar) with jaxrs-server, microprofile-config, datasources, h2-default-datasource layers (you can check the same on WF)
> * deploy deployment with this simple deployment ([^ssl-war.war]):
> {code:java}
> @Path("/ssl")
> public class SslResource {
> @Path("/hello")
> @GET
> public String hello() {
> return "Hello World!";
> }
> }
> {code}
> * Make HTTP call by this client (use [this client.truststore|https://github.com/resteasy/Resteasy/blob/3.12/testsuit...]):
> {code:java}
> truststore = KeyStore.getInstance("jks");
> try (InputStream in = new FileInputStream("/home/path/client.truststore")) {
> truststore.load(in, "123456".toCharArray());
> }
> resteasyClientBuilder = (ResteasyClientBuilder) ClientBuilder.newBuilder();
> resteasyClientBuilder.setIsTrustSelfSignedCertificates(false);
> resteasyClientBuilder = resteasyClientBuilder.disableTrustManager();
> client = resteasyClientBuilder.trustStore(truststore).build();
> Response response = client.target("https://127.0.0.1:8443/ssl-war/ssl/hello").request().get();
> System.out.println("Response status: " + response.getStatus() + " (expected is 200)");
> if (response.getStatus() == 200) {
> System.out.println("Output: " + response.readEntity(String.class));
> }
> {code}
> * See the results:
> ** "Connection refused (Connection refused)" on bootable jar
> ** 200 response code on WF
> cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFWIP-344) Bootable JAR - SSL 8443 port doesn't work by default
by Marek Kopecky (Jira)
Marek Kopecky created WFWIP-344:
-----------------------------------
Summary: Bootable JAR - SSL 8443 port doesn't work by default
Key: WFWIP-344
URL: https://issues.redhat.com/browse/WFWIP-344
Project: WildFly WIP
Issue Type: Bug
Reporter: Marek Kopecky
Assignee: Kabir Khan
Attachments: ssl-war.war
RFE jira: EAP7-1385
SSL 8443 port doesn't work by default on bootable jar
*Steps to reproduce:*
* start bootable jar (hollow jar) with jaxrs-server, microprofile-config, datasources, h2-default-datasource layers (you can check the same on WF)
* deploy deployment with this simple deployment:
{code:java}
@Path("/ssl")
public class SslResource {
@Path("/hello")
@GET
public String hello() {
return "Hello World!";
}
}
{code}
* Make HTTP call by this client (use [this client.truststore|https://github.com/resteasy/Resteasy/blob/3.12/testsuit...]):
{code:java}
truststore = KeyStore.getInstance("jks");
try (InputStream in = new FileInputStream("/home/path/client.truststore")) {
truststore.load(in, "123456".toCharArray());
}
resteasyClientBuilder = (ResteasyClientBuilder) ClientBuilder.newBuilder();
resteasyClientBuilder.setIsTrustSelfSignedCertificates(false);
resteasyClientBuilder = resteasyClientBuilder.disableTrustManager();
client = resteasyClientBuilder.trustStore(truststore).build();
Response response = client.target("https://127.0.0.1:8443/ssl-war/ssl/hello").request().get();
System.out.println("Response status: " + response.getStatus() + " (expected is 200)");
if (response.getStatus() == 200) {
System.out.println("Output: " + response.readEntity(String.class));
}
{code}
* See the results:
** "Connection refused (Connection refused)" on bootable jar
** 200 response code on WF
cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFWIP-342) Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response
by Marek Kopecky (Jira)
[ https://issues.redhat.com/browse/WFWIP-342?page=com.atlassian.jira.plugin... ]
Marek Kopecky updated WFWIP-342:
--------------------------------
Summary: Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response (was: RESTEasy JAXB end-point on bootable jar return unexpected 400 response)
> Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response
> ---------------------------------------------------------------------
>
> Key: WFWIP-342
> URL: https://issues.redhat.com/browse/WFWIP-342
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Jean Francois Denise
> Priority: Blocker
>
> RFE link: EAP7-1385
> RESTEasy JAXB end-point on bootable jar return unexpected 400 response with these security params:
> {code:xml}
> <context-param>
> <param-name>resteasy.document.secure.processing.feature</param-name>
> <param-value>true</param-value>
> </context-param>
> <context-param>
> <param-name>resteasy.document.secure.disableDTDs</param-name>
> <param-value>false</param-value>
> </context-param>
> <context-param>
> <param-name>resteasy.document.expand.entity.references</param-name>
> <param-value>false</param-value>
> </context-param>
> {code}
> Used layers:
> * jaxrs-server
> * microprofile-config
> Although this test is security related, AFAIK this is not related with legacy-security/elytron configuration, because related params are used in javax.xml.parsers.DocumentBuilderFactory directly from RESTEasy. Anyway let me know if I'm wrong.
> Steps to reproduce:
> # use installed WF version with reasonable layers, eg: WF_VERSION=21.0.0.Beta1-SNAPSHOT #
> # git clone git@github.com:marekkopecky/Resteasy.git -b bootable-jar-3-12-secure-processing
> # cd Resteasy
> # mvn install -DskipTests -Dcheckstyle.skip=true
> # cd testsuite
> # mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml
> # cd integration-tests
> # mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=${WF_VERSION} -Dserver.home=placeholder -Dcheckstyle.skip=true -Denforcer.skip -Dcheckstyle.skip=true -Dmaven.test.redirectTestOutputToFile=false
> I can move these steps outside of TS, but I believe that TS doesn't affects this bootable jar behaviour, so it doesn't seem to be necessary.
> I see just this unexpected&suspicious console output although I'm not sure whether it's related or not:
> {noformat}
> [org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 189; External DTD: Failed to read external DTD 'SecureProcessing_external.dtd', because 'file' access is not allowed due to restriction set by the accessExternalDTD property.]
> {noformat}
> cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFLY-13819) Drop jipijapa-hibernate5x-legacy modules
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-13819:
-----------------------------------
Summary: Drop jipijapa-hibernate5x-legacy modules
Key: WFLY-13819
URL: https://issues.redhat.com/browse/WFLY-13819
Project: WildFly
Issue Type: Bug
Components: Clustering, JPA / Hibernate
Affects Versions: 20.0.1.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The region factory implementations contained with these module have been non-functional for several releases, since they never registered their implementations with Hibernate's service registry.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFWIP-339:
-----------------------------------
Okay, just tried with a newer JDK8 version (this is not set as default in our CI yet):
{code}
$ /home/jstourac/jdks/jdk1.8.0_261/bin/java -version
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
{code}
and you are right - I cannot reproduce this neither anymore. Is this the JDK8 version you used?
One of the possible reasons for different behavior here may be the fact that JDK8u261 version has ALPN support backported into it already. And as such server does not have to use https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io... anymore?
> OpenSSL security provider seems to be used when not defined with JDK8 now
> -------------------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected!
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
> This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8:
> {code}
> <server-ssl-contexts>
> <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/>
> </server-ssl-contexts>
> <client-ssl-contexts>
> <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/>
> </client-ssl-contexts>
> {code}
> There are two questions from this:
> # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected?
> # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11.
> Hope I don't have any misconfiguration in the configuration itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFWIP-339:
-----------------------------------
Hm, I've tried again now and still I can reproduce:
# download build and unzip
{code}
$ md5sum wildfly-21.0.0.Beta1-SNAPSHOT.zip
9f24b4fc8d8acfbe7b9f7d3134eb6463 wildfly-21.0.0.Beta1-SNAPSHOT.zip
{code}
# download [^client.jks], [^server.jks] and [^standalone-full.xml] attachments and copy into the {{wildfly-21.0.0.Beta1-SNAPSHOT/standalone/configuration/}}
# start server with:
{code}
JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_241 wildfly-21.0.0.Beta1-SNAPSHOT/bin/standalone.sh -c standalone-full.xml
{code}
# I can see following in the log:
{code}
12:39:47,528 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-6) WFOPENSSL0002 OpenSSL Version OpenSSL 1.1.1g FIPS 21 Apr 2020
{code}
My JDK info:
{code}
$ /home/jstourac/jdks/jdk1.8.0_241/bin/java -version
java version "1.8.0_241"
Java(TM) SE Runtime Environment (build 1.8.0_241-b07)
Java HotSpot(TM) 64-Bit Server VM (build 25.241-b07, mixed mode)
{code}
My OpenSSL info:
{code}
$ openssl version
OpenSSL 1.1.1g FIPS 21 Apr 2020
{code}
> OpenSSL security provider seems to be used when not defined with JDK8 now
> -------------------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected!
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
> This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8:
> {code}
> <server-ssl-contexts>
> <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/>
> </server-ssl-contexts>
> <client-ssl-contexts>
> <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/>
> </client-ssl-contexts>
> {code}
> There are two questions from this:
> # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected?
> # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11.
> Hope I don't have any misconfiguration in the configuration itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months