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

Cheng Fang (Jira) issues at jboss.org
Tue Apr 30 12:54:00 EDT 2019


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

Cheng Fang commented on WFLY-12031:
-----------------------------------

When adding to {{openFilePaths}} set, the file name part (the last element in the path) is used.  So when removing it, we should also use the file name part of the path {{filePath}}.

I think changing the remove line to the following should work:

{code:java}
openFilePaths.remove(filePath.getFileName().toString());
{code}

/cc [~flavia.rainone]

> 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
> Window 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)


More information about the jboss-jira mailing list