[jboss-jira] [JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client

[Cheng Fang (Jira)]

    [ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13752287#comment-13752287 ] 

Cheng Fang edited comment on WFLY-12031 at 6/26/19 10:42 AM:
-------------------------------------------------------------

[~petrjoac] could you try running with the latest wildfly-transaction-client [1.1.4.Final|https://github.com/wildfly/wildfly-transaction-client/releases/tag/1.1.4.Final], and see if that fixes the issue?  If not, then we will need to apply the proposed fix on [2019-04-30|https://issues.jboss.org/browse/WFLY-12031?focusedCommentId=13728380&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13728380] in next release (maybe 1.1.5.Final).  So either way, I think it's helpful to try out wildfly-transaction-client 1.1.4.Final


was (Author: cfang):
[~petrjoac] could you try running with the latest wildfly-transaction-client [1.1.4.Final|https://github.com/wildfly/wildfly-transaction-client/releases/tag/1.1.4.Final], and see if that fixes the issue?  If not, then we will need to apply the proposed fix on [2019-04-30|https://issues.jboss.org/browse/WFLY-12031?focusedCommentId=13728380&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13728380] on top of 1.1.4.Final.  So either way, I think it's helpful to try out wildfly-transaction-client 1.1.4.Final

> Memory leak in wildfly transaction client
> -----------------------------------------
>
>                 Key: WFLY-12031
>                 URL: https://issues.jboss.org/browse/WFLY-12031
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 15.0.1.Final
>         Environment: wildfly-transaction-client-1.1.3.Final
> wildfly.15.0.1.Final
> Windows 10
>            Reporter: Joachim Petrich
>            Assignee: Cheng Fang
>            Priority: Critical
>
> After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used
> {code:java}
>         XAResourceRegistryFile(Xid xid) throws SystemException {
>             xaRecoveryPath.toFile().mkdir(); // create dir if non existent
>             final String xidString = SimpleXid.of(xid).toHexString('_');
>             this.filePath = xaRecoveryPath.resolve(xidString);
>             openFilePaths.add(*xidString*);
> {code}
> and for removing the entire file path:
> {code:java}
>         protected void removeResource(XAResource resource) throws XAException {
>             if (resources.remove(resource)) {
>                 if (resources.isEmpty()) {
>                     // delete file
>                     try {
>                         if (fileChannel != null) {
>                             fileChannel.close();
>                         }
>                         Files.delete(filePath);
>                         // deleting using the filepath as key caused a memory leak,
>                         // if xid string have been added, therefore build the xid string for removing
>                         openFilePaths.remove(*filePath.toString()*);
>  {code}
> We didn't find any code where this xid are cleaned up.
> As workaround we additionally extract the xid String from the file path and remove the corresponding entry.
> {code:java}
>                         String xidString = filePath.toString().substring(filePath.toString().indexOf(
>                         		xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1);
>                         openFilePaths.remove(xidString);
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)