December 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-14234) EJB bean method direct memory buffer leaking

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFLY-14234?page=com.atlassian.jira.plugi... ] Flavia Rainone reassigned WFLY-14234: ------------------------------------- Assignee: Flavia Rainone (was: Cheng Fang) > EJB bean method direct memory buffer leaking > -------------------------------------------- > > Key: WFLY-14234 > URL: https://issues.redhat.com/browse/WFLY-14234 > Project: WildFly > Issue Type: Bug > Components: EJB, IO > Affects Versions: 19.0.0.Final > Reporter: Mike Zhary > Assignee: Flavia Rainone > Priority: Major > Attachments: 2020-11-10-112753_563x276_scrot.png, src_main_java_org_jboss_remoting3_remote_RemoteConnectionProvider.java > > > Wildfly.19.0.1.Final standalone > We're using haproxy to balance ejb calls between wildfly servers. > That's very useful model, but there are problems with it. > All connections are declared as remote-outbound-connection and it works. > {code} > <remote-outbound-connection name="{{ c.name }}" outbound-socket-binding-ref="{{ c.socket_binding }}" protocol="http-remoting" security-realm="{{ c.security_realm }}" username="{{ c.user }}"> > <properties> > <property name="SASL_POLICY_NOANONYMOUS" value="false"/> > <property name="SSL_ENABLED" value="false"/> > </properties> > </remote-outbound-connection> > {code} > But there is the problem when some from servers is offline. haproxy send response by http and sends RST by tcp, but WF can't make sense of this response. > Problem can be reprouced when servers listening port, but there is no repsonse for ejb call(in our case it means haproxy doesn't have suitable backend online) > But everything is clear, when port closed or server don't response for a calls. > Haproxy doesn't have feature to don't listen port if backed is offline. > At OS problems shows as huge count(equal to thread count) of connections in state CLOSE_WAIT. That means server had send packet TCP_FIN and client accepted it, but there were no respond on it. In other words WF and it's subsystems didn't agree with closing connection and it becomes to CLOSE_WAIT. At OS side closing connection in sometime and took it as dead(it's normal case) > At WF memory it appears as growing count of objects org.xnio.ByteBufferSlicePool$PooledByteBuffer, that have attribute buffer that holds about 2mb each. > Take a look: > !2020-11-10-112753_563x276_scrot.png|thumbnail! > Problem allocated in XNIO library. There were found a mistake and looks very similar to our problem. XNIO-254 > The same time we'd found XNIO-380 and we tried it with last version of this library(snapshot 3.9), no results were there. > We tried get undrestanding ow DMB clean, but did nothing due to too complicated code design. > As per investigations DMB used for an SSL connection, but we don't it. > So we were to patch jboss-remoting class RemoteConnectionProvider. > after that we'd solved issue with leaking of DMB. > Our patched library: [^src_main_java_org_jboss_remoting3_remote_RemoteConnectionProvider.java] > Please take look how this bug can be fixed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14233) Undertow xnio direct memory buffer leaking

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFLY-14233?page=com.atlassian.jira.plugi... ] Flavia Rainone commented on WFLY-14233: --------------------------------------- [~zharymv] As you said yourself, GC does not clean directly allocated memory. That's why we have the directBuffers collection, it allows reuse of directly allocated memory so we can prevent allocating new memory when we can just reuse memory that has been previously allocatedl. By deleting it from the code, you remove the very same mechanism to prevent direct memory leak. You mentioned you disabled some cache mechanism so that now GC frees the directly allocated memory. Can you explain this workaround better? Also, can you walk me through how to reproduce the OutOfMemoryError you're seeing? If you could provide an application that does that, the better. > Undertow xnio direct memory buffer leaking > ------------------------------------------ > > Key: WFLY-14233 > URL: https://issues.redhat.com/browse/WFLY-14233 > Project: WildFly > Issue Type: Bug > Components: IO, Web (Undertow) > Affects Versions: 19.0.0.Final > Reporter: Mike Zhary > Assignee: Flavia Rainone > Priority: Major > Attachments: 2020-11-10-112753_563x276_scrot.png, api_src_main_java_org_xnio_ByteBufferSlicePool.java, image_2020_10_30T09_55_47_082Z.png, Снимок экрана 2020-12-16 в 15.33.53.png, Снимок экрана 2020-12-16 в 15.34.20.png > > > Wildfly.19.0.1.Final standalone > We'd found an issue with direct memory buffer leaking on one from our servers. > There is rest api application allocated there. > it provides hugh data on some requests. > As per graphics we noticed that there is corrielation between sessions on server and using of direct memory buffer. > !Снимок экрана 2020-12-16 в 15.33.53.png|width=1199,height=400!!Снимок экрана 2020-12-16 в 15.34.20.png|width=1170,height=392! > Our suggestion was that direct memory buffer is reallocatable with new web requests, that's we tried change session lifetime to minimum we prefer. > You can see it on graphs with memory. Red line means direct memory buffer. > At first time it takes as much as it can, but after changing session lifetime we faced the same problem. > There are some drops of redline to zero, but there were restarts of wildfly. > As per our investigations there is the problem in that GC free some part of memory, but it can't get DMB and that's why it increases. > Something allocates ByteBufferSlicePool (but it marked as depricated, so I think it'll disappared in sometime, but our bug still reproduceable on WF21) > {code:java} > 2020-10-15 18:24:59,569 ERROR (default I/O-4) [listener] [SOMEAPP] XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory > at java.base/java.nio.Bits.reserveMemory(Bits.java:175) > at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118) > at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317) > at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) > at org.jboss.xnio@3.7.3.Final//org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) > at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocateSlices(ByteBufferSlicePool.java:162) > at org.jboss.xnio@3.7.3.Final//org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149) > at io.undertow.core@2.0.27.Final//io.undertow.server.XnioByteBufferPool.allocate(XnioByteBufferPool.java:53) > at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:147) > at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136) > at io.undertow.core@2.0.27.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59) > at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.jboss.xnio@3.7.3.Final//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.jboss.xnio.nio@3.7.3.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > {code} > !2020-11-10-112753_563x276_scrot.png|thumbnail! > When something needs memory it allocates and save this memory to directBuffers(that was removed) > Seems there is a point of leaking in that some code allocates direct memory when client doesn't need it > Another point is at method of cleaning of direct memory. When it called directBuffers saves in static variable of class as null-buffers and it can be reusable for ByteBufferSlicePool, that is potential leak point, because of this variable never clean just accumulate. > So, after removing variable directBuffers we'd found a "method". > We'd disable some cache mechanism of allocated memory areas and now clients of this lib gets DMB directly and when it free GC clean it. > You can see it on graphics. first part of it shows that DMB grows before maxim get OOM and another part is when there is no problem with OOM. > Some nearest issue WFCORE-4600 > that is our patched library: > [^api_src_main_java_org_xnio_ByteBufferSlicePool.java] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14201) Integrate MP Config 2.0 into EAP

by Kabir Khan (Jira)

[ https://issues.redhat.com/browse/WFLY-14201?page=com.atlassian.jira.plugi... ] Kabir Khan commented on WFLY-14201: ----------------------------------- My feature branch updating to MP Config 2.0 can be found at https://github.com/kabir/wildfly/tree/WFLY-14201-MP-Config-2.0 It relies on a RestEasy SNAPSHOT built from https://github.com/kabir/Resteasy/tree/3.14-mp-config-2.0. I'll update that to a proper release once I have one > Integrate MP Config 2.0 into EAP > -------------------------------- > > Key: WFLY-14201 > URL: https://issues.redhat.com/browse/WFLY-14201 > Project: WildFly > Issue Type: Feature Request > Components: MP Config > Reporter: Stefano Maestri > Assignee: Kabir Khan > Priority: Major > Labels: MP4.0 > > See: > [Config 2.0|https://github.com/microprofile/microprofile-wg/issues/9] > [https://github.com/eclipse/microprofile-config/blob/master/spec/src/main/...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14240) Upgrade EE 9 variant to Weld 4 Final version

by Matěj Novotný (Jira)

[ https://issues.redhat.com/browse/WFLY-14240?page=com.atlassian.jira.plugi... ] Matěj Novotný updated WFLY-14240: --------------------------------- Fix Version/s: 22.0.0.Final > Upgrade EE 9 variant to Weld 4 Final version > -------------------------------------------- > > Key: WFLY-14240 > URL: https://issues.redhat.com/browse/WFLY-14240 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Reporter: Matěj Novotný > Assignee: Matěj Novotný > Priority: Major > Fix For: 22.0.0.Final > > > Final version of Weld 4 core and API is now available and can be upgraded in WFLY. > More information here - http://weld.cdi-spec.org/news/2020/12/16/weld-400Final/ > I will send a PR shortly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14240) Upgrade EE 9 variant to Weld 4 Final version

by Matěj Novotný (Jira)

[ https://issues.redhat.com/browse/WFLY-14240?page=com.atlassian.jira.plugi... ] Matěj Novotný updated WFLY-14240: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13831 > Upgrade EE 9 variant to Weld 4 Final version > -------------------------------------------- > > Key: WFLY-14240 > URL: https://issues.redhat.com/browse/WFLY-14240 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Reporter: Matěj Novotný > Assignee: Matěj Novotný > Priority: Major > > Final version of Weld 4 core and API is now available and can be upgraded in WFLY. > More information here - http://weld.cdi-spec.org/news/2020/12/16/weld-400Final/ > I will send a PR shortly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14240) Upgrade EE 9 variant to Weld 4 Final version

by Matěj Novotný (Jira)

Matěj Novotný created WFLY-14240: ------------------------------------ Summary: Upgrade EE 9 variant to Weld 4 Final version Key: WFLY-14240 URL: https://issues.redhat.com/browse/WFLY-14240 Project: WildFly Issue Type: Component Upgrade Components: CDI / Weld Reporter: Matěj Novotný Assignee: Matěj Novotný Final version of Weld 4 core and API is now available and can be upgraded in WFLY. More information here - http://weld.cdi-spec.org/news/2020/12/16/weld-400Final/ I will send a PR shortly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14239) jboss-eap-xp2 imagestreams-templates are using a wrong (2.0) tag

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-14239?page=com.atlassian.jira.plugi... ] Eduardo Martins updated WFLY-14239: ----------------------------------- Fix Version/s: 22.0.0.Final > jboss-eap-xp2 imagestreams-templates are using a wrong (2.0) tag > ---------------------------------------------------------------- > > Key: WFLY-14239 > URL: https://issues.redhat.com/browse/WFLY-14239 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 22.0.0.Beta1 > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Blocker > Fix For: 22.0.0.Final > > > I've learned that XP2 images will be tagged by 1.0, however the import templates are using the 2.0, which will create the broken image streams > {code} > "from": { > "kind": "DockerImage", > "name": "registry.redhat.io/jboss-eap-7/eap-xp2-openjdk8-openshift-rhel7:2.0" > {code} > Also, following the docs (with respect to fix for JBEAP-20718 - see https://github.com/jbossas/eap-quickstarts/pull/211/files), the import image stream templates tags the created image streams with [2.0,latest] tags, however all the documentation examples are using the 1.0 tag (see https://github.com/jbossas/eap-quickstarts/pull/211/files) > {code:bash} > $ oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-opensh... > $ oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-opensh... > $ oc get imagestream > NAME IMAGE REPOSITORY TAGS UPDATED > jboss-eap-xp2-openjdk11-openshift default-route-openshift-image-registry.apps-crc.testing/pkremens-namespace/jboss-eap-xp2-openjdk11-openshift 2.0,latest > jboss-eap-xp2-openjdk11-runtime-openshift default-route-openshift-image-registry.apps-crc.testing/pkremens-namespace/jboss-eap-xp2-openjdk11-runtime-openshift 2.0,latest > jboss-eap-xp2-openjdk8-openshift default-route-openshift-image-registry.apps-crc.testing/pkremens-namespace/jboss-eap-xp2-openjdk8-openshift 2.0,latest > jboss-eap-xp2-openjdk8-runtime-openshift default-route-openshift-image-registry.apps-crc.testing/pkremens-namespace/jboss-eap-xp2-openjdk8-runtime-openshift 2.0,latest > {code} > Docs example: > {code:bash} > $ oc new-app --template={ImagePrefixVersion}-basic-s2i \ > -p EAP_IMAGE_NAME=jboss-{ImagePrefixVersion}-openjdk8-openshift:1.0 \ > -p EAP_RUNTIME_IMAGE_NAME=jboss-{ImagePrefixVersion}-openjdk8-runtime-openshift:1.0 \ > -p IMAGE_STREAM_NAMESPACE="{artifactId}-project" \ > -p SOURCE_REPOSITORY_URL="{EAPQuickStartRepo}" \ > -p SOURCE_REPOSITORY_REF="{EAPQuickStartRepoRef}" \ > -p CONTEXT_DIR="{artifactId}" > {code} > Maybe we should simply go with the ":latest" to avoid these. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14239) jboss-eap-xp2 imagestreams-templates are using a wrong (2.0) tag

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-14239?page=com.atlassian.jira.plugi... ] Eduardo Martins moved JBEAP-20735 to WFLY-14239: ------------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-14239 (was: JBEAP-20735) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Quickstarts (was: Quickstarts) Affects Version/s: 22.0.0.Beta1 (was: EAP-XP-2.0.0.CR1) > jboss-eap-xp2 imagestreams-templates are using a wrong (2.0) tag > ---------------------------------------------------------------- > > Key: WFLY-14239 > URL: https://issues.redhat.com/browse/WFLY-14239 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 22.0.0.Beta1 > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Blocker > > I've learned that XP2 images will be tagged by 1.0, however the import templates are using the 2.0, which will create the broken image streams > {code} > "from": { > "kind": "DockerImage", > "name": "registry.redhat.io/jboss-eap-7/eap-xp2-openjdk8-openshift-rhel7:2.0" > {code} > Also, following the docs (with respect to fix for JBEAP-20718 - see https://github.com/jbossas/eap-quickstarts/pull/211/files), the import image stream templates tags the created image streams with [2.0,latest] tags, however all the documentation examples are using the 1.0 tag (see https://github.com/jbossas/eap-quickstarts/pull/211/files) > {code:bash} > $ oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-opensh... > $ oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-opensh... > $ oc get imagestream > NAME IMAGE REPOSITORY TAGS UPDATED > jboss-eap-xp2-openjdk11-openshift default-route-openshift-image-registry.apps-crc.testing/pkremens-namespace/jboss-eap-xp2-openjdk11-openshift 2.0,latest > jboss-eap-xp2-openjdk11-runtime-openshift default-route-openshift-image-registry.apps-crc.testing/pkremens-namespace/jboss-eap-xp2-openjdk11-runtime-openshift 2.0,latest > jboss-eap-xp2-openjdk8-openshift default-route-openshift-image-registry.apps-crc.testing/pkremens-namespace/jboss-eap-xp2-openjdk8-openshift 2.0,latest > jboss-eap-xp2-openjdk8-runtime-openshift default-route-openshift-image-registry.apps-crc.testing/pkremens-namespace/jboss-eap-xp2-openjdk8-runtime-openshift 2.0,latest > {code} > Docs example: > {code:bash} > $ oc new-app --template={ImagePrefixVersion}-basic-s2i \ > -p EAP_IMAGE_NAME=jboss-{ImagePrefixVersion}-openjdk8-openshift:1.0 \ > -p EAP_RUNTIME_IMAGE_NAME=jboss-{ImagePrefixVersion}-openjdk8-runtime-openshift:1.0 \ > -p IMAGE_STREAM_NAMESPACE="{artifactId}-project" \ > -p SOURCE_REPOSITORY_URL="{EAPQuickStartRepo}" \ > -p SOURCE_REPOSITORY_REF="{EAPQuickStartRepoRef}" \ > -p CONTEXT_DIR="{artifactId}" > {code} > Maybe we should simply go with the ":latest" to avoid these. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14238) FaceletsResourceResolver annotation is not taken into account

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFLY-14238?page=com.atlassian.jira.plugi... ] Ricardo Martin Camarero updated WFLY-14238: ------------------------------------------- Attachment: test-servlet30-faceletResourceResolver2.war > FaceletsResourceResolver annotation is not taken into account > ------------------------------------------------------------- > > Key: WFLY-14238 > URL: https://issues.redhat.com/browse/WFLY-14238 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 21.0.1.Final > Reporter: Ricardo Martin Camarero > Assignee: Ricardo Martin Camarero > Priority: Major > Attachments: test-servlet30-faceletResourceResolver2.war > > > The annotation [@FaceletsResourceResolver|https://javaee.github.io/javaee-spec/javadocs/index.html?javax/faces/view/facelets/FaceletsResourceResolver.html] is just not considered in a JSF application. The reason is that it is not taken into account [here|https://github.com/wildfly/wildfly/blob/21.0.1.Final/jsf/subsystem/s...]. > There are at least two tests in the JSF test-suite that check this annotation, [faceletResourceResolver2|https://github.com/eclipse-ee4j/mojarra/tree/2.3...] is one of the tests that fails. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14238) FaceletsResourceResolver annotation is not taken into account

by Ricardo Martin Camarero (Jira)

Ricardo Martin Camarero created WFLY-14238: ---------------------------------------------- Summary: FaceletsResourceResolver annotation is not taken into account Key: WFLY-14238 URL: https://issues.redhat.com/browse/WFLY-14238 Project: WildFly Issue Type: Bug Components: JSF Affects Versions: 21.0.1.Final Reporter: Ricardo Martin Camarero Assignee: Ricardo Martin Camarero Attachments: test-servlet30-faceletResourceResolver2.war The annotation [@FaceletsResourceResolver|https://javaee.github.io/javaee-spec/javadocs/index.html?javax/faces/view/facelets/FaceletsResourceResolver.html] is just not considered in a JSF application. The reason is that it is not taken into account [here|https://github.com/wildfly/wildfly/blob/21.0.1.Final/jsf/subsystem/s...]. There are at least two tests in the JSF test-suite that check this annotation, [faceletResourceResolver2|https://github.com/eclipse-ee4j/mojarra/tree/2.3...] is one of the tests that fails. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 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 December 2020