November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFWIP-160: ---------------------------------- [~dmlloyd] Do you have thoughts on how we could go about solving the problem [~ropalka] mentioned in his [previous comment|https://issues.jboss.org/browse/WFWIP-160?focusedCommentId=138157... > 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 > Attachments: jstourac-report.zip, performance-hotspot.png, results-tlsv12.zip, results-tlsv13.zip > > > 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. Start server with JDK11 and configure with TLSv1.3: > {code} > $ JAVA_HOME=/path/to/java/openjdk-11.0.2 <EAP_HOME>/bin/standalone.sh > $ <EAP_HOME>/bin/jboss-cli.sh -c > /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, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4767) Fix error-popover position on simulation/background grids

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4767?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-4767: ---------------------------------------- [~gabriolo] FYI, the PR that allows you to re-use {{CellContextUtilities.makeCellRenderContext()}} to get a cell's DOM {{(x, y)}} has been merged. > Fix error-popover position on simulation/background grids > --------------------------------------------------------- > > Key: DROOLS-4767 > URL: https://issues.jboss.org/browse/DROOLS-4767 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > > When there is only one column on the grid, the popover is show to the left. But if there is not enough space to the left, the popover is not visible. > Proposed solution, for this situation, is to show the popover _below_ the cell. > If there is not space below, the the popover will be shown _above_. > The final position preference order will be (respect the cell): > RIGTH -> LEFT -> BELOW -> ABOVE > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12827) Class not found com.sun.xml.internal.ws.encoding.StringDataContentHandler

by Dominik Derwiński (Jira)

[ https://issues.jboss.org/browse/WFLY-12827?page=com.atlassian.jira.plugin... ] Dominik Derwiński commented on WFLY-12827: ------------------------------------------ I have reported this issue: https://github.com/eclipse-ee4j/jaf/issues/33 I think Java Mail API / Activation libraries did not survive transition to JDK 11. Question is whether WildFly can provide missing classes to ease transition until said libraries will be fixed? > Class not found com.sun.xml.internal.ws.encoding.StringDataContentHandler > ------------------------------------------------------------------------- > > Key: WFLY-12827 > URL: https://issues.jboss.org/browse/WFLY-12827 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 18.0.1.Final > Reporter: Dominik Derwiński > Assignee: Tomaž Cerar > Priority: Major > > Trying to send email I get: > {noformat} > [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [43] : MailcapCommandMap: createDataContentHandler for text/plain > [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [43] : search DB #0 > [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [43] : got content-handler > [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [43] : class com.sun.xml.internal.ws.encoding.StringDataContentHandler > [2019-11-26 03:10:04.781] [javax.activation] [EE-ManagedThreadFactory-default-Thread-18] [FINE ] [com.sun.activation.registries.LogSupport] [log] [49] : Can't load DCH com.sun.xml.internal.ws.encoding.StringDataContentHandler: java.lang.ClassNotFoundException: com.sun.xml.internal.ws.encoding.StringDataContentHandler from [Module "javax.activation.api" version 1.2.1 from local module loader @82de64a (finder: local module finder @659499f1 (roots: /u01/wildfly/wildfly18/modules,/u01/wildfly/wildfly18/modules/system/layers/base))] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at javax.activation.api@1.2.1//javax.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:598) > at javax.activation.api@1.2.1//javax.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:555) > at javax.activation.api@1.2.1//javax.activation.DataHandler.getDataContentHandler(DataHandler.java:600) > at javax.activation.api@1.2.1//javax.activation.DataHandler.writeTo(DataHandler.java:299) > at javax.mail.api@1.6.4//javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:316) > at javax.mail.api@1.6.4//javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1551) > at javax.mail.api@1.6.4//javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1148) > at javax.mail.api@1.6.4//javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:498) > at javax.mail.api@1.6.4//javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1509) > at javax.mail.api@1.6.4//javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2238) > at javax.mail.api@1.6.4//javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2198) > at javax.mail.api@1.6.4//javax.mail.Transport.send(Transport.java:99) > {noformat} > Maybe it's just missing module dependency for javax.mail.api, maybe you need to include JAXB and JAXWS libraries in WildFly modules for use on JDK 11+, when they were removed from JDK. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4655) Test Scenario: refactor drools-wb-scenario-simulation-editor to use ConstantsHolder.VALUE

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-4655?page=com.atlassian.jira.plugi... ] Yeser Amer updated DROOLS-4655: ------------------------------- Priority: Minor (was: Major) > Test Scenario: refactor drools-wb-scenario-simulation-editor to use ConstantsHolder.VALUE > ----------------------------------------------------------------------------------------- > > Key: DROOLS-4655 > URL: https://issues.jboss.org/browse/DROOLS-4655 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Minor > Labels: ScenarioSimulation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4807) [DMN Designer] Do not group V&V messages by UUID

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4807?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-4807: ---------------------------------------- [~tdolphine] [~kgaevski] [~roger.martinez] Can you please comment on this. https://github.com/kiegroup/kie-wb-common/pull/2661/files#diff-6d23504287... added grouping of {{DomainViolation}} by (graph) {{element id}}. This seems to have the opposite effect to that requested by https://issues.jboss.org/browse/JBPM-7436 that seemed to request messages should be split. Can you confirm BPMN's use of [ProjectValidationServiceImpl|https://github.com/kiegroup/kie-wb-common/bl...] is working as expected? If BPMN is working as expected then I'll need to work out a way to allow DMN's {{DomainValidator}}'s {{DomainViolation}} objects not to be grouped whilst preserving the grouping behaviour applied to BPMN's {{DomainValidator}} {{DomainViolation}} messages. > [DMN Designer] Do not group V&V messages by UUID > ------------------------------------------------ > > Key: DROOLS-4807 > URL: https://issues.jboss.org/browse/DROOLS-4807 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.30.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: V&V.png > > > The V&V results are grouped by UUID. See attached screen-shot. > These items are reported individually by {{kie-dmn-validation}} but grouped by {{org.kie.workbench.common.dmn.showcase.backend.validation.ValidationServiceImpl}} in the _standalone_ webapp however I fear Stunner's generic {{ValidationService}} does the same in Business Central and hence reporting DMN V&V per-line may be more troublesum. > See [here|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...] that should more correctly be:- > {code} > @Override > public Collection<DiagramElementViolation<RuleViolation>> validate(Diagram diagram) { > return domainViolations(diagram).stream() > .filter(v -> Objects.nonNull(v.getUUID())) > .filter(v -> !"null".equals(v.getUUID())) > .map(v -> new ElementViolationImpl.Builder().setUuid(v.getUUID()).setDomainViolations(Collections.singletonList(v)).build()) > .collect(Collectors.toList()); > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4762) Add HostExcludeResourceDefinition.KnownRelease values

by Jeff Mesnil (Jira)

Jeff Mesnil created WFCORE-4762: ----------------------------------- Summary: Add HostExcludeResourceDefinition.KnownRelease values Key: WFCORE-4762 URL: https://issues.jboss.org/browse/WFCORE-4762 Project: WildFly Core Issue Type: Task Components: Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 11.0.0.Beta4 Add entries for WF 16, 17, 18. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4807) [DMN Designer] Do not group V&V messages by UUID

by Michael Anstis (Jira)

Michael Anstis created DROOLS-4807: -------------------------------------- Summary: [DMN Designer] Do not group V&V messages by UUID Key: DROOLS-4807 URL: https://issues.jboss.org/browse/DROOLS-4807 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.30.0.Final Reporter: Michael Anstis Assignee: Michael Anstis Attachments: V&V.png The V&V results are grouped by UUID. See attached screen-shot. These items are reported individually by {{kie-dmn-validation}} but grouped by {{org.kie.workbench.common.dmn.showcase.backend.validation.ValidationServiceImpl}} in the _standalone_ webapp however I fear Stunner's generic {{ValidationService}} does the same in Business Central and hence reporting DMN V&V per-line may be more troublesum. See [here|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...] that should more correctly be:- {code} @Override public Collection<DiagramElementViolation<RuleViolation>> validate(Diagram diagram) { return domainViolations(diagram).stream() .filter(v -> Objects.nonNull(v.getUUID())) .filter(v -> !"null".equals(v.getUUID())) .map(v -> new ElementViolationImpl.Builder().setUuid(v.getUUID()).setDomainViolations(Collections.singletonList(v)).build()) .collect(Collectors.toList()); } {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6631) EJB 2.1 BMP Entity beans are not synchronized correctly

by Tomasz Adamski (Jira)

[ https://issues.jboss.org/browse/WFLY-6631?page=com.atlassian.jira.plugin.... ] Tomasz Adamski resolved WFLY-6631. ---------------------------------- Resolution: Out of Date > EJB 2.1 BMP Entity beans are not synchronized correctly > ------------------------------------------------------- > > Key: WFLY-6631 > URL: https://issues.jboss.org/browse/WFLY-6631 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Marco Zanker > Priority: Major > > This problem was discussed in the following threads and still exists in wildfly 10. > https://developer.jboss.org/message/794417 > https://issues.jboss.org/browse/WFLY-841 > But this is not alone a problem of EJB 2.1 CMP Beans. *EJB 2.1 BMP Beans also affected*. We are running in this problem during migrating to the new wildfly version with several EJB2.1 components. As I know there is no offical statement EJB2.1 BMP Beans are not supported anymore?! > Thanks and best regards > Marco -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4385) Authentication is not propagated to EJB in the login request

by Tomasz Adamski (Jira)

[ https://issues.jboss.org/browse/WFLY-4385?page=com.atlassian.jira.plugin.... ] Tomasz Adamski closed WFLY-4385. -------------------------------- Resolution: Out of Date > Authentication is not propagated to EJB in the login request > ------------------------------------------------------------ > > Key: WFLY-4385 > URL: https://issues.jboss.org/browse/WFLY-4385 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final > Environment: MAC OSX YOSEMITE > JAVA ORACLE 1.8 > WILDFLY 8.2.0.FINAL STANDALONE > Reporter: Paulo Cesar Silva Reis > Priority: Major > Labels: authentication, ejb, http, login, roles, web > Attachments: wildfly-4385.zip > > > I'm migrating from glassfish to wildfly and noticed few weird things. > When you perform login through web container (request.login(user, pwd)), the principal is not propagated to EJB Container, only for web container. > To test that, this is what I did: > . BASIC AUTH > . EJB receives HttpServletRequest with user data and perform login > . Print request.getUserPrincipal() => ok, logged in > . Print EJBContext.getCallerPrincipal() => anonymous > This happens in the same request that user logged in. In the subsequent requests (using Set-Cookie response and cookie with JSESSIONID in request), the EJB is aware of the authentication. > Is that the right behavior? 'Cause in glassfish is different, the principal is propagated immediately to EJB. > Thanks in advance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4169) Wildfly doesn't fail on deployment EJB with CDI @Transactional

by Tomasz Adamski (Jira)

[ https://issues.jboss.org/browse/WFLY-4169?page=com.atlassian.jira.plugin.... ] Tomasz Adamski closed WFLY-4169. -------------------------------- Resolution: Rejected > Wildfly doesn't fail on deployment EJB with CDI @Transactional > -------------------------------------------------------------- > > Key: WFLY-4169 > URL: https://issues.jboss.org/browse/WFLY-4169 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final > Reporter: Kamil Żbikowski > Priority: Major > > When javax.transaction.@Transactional CDI is put on EJB application is able to be correctly deployed on the server. According to JSR345 it should not be possible. ??It is illegal to associate JTA transactional interceptors \[8\] with Enterprise JavaBeans. The EJB Container should fail deployment of such applications.?? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 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 November 2019