[
https://issues.apache.org/jira/browse/ARTEMIS-3117?focusedWorklogId=553560&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-553560
]
ASF GitHub Bot logged work on ARTEMIS-3117:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 17/Feb/21 11:23
Start Date: 17/Feb/21 11:23
Worklog Time Spent: 10m
Work Description: sebthom commented on a change in pull request #3456:
URL: https://github.com/apache/activemq-artemis/pull/3456#discussion_r577532185
##########
File path:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/ssl/DefaultOpenSSLContextFactory.java
##########
@@ -0,0 +1,95 @@
+/*
+ * Copyright 2021 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.core.remoting.impl.ssl;
+
+import java.util.Map;
+
+import org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector;
+import org.apache.activemq.artemis.core.remoting.impl.netty.TransportConstants;
+import org.apache.activemq.artemis.spi.core.remoting.ssl.OpenSSLContextFactory;
+
+import io.netty.handler.ssl.SslContext;
+
+/**
+ * Default {@link OpenSSLContextFactory} for use in {@link NettyConnector} and
NettyAcceptor.
+ */
+public class DefaultOpenSSLContextFactory implements OpenSSLContextFactory {
+
+ protected SSLSupport createSSLSupport(final Map<String, Object> config,
+ final String keystoreProvider, final String keystorePath, final String
keystorePassword,
Review comment:
In the same go I would also like to remove of the confusing
SSL_CONTEXT_PROP_NAME "sslContext" property as it's usage does not seem to make
much sense. Why would a caching SSL context factory be adviced to always return
the same SSL context no matter the given input parameters (keystore/truststore
etc) (which is currently how it is implemented in
[CachingSSLContextFactory](https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/ssl/CachingSSLContextFactory.java#L48)).
@clebertsuconic WDYT?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 553560)
Time Spent: 1.5h (was: 1h 20m)
> Performance degradation when switching from JDK8 to JDK11
> ---------------------------------------------------------
>
> Key: ARTEMIS-3117
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3117
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 2.16.0
> Environment: Amazon Linux 2, Amazon Corretto (OpenJDK 11), AMQP over
> TLS via BoringSSL
> Reporter: Sebastian T
> Priority: Major
> Attachments: broker.xml, image-2021-02-12-21-39-32-185.png,
> image-2021-02-12-21-40-21-125.png, image-2021-02-12-21-44-26-271.png,
> image-2021-02-12-21-46-52-006.png, image-2021-02-12-21-47-02-387.png,
> image-2021-02-12-21-47-57-301.png, image-2021-02-12-22-01-07-044.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Since it was announced that probably Artemis 2.18.0 will require Java 11 we
> upgraded the JVM of one of our broker clusters from OpenJDK 8 to OpenJDK 11
> and are seeing a noticable performance degradation which results in higher
> CPU usage and higher latency.
> We are monitoring request/reply round trip duration with a custom distributed
> qpid-jms based healthcheck applications. Here is a graphic that shows the
> effect when we switched the JDK:
> !image-2021-02-12-21-39-32-185.png!
> CPU Usage of the broker process:
> !image-2021-02-12-22-01-07-044.png|width=874,height=262!
>
> The broker itself is also monitored via Dynatrace, there I can see that after
> upgrading to JDK 11 the broker process spend 21% of CPU time locking while in
> JDK it only spent 3.2%.
> *JDK 8:*
> !image-2021-02-12-21-40-21-125.png|width=1247,height=438!
>
> *JDK 11:*
> *!image-2021-02-12-21-44-26-271.png|width=1197,height=420!*
>
> *A method hotspot breakdown reveals this:*
> !image-2021-02-12-21-47-02-387.png|width=1271,height=605!
> !image-2021-02-12-21-47-57-301.png|width=1059,height=627!
> Maybe I am misinterpreting the charts but the root cause seems to be
> somewhere in {{org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1}}
> and/or in
> {{org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.getSslHandler}}
> I currently cannot pinpoint the exact line number.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
