September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11000) Upgrade dom4j from 1.6.1 to 2.1.1

by Chao Wang (JIRA)

Chao Wang created WFLY-11000: -------------------------------- Summary: Upgrade dom4j from 1.6.1 to 2.1.1 Key: WFLY-11000 URL: https://issues.jboss.org/browse/WFLY-11000 Project: WildFly Issue Type: Component Upgrade Affects Versions: 14.0.0.Final Reporter: Chao Wang -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10999) Upgrade Infinispan to 9.4.0.Final

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-10999: ----------------------------------- Summary: Upgrade Infinispan to 9.4.0.Final Key: WFLY-10999 URL: https://issues.jboss.org/browse/WFLY-10999 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 14.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10991) Memory leak when deployment is redeployed multiple times

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFLY-10991?page=com.atlassian.jira.plugin... ] Jan Stourac edited comment on WFLY-10991 at 9/10/18 7:52 AM: ------------------------------------------------------------- [~juraci.costa], yeah - the leak was 25MB for 100 re-deployments, so the fix you provided is probably the right-one. Thank you for running our test against that version. I'll do that myself manually too but as test passed for you I believe that the fix is correct :) EDIT: Already commented on MR on GitHub, but just for the reference - attached MR fixes the issue. Thanks Juraci! was (Author: jstourac): [~juraci.costa], yeah - the leak was 25MB for 100 re-deployments, so the fix you provided is probably the right-one. Thank you for running our test against that version. I'll do that myself manually too but as test passed for you I believe that the fix is correct :) > Memory leak when deployment is redeployed multiple times > -------------------------------------------------------- > > Key: WFLY-10991 > URL: https://issues.jboss.org/browse/WFLY-10991 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Stourac > Assignee: Juraci Paixão Kröhling > Priority: Blocker > Attachments: memoryLeaks.war, problematic-wf-build-heap-diff-start-end-org-filter.png, problematic-wf-build-heap-diff-start-end.png, sane-wf-build-heap-diff-start-end-org-filter.png, sane-wf-build-heap-diff-start-end.png > > > It looks like redeploying attached deployment [^memoryLeaks.war] multiple times (our automated test does it 100 times), there seems to be some memory leak in the WildFly. Using git bisect, the commit that started to fail is [651dc8a2f0d4ccad6a35f7b1d28626b43ebb2a5d in WildFly repository|https://github.com/wildfly/wildfly/commits/651dc8a2f0d4ccad6a3...]. That is why I selected MP OpenTracing component for this issue. Actual testing deployment is very simple and contains just some jsp file with some EJB classes that are used to call GC and check current heap usage. > Brief description of the test: > # attached deployment is deployed > # System.gc() is called via EJB call > # it checks initial heap usage at the beginning of the test via EJB call that checks all instances of ManagementFactory.getMemoryPoolMXBeans() > # deployment is redeployed 100 times > # calls System.gc() via EJP call again and checks heap usage again via EJB call and compares the results > Size of the extra heap in use is about 25MB plus when compared to the initial size. > I tried to check manually via [visualVM|https://visualvm.github.io/] tool. You can create a heapdump at the beginning of the test and at the end of the test. Then compare them easily and check the differences. Using a filter I can see quite a huge increase of instances of the {{org.jboss.modules.*}} classes. However, biggest memory footprint is huge increase of the instances of the {{java.util.HashMap$Node}}, {{char[]}}, {{java.util.HashMap$Node[]}} and few others. I don't see such huge increase of the instances of these classes when I use older build of WildFly prior to the problematic commit. To be honest I don't see direct link with the problematic commit I linked before. As the heapdumps are too big to be attached here, I am attaching some screenshots. > Also, when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > then no more memory leak is detected, after adding the subsystem back, the leak is present again. Thus opentracing is involved somehow into this indeed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10956) Upgrade Infinispan to 9.3.3.Final

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10956?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-10956: -------------------------------- Summary: Upgrade Infinispan to 9.3.3.Final (was: Upgrade Infinispan to 9.4.0.Final) > Upgrade Infinispan to 9.3.3.Final > --------------------------------- > > Key: WFLY-10956 > URL: https://issues.jboss.org/browse/WFLY-10956 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 14.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-19) Upgrade Undertow version to 2.0.13.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELYWEB-19: -------------------------------------- Summary: Upgrade Undertow version to 2.0.13.Final Key: ELYWEB-19 URL: https://issues.jboss.org/browse/ELYWEB-19 Project: Elytron Web Issue Type: Component Upgrade Components: Undertow, Undertow Servlet Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.4.CR1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-18) SNI Integration

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELYWEB-18: -------------------------------------- Summary: SNI Integration Key: ELYWEB-18 URL: https://issues.jboss.org/browse/ELYWEB-18 Project: Elytron Web Issue Type: Task Components: Undertow Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.4.CR1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBEE-196) JSP and JSTL missing from EE 7 BOM

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/JBEE-196?page=com.atlassian.jira.plugin.s... ] Eduardo Martins commented on JBEE-196: -------------------------------------- The PRs look fine to me, WFLY parent pom's dep management also uses compile scope for these, not provided. Also, just in case this was not correct on WFLY parent I did check the dependencies in the apache libs, and all have provided scope. > JSP and JSTL missing from EE 7 BOM > ---------------------------------- > > Key: JBEE-196 > URL: https://issues.jboss.org/browse/JBEE-196 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Affects Versions: JavaEE 7 Spec APIs 1.1.0.Final > Reporter: Rich DiCroce > Assignee: Eduardo Martins > > jboss-javaee-7.0 version 1.0.4 includes JSP and JSTL. Version 1.1.0 and later effectively do not, because they declare those dependencies to be provided scope for some reason. Servlet would also be affected, except JACC has a transitive dependency on it. > This bug appears to have been introduced as part of resolving JBEE-170. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9702) SSO Integration for Programmatic Authentication

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9702?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9702: --------------------------------- Description: At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication. In this scenario we don't have either a wrapped mechanism or a CallbackHandler. Couple of options: * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on. * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication? * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process. was: At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication. In this scenario we don't have either a wrapped mechanism or a CallbackHandler. Couple of options: - * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on. * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication? * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process. * > SSO Integration for Programmatic Authentication > ----------------------------------------------- > > Key: WFLY-9702 > URL: https://issues.jboss.org/browse/WFLY-9702 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > > At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication. > In this scenario we don't have either a wrapped mechanism or a CallbackHandler. > Couple of options: > * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on. > * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication? > * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10845) WildFly 13 Infinispan 9.2 Query

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10845?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10845: ---------------------------------- Summary: WildFly 13 Infinispan 9.2 Query (was: WildFly13 Infinispan 9.2 Query) > WildFly 13 Infinispan 9.2 Query > ------------------------------- > > Key: WFLY-10845 > URL: https://issues.jboss.org/browse/WFLY-10845 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Majid Mostafavi > Assignee: Paul Ferraro > > standalone.xml > {color:#14892c}<cache-container name="gridCache" default-cache="default" module="org.infinispan.query:ispn-9.2"> > <local-cache name="default"> > <locking isolation="REPEATABLE_READ"/> > <transaction locking="OPTIMISTIC" mode="FULL_XA"/> > <file-store passivation="true" purge="false"/> > </local-cache> > </cache-container>{color} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2983) Failed to checkout droolsjbpm-integration project on Windows

by Ramūnas K (JIRA)

Ramūnas K created DROOLS-2983: --------------------------------- Summary: Failed to checkout droolsjbpm-integration project on Windows Key: DROOLS-2983 URL: https://issues.jboss.org/browse/DROOLS-2983 Project: Drools Issue Type: Bug Affects Versions: 7.12.0.Final Environment: Windows 10 Enterprise C:\ drive with NTFS filesystem GIT version "git version 2.18.0.windows.1" Reporter: Ramūnas K Assignee: Mario Fusco Priority: Critical Attachments: screen_2018-09-10_14_03_11.png Unable to checkout [droolsjbpm-integration|https://github.com/kiegroup/droolsjbpm-integration] on Windows 10 with NTFS file system. Filename {{kie-integration-test-coverage/kie-maven-plugin-separate-model-tests/kjar-with-separate-instrumentation-wrapper/src/test/resources/kjar-with-separate-instrumentation/src/main/resources/org/kie/integration/testcoverage/instrumentation}} is too long -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 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 September 2018