[JBoss JIRA] (WFLY-11213) On release of batch it still contained JDBC statements logged
by Cody Lerum (Jira)
[ https://issues.jboss.org/browse/WFLY-11213?page=com.atlassian.jira.plugin... ]
Cody Lerum commented on WFLY-11213:
-----------------------------------
This remains an issue on Wildfly 18.0.0.Final
17:25:32,003 INFO [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (ServerService Thread Pool -- 117) HHH000010: On release of batch it still contained JDBC statement
Wondering if a new issue needs to be opened on this?
> On release of batch it still contained JDBC statements logged
> -------------------------------------------------------------
>
> Key: WFLY-11213
> URL: https://issues.jboss.org/browse/WFLY-11213
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 14.0.1.Final
> Environment: Java 8_181
> Wildfly 14.0.1.Final
> Reporter: Cody Lerum
> Assignee: Scott Marlow
> Priority: Major
>
> After updating from Wildfly 11 (Hibernate 5.1.10) to Wildfly 14.0.1 (Hibernate 5.3.6) I've started seeing the following log messages
> I’m starting to see the log message
> {code:java}
> 2018-10-17 20:12:47,571 INFO [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default task-54) HHH000010: On release of batch it still contained JDBC statements
> 2018-10-17 20:12:47,572 ERROR [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default task-54) HHH000352: Unable to release batch statement...
> {code}
> I’ve debugged where that is getting logged and all I can find is a single statement at the time.
> insert into EventLog (entityId, entityType, ipAddress, message, time, user, id) values (?, ?, ?, ?, ?, ?, ?)
> The only insert that is being created is actually being persisted to the database so this may be a spurious message.
> From my early debugging this appears to happen when 1 entity is persisted which does not need an immediate inset (due to having a generated pk) and then in another method of the same transaction an entity is persisted that does need an immediate insert because of a auto increment pk.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12691) Upgrade WildFly Core to 10.0.3.Final
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12691:
---------------------------------------
Summary: Upgrade WildFly Core to 10.0.3.Final
Key: WFLY-12691
URL: https://issues.jboss.org/browse/WFLY-12691
Project: WildFly
Issue Type: Component Upgrade
Components: Server
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
Fix For: 18.0.1.Final
Upgrade tracker for 18.0.1.Final fixes coming in via WildFly Core.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12655) Exception with web.xml url-pattern
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12655?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-12655:
--------------------------------------
The attached {{app.war}} should reproduce this issue.
> Exception with web.xml url-pattern
> ----------------------------------
>
> Key: WFLY-12655
> URL: https://issues.jboss.org/browse/WFLY-12655
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 18.0.0.Final
> Reporter: Frank Heldt
> Assignee: Flavia Rainone
> Priority: Blocker
> Fix For: 19.0.0.Beta1
>
> Attachments: app.war
>
>
> Defining and securing 2 folders in a war with similar names given this Exception on deployment:
> {code}
> 12:38:37,994 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: org.jboss.msc.service.StartException in service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: WFLYSEC0012: Unable to start the JaccService service
> at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:107)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: Invalid prefix pattern in URLPatternList
> at javax.security.jacc.api@2.0.0.Final//javax.security.jacc.URLPatternSpec.setURLPatternArray(URLPatternSpec.java:308)
> at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:79)
> at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:160)
> at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:303)
> at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:64)
> at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:86)
> ... 8 more
> {code}
> This is the corresponding part of the web.xml:
> {code}
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Area</web-resource-name>
> <url-pattern>/area/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>role1</role-name>
> <role-name>role2</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Area 51</web-resource-name>
> <url-pattern>/area51/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>role1</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> {code}
> Looks like this only happens when the url-pattern starts with the same characters (eg /area/* and /area51/*).
> The same war under WildFly 17.0.1 works as expected.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12655) Exception with web.xml url-pattern
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12655?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12655:
---------------------------------
Attachment: app.war
> Exception with web.xml url-pattern
> ----------------------------------
>
> Key: WFLY-12655
> URL: https://issues.jboss.org/browse/WFLY-12655
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 18.0.0.Final
> Reporter: Frank Heldt
> Assignee: Flavia Rainone
> Priority: Blocker
> Fix For: 19.0.0.Beta1
>
> Attachments: app.war
>
>
> Defining and securing 2 folders in a war with similar names given this Exception on deployment:
> {code}
> 12:38:37,994 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: org.jboss.msc.service.StartException in service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: WFLYSEC0012: Unable to start the JaccService service
> at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:107)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: Invalid prefix pattern in URLPatternList
> at javax.security.jacc.api@2.0.0.Final//javax.security.jacc.URLPatternSpec.setURLPatternArray(URLPatternSpec.java:308)
> at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:79)
> at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:160)
> at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:303)
> at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:64)
> at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:86)
> ... 8 more
> {code}
> This is the corresponding part of the web.xml:
> {code}
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Area</web-resource-name>
> <url-pattern>/area/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>role1</role-name>
> <role-name>role2</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Area 51</web-resource-name>
> <url-pattern>/area51/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>role1</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> {code}
> Looks like this only happens when the url-pattern starts with the same characters (eg /area/* and /area51/*).
> The same war under WildFly 17.0.1 works as expected.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12690) Metrics call causes java.util.ConcurrentModificationException
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12690?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-12690:
------------------------------------
Thanks I've created an issue in smallrye-metrics to guard against concurrent modification: https://github.com/smallrye/smallrye-metrics/issues/192
> Metrics call causes java.util.ConcurrentModificationException
> -------------------------------------------------------------
>
> Key: WFLY-12690
> URL: https://issues.jboss.org/browse/WFLY-12690
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 18.0.0.Final
> Environment: I ran the tests in our integration test environment. This includes a prometheus, scraping the metrics with an intervall of 5s.
> Reporter: Ralf Battenfeld
> Assignee: Jeff Mesnil
> Priority: Major
>
> Hi I ran our integrations tests together with prometheus calls. In Wildfly 18, I get this errors constantly:
> {code:java}
> 2019-10-18 14:22:57,284 ERROR [io.undertow.request] (management I/O-2) UT005071: Undertow request failed HttpServerExchange{ GET /metrics}: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1445)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1479)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1477)
> at java.util.HashMap.putMapEntries(HashMap.java:512)
> at java.util.HashMap.<init>(HashMap.java:490)
> at io.smallrye.metrics.MetricsRegistryImpl.getMetadata(MetricsRegistryImpl.java:560)
> at io.smallrye.metrics.exporters.OpenMetricsExporter.exposeEntries(OpenMetricsExporter.java:157)
> at io.smallrye.metrics.exporters.OpenMetricsExporter.getEntriesForScope(OpenMetricsExporter.java:150)
> at io.smallrye.metrics.exporters.OpenMetricsExporter.exportAllScopes(OpenMetricsExporter.java:101)
> at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:116)
> at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:73)
> at org.wildfly.extension.microprofile.metrics.MetricsContextService$1.handleRequest(MetricsContextService.java:81)
> at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
> at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
> at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
> at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:666)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12690) Metrics call causes java.util.ConcurrentModificationException
by Ralf Battenfeld (Jira)
Ralf Battenfeld created WFLY-12690:
--------------------------------------
Summary: Metrics call causes java.util.ConcurrentModificationException
Key: WFLY-12690
URL: https://issues.jboss.org/browse/WFLY-12690
Project: WildFly
Issue Type: Bug
Components: MP Metrics
Affects Versions: 18.0.0.Final
Environment: I ran the tests in our integration test environment. This includes a prometheus, scraping the metrics with an intervall of 5s.
Reporter: Ralf Battenfeld
Assignee: Jeff Mesnil
Hi I ran our integrations tests together with prometheus calls. In Wildfly 18, I get this errors constantly:
{code:java}
2019-10-18 14:22:57,284 ERROR [io.undertow.request] (management I/O-2) UT005071: Undertow request failed HttpServerExchange{ GET /metrics}: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1445)
at java.util.HashMap$EntryIterator.next(HashMap.java:1479)
at java.util.HashMap$EntryIterator.next(HashMap.java:1477)
at java.util.HashMap.putMapEntries(HashMap.java:512)
at java.util.HashMap.<init>(HashMap.java:490)
at io.smallrye.metrics.MetricsRegistryImpl.getMetadata(MetricsRegistryImpl.java:560)
at io.smallrye.metrics.exporters.OpenMetricsExporter.exposeEntries(OpenMetricsExporter.java:157)
at io.smallrye.metrics.exporters.OpenMetricsExporter.getEntriesForScope(OpenMetricsExporter.java:150)
at io.smallrye.metrics.exporters.OpenMetricsExporter.exportAllScopes(OpenMetricsExporter.java:101)
at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:116)
at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:73)
at org.wildfly.extension.microprofile.metrics.MetricsContextService$1.handleRequest(MetricsContextService.java:81)
at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:666)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Richard Opalka commented on WFWIP-160:
--------------------------------------
I oversaw JIRA description area was packed [~fjuma] - thanks for the info anyway.
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months