-
Bug
-
Resolution: Done
-
Critical
-
1.1.4.Final
-
None
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
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*);
and for removing the entire file path:
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()*);
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.
String xidString = filePath.toString().substring(filePath.toString().indexOf(
xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1);
openFilePaths.remove(xidString);
- clones
-
-
- Closed
-
