[JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12446?page=com.atlassian.jira.plugin... ]
Cheng Fang updated WFLY-12446:
------------------------------
Attachment: (was: dump.png)
> Memory leak in StatelessSessionComponent
> ----------------------------------------
>
> Key: WFLY-12446
> URL: https://issues.jboss.org/browse/WFLY-12446
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Reporter: Joerg Baesner
> Assignee: Cheng Fang
> Priority: Major
> Attachments: playground-jee8.zip, server.log.gz, wfly-12446-heap-dump.png
>
>
> When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g.
> {code}
> One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>".
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12446?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-12446:
-----------------------------------
Thanks @jaikiran for the detailed analysis. @manovotn can you take a look from Weld side, in particular why ejb bean instance holds {{CreationalContextImpl}}, which holds huge list containing thousands of {{org.jboss.weld.contexts.SerializableContextualInstanceImpl}}?
> Memory leak in StatelessSessionComponent
> ----------------------------------------
>
> Key: WFLY-12446
> URL: https://issues.jboss.org/browse/WFLY-12446
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Reporter: Joerg Baesner
> Assignee: Cheng Fang
> Priority: Major
> Attachments: dump.png, playground-jee8.zip, server.log.gz, wfly-12446-heap-dump.png
>
>
> When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g.
> {code}
> One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>".
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFCORE-4656) Write Empty ALLOWED_ORIGINS list could cause IllegalArgumentException on reload
by Chao Wang (Jira)
Chao Wang created WFCORE-4656:
---------------------------------
Summary: Write Empty ALLOWED_ORIGINS list could cause IllegalArgumentException on reload
Key: WFCORE-4656
URL: https://issues.jboss.org/browse/WFCORE-4656
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 10.0.0.Beta6
Reporter: Chao Wang
Assignee: Chao Wang
First add then clear ALLOWED_ORIGINS list cause ConfigurationPersistenceException at next server reload
{noformat}
19:25:17,033 ERROR [org.jboss.as.controller] (Controller Boot Thread)
OPVDX001: Validation error in standalone.xml -----------------------------------
|
| 79: </audit-log>
| 80: <management-interfaces>
| 81: <http-interface security-realm="ManagementRealm" allowed-origins="">
| ^^^^ '' is an invalid value for parameter allowed-origins. Values must have
| a minimum length of 1 characters
|
| 82: <http-upgrade enabled="true"/>
| 83: <socket-binding http="management-http"/>
| 84: </http-interface>
|
| The primary underlying error message was:
| > ParseError at [row,col]:[81,13]
| > Message: "WFLYCTL0113: '' is an invalid value for parameter
| > allowed-origins. Values must have a minimum length of 1 characters"
|
|-------------------------------------------------------------------------------
19:25:17,034 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller@10.0.0.Beta6//org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
at org.jboss.as.server@10.0.0.Beta6//org.jboss.as.server.ServerService.boot(ServerService.java:385)
at org.jboss.as.controller@10.0.0.Beta6//org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
at java.base/java.lang.Thread.run(Thread.java:834)
19:25:17,035 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{noformat}
Because parser doesn't properly parse empty list for configuration like:
{noformat}
<management-interfaces>
<http-interface security-realm="ManagementRealm" allowed-origins="">
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFCORE-4656) Write Empty ALLOWED_ORIGINS list cause ConfigurationPersistenceException on reload
by Chao Wang (Jira)
[ https://issues.jboss.org/browse/WFCORE-4656?page=com.atlassian.jira.plugi... ]
Chao Wang updated WFCORE-4656:
------------------------------
Summary: Write Empty ALLOWED_ORIGINS list cause ConfigurationPersistenceException on reload (was: Write Empty ALLOWED_ORIGINS list could cause IllegalArgumentException on reload)
> Write Empty ALLOWED_ORIGINS list cause ConfigurationPersistenceException on reload
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4656
> URL: https://issues.jboss.org/browse/WFCORE-4656
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 10.0.0.Beta6
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
>
> First add then clear ALLOWED_ORIGINS list cause ConfigurationPersistenceException at next server reload
> {noformat}
> 19:25:17,033 ERROR [org.jboss.as.controller] (Controller Boot Thread)
> OPVDX001: Validation error in standalone.xml -----------------------------------
> |
> | 79: </audit-log>
> | 80: <management-interfaces>
> | 81: <http-interface security-realm="ManagementRealm" allowed-origins="">
> | ^^^^ '' is an invalid value for parameter allowed-origins. Values must have
> | a minimum length of 1 characters
> |
> | 82: <http-upgrade enabled="true"/>
> | 83: <socket-binding http="management-http"/>
> | 84: </http-interface>
> |
> | The primary underlying error message was:
> | > ParseError at [row,col]:[81,13]
> | > Message: "WFLYCTL0113: '' is an invalid value for parameter
> | > allowed-origins. Values must have a minimum length of 1 characters"
> |
> |-------------------------------------------------------------------------------
> 19:25:17,034 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller@10.0.0.Beta6//org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
> at org.jboss.as.server@10.0.0.Beta6//org.jboss.as.server.ServerService.boot(ServerService.java:385)
> at org.jboss.as.controller@10.0.0.Beta6//org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
> at java.base/java.lang.Thread.run(Thread.java:834)
> 19:25:17,035 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {noformat}
> Because parser doesn't properly parse empty list for configuration like:
> {noformat}
> <management-interfaces>
> <http-interface security-realm="ManagementRealm" allowed-origins="">
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12446?page=com.atlassian.jira.plugin... ]
Cheng Fang updated WFLY-12446:
------------------------------
Component/s: CDI / Weld
> Memory leak in StatelessSessionComponent
> ----------------------------------------
>
> Key: WFLY-12446
> URL: https://issues.jboss.org/browse/WFLY-12446
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Reporter: Joerg Baesner
> Assignee: Cheng Fang
> Priority: Major
> Attachments: dump.png, playground-jee8.zip, server.log.gz, wfly-12446-heap-dump.png
>
>
> When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g.
> {code}
> One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>".
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12526) doPrivileged needed for isUserInRole
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-12526:
---------------------------------------
Summary: doPrivileged needed for isUserInRole
Key: WFLY-12526
URL: https://issues.jboss.org/browse/WFLY-12526
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 18.0.0.Final
Currently experiencing the following error: -
{noformat}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.plugins.ClassLoaderLocatorFactory.get")" in code source "(vfs:/content/mydeployment.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader@24d700ba")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294) [wildfly-elytron-security-manager-1.10.0.Final.jar:1.10.0.Final]
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191) [wildfly-elytron-security-manager-1.10.0.Final.jar:1.10.0.Final]
at org.jboss.security.plugins.ClassLoaderLocatorFactory.get(ClassLoaderLocatorFactory.java:51) [picketbox-5.0.3.Final.jar:5.0.3.Final]
at org.jboss.security.plugins.authorization.JBossAuthorizationContext.initializeModules(JBossAuthorizationContext.java:187) [picketbox-5.0.3.Final.jar:5.0.3.Final]
at org.jboss.security.plugins.authorization.JBossAuthorizationContext.authorize(JBossAuthorizationContext.java:141) [picketbox-5.0.3.Final.jar:5.0.3.Final]
at org.jboss.security.plugins.JBossAuthorizationManager.internalAuthorization(JBossAuthorizationManager.java:438) [picketbox-5.0.3.Final.jar:5.0.3.Final]
at org.jboss.security.plugins.JBossAuthorizationManager.authorize(JBossAuthorizationManager.java:115) [picketbox-5.0.3.Final.jar:5.0.3.Final]
at org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasRole(WebAuthorizationHelper.java:201) [picketbox-5.0.3.Final.jar:5.0.3.Final]
at org.wildfly.extension.undertow.security.JbossAuthorizationManager.isUserInRole(JbossAuthorizationManager.java:99)
at io.undertow.servlet.spec.HttpServletRequestImpl.isUserInRole(HttpServletRequestImpl.java:337) [undertow-servlet-2.0.26.Final.jar:2.0.26.Final]
at org.apache.jsp.secured_jsp._jspService(secured_jsp.java:109)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) [jastow-2.0.7.Final.jar:2.0.7.Final]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:590) [jboss-servlet-api_4.0_spec-2.0.0.CR2.jar:2.0.0.CR2]
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) [jastow-2.0.7.Final.jar:2.0.7.Final]
... 51 more
{noformat}
The reason I believe this requires a doPrivileged is the permission required is entirely internal to our implementation of isUserInRole - whilst the deployment can trigger this call the deployment can not influence how this is implemented so the deployment's ProtectionDomain should not require the permissions needed for our internal class loading so a doPrivileged call will drop the deployment's ProtectionDomain from the stack.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2327?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2327:
---------------------------
Description:
* A and B
* B sends 2 messages to A: B1 and B2
* A receives B2 _before_ B1 (both B1 and B2 are OOB)
* The current code has A drop B2 and B1 and send a SEND_FIRST_SEQNO message to B
* B resends B1, but _not_ B2
* Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
h4. Scenario (JGRP-2293):
* A installs a new view
* B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
* The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
* This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
h4. Workaround
* Set GMS.leave_timeout to a higher value (say 8000ms)
h4. Solution
* When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
* However, this requires the first seqno from B *to always be 0*
--> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
was:
* A and B
* B sends 2 messages to A: B1 and B2
* A receives B2 _before_ B1 (both B1 and B2 are OOB)
* The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
* B resends B1, but _not_ B2
* Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
h4. Scenario (JGRP-2293):
* A installs a new view
* B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
* The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
* This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
h4. Workaround
* Set GMS.leave_timeout to a higher value (say 8000ms)
h4. Solution
* When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
* However, this requires the first seqno from B *to always be 0*
--> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
> UNICAST3: create receiver table when non-first message is received first
> ------------------------------------------------------------------------
>
> Key: JGRP-2327
> URL: https://issues.jboss.org/browse/JGRP-2327
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.5
>
>
> * A and B
> * B sends 2 messages to A: B1 and B2
> * A receives B2 _before_ B1 (both B1 and B2 are OOB)
> * The current code has A drop B2 and B1 and send a SEND_FIRST_SEQNO message to B
> * B resends B1, but _not_ B2
> * Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
> h4. Scenario (JGRP-2293):
> * A installs a new view
> * B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
> * The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
> * This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
> h4. Workaround
> * Set GMS.leave_timeout to a higher value (say 8000ms)
> h4. Solution
> * When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
> * However, this requires the first seqno from B *to always be 0*
> --> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12468) Rename BOMs artifactIds with javaee8-* to jakartaee8-*
by Marek Kopecky (Jira)
[ https://issues.jboss.org/browse/WFLY-12468?page=com.atlassian.jira.plugin... ]
Marek Kopecky commented on WFLY-12468:
--------------------------------------
[~emmartins] (cc [~smarlow]): Do you plan to have two variants of clients bom? For example, something like "wildfly-ejb-client-bom" for JavaEE artifacts and "wildfly-ejb-client-jakarta-bom" for JakartaEE artifacts?
> Rename BOMs artifactIds with javaee8-* to jakartaee8-*
> ------------------------------------------------------
>
> Key: WFLY-12468
> URL: https://issues.jboss.org/browse/WFLY-12468
> Project: WildFly
> Issue Type: Sub-task
> Components: BOM, Quickstarts
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
> Priority: Major
>
> The following WildFly BOM artifactIds should be renamed to not include javaee, replacing it with jakartaee8:
> * wildfly-javaee8
> * wildfly-javaee8-with-tools
> Same should be done to the jboss javaee BOMs at https://github.com/jboss/jboss-javaee-specs, what should probably first be forked due to including javaee in its name too (to jboss/jboss-jakartaee-specs?).
> Reference to renamed BOMs in Quickstarts project should also be updated.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months