[JBoss JIRA] (WFLY-12032) Follow-up: java.rmi is not visible from wildfly.extension.io module
by Tomas Hofman (Jira)
[ https://issues.jboss.org/browse/WFLY-12032?page=com.atlassian.jira.plugin... ]
Tomas Hofman updated WFLY-12032:
--------------------------------
Summary: Follow-up: java.rmi is not visible from wildfly.extension.io module (was: java.rmi is not visible from wildfly.extension.io module)
> Follow-up: java.rmi is not visible from wildfly.extension.io module
> -------------------------------------------------------------------
>
> Key: WFLY-12032
> URL: https://issues.jboss.org/browse/WFLY-12032
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 16.0.0.Final
> Reporter: Tomas Hofman
> Priority: Major
>
> This is follow up issue for JBEAP-16725, which was resolved with a workaround - javax.rmi was added as a dependency of wildfly.extension.io module.
> The root cause is probably inside jboss-modules.
> The issue is following:
> * a standalone EJB client invokes remote EJB, and passes an object as an argument;
> * server (trying to use the remote object) fails with "java.lang.ClassNotFoundException: java.rmi.dgc.Lease" (stacktrace bellow).
> If a short delay ({{Thread.sleep(100)}}) is introduced on the server side, before manipulating the remote object, the invocation succeeds.
> {code}
> java.lang.ClassNotFoundException: java.rmi.dgc.Lease from [Module "org.wildfly.extension.io" version 6.0.12.Final-redhat-00001 from local module loader @6a024a67 (finder: local module finder @7921b0a2 (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base))] (no security manager: RMI class loader disabled)
> (default task-2) java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:97)
> (default task-2) sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:396)
> (default task-2) sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186)
> (default task-2) java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637)
> (default task-2) java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:264)
> (default task-2) sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:219)
> (default task-2) java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1868)
> (default task-2) java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751)
> (default task-2) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2042)
> (default task-2) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
> (default task-2) java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
> (default task-2) sun.rmi.transport.DGCImpl_Stub.dirty(DGCImpl_Stub.java:125)
> (default task-2) sun.rmi.transport.DGCClient$EndpointEntry.makeDirtyCall(DGCClient.java:382)
> (default task-2) sun.rmi.transport.DGCClient$EndpointEntry.registerRefs(DGCClient.java:324)
> (default task-2) sun.rmi.transport.DGCClient.registerRefs(DGCClient.java:160)
> (default task-2) sun.rmi.transport.LiveRef.read(LiveRef.java:312)
> (default task-2) sun.rmi.server.UnicastRef.readExternal(UnicastRef.java:489)
> (default task-2) java.rmi.server.RemoteObject.readObject(RemoteObject.java:455)
> (default task-2) sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2)
> (default task-2) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> (default task-2) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> (default task-2) java.lang.reflect.Method.invoke(Method.java:498)
> (default task-2) org.jboss.marshalling.reflect.JDKSpecific$SerMethods.callReadObject(JDKSpecific.java:179)
> (default task-2) org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:212)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1746)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1715)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1715)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1395)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
> (default task-2) org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> (default task-2) org.jboss.ejb.protocol.remote.EJBServerChannel$RemotingInvocationRequest.getRequestContent(EJBServerChannel.java:813)
> (default task-2) org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:130)
> (default task-2) org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleInvocationRequest(EJBServerChannel.java:451)
> (default task-2) org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleMessage(EJBServerChannel.java:189)
> (default task-2) org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> (default task-2) org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:949)
> (default task-2) org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> (default task-2) org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> (default task-2) org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> (default task-2) org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> (default task-2) java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12033) Follow-up: java.rmi is not visible from wildfly.extension.io module
by Tomas Hofman (Jira)
Tomas Hofman created WFLY-12033:
-----------------------------------
Summary: Follow-up: java.rmi is not visible from wildfly.extension.io module
Key: WFLY-12033
URL: https://issues.jboss.org/browse/WFLY-12033
Project: WildFly
Issue Type: Bug
Affects Versions: 16.0.0.Final
Reporter: Tomas Hofman
This is follow up issue for JBEAP-16725, which was resolved with a workaround - javax.rmi was added as a dependency of wildfly.extension.io module.
The root cause is probably inside jboss-modules.
The issue is following:
* a standalone EJB client invokes remote EJB, and passes an object as an argument;
* server (trying to use the remote object) fails with "java.lang.ClassNotFoundException: java.rmi.dgc.Lease" (stacktrace bellow).
If a short delay ({{Thread.sleep(100)}}) is introduced on the server side, before manipulating the remote object, the invocation succeeds.
{code}
java.lang.ClassNotFoundException: java.rmi.dgc.Lease from [Module "org.wildfly.extension.io" version 6.0.12.Final-redhat-00001 from local module loader @6a024a67 (finder: local module finder @7921b0a2 (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base))] (no security manager: RMI class loader disabled)
(default task-2) java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:97)
(default task-2) sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:396)
(default task-2) sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186)
(default task-2) java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637)
(default task-2) java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:264)
(default task-2) sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:219)
(default task-2) java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1868)
(default task-2) java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751)
(default task-2) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2042)
(default task-2) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
(default task-2) java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
(default task-2) sun.rmi.transport.DGCImpl_Stub.dirty(DGCImpl_Stub.java:125)
(default task-2) sun.rmi.transport.DGCClient$EndpointEntry.makeDirtyCall(DGCClient.java:382)
(default task-2) sun.rmi.transport.DGCClient$EndpointEntry.registerRefs(DGCClient.java:324)
(default task-2) sun.rmi.transport.DGCClient.registerRefs(DGCClient.java:160)
(default task-2) sun.rmi.transport.LiveRef.read(LiveRef.java:312)
(default task-2) sun.rmi.server.UnicastRef.readExternal(UnicastRef.java:489)
(default task-2) java.rmi.server.RemoteObject.readObject(RemoteObject.java:455)
(default task-2) sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2)
(default task-2) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
(default task-2) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
(default task-2) java.lang.reflect.Method.invoke(Method.java:498)
(default task-2) org.jboss.marshalling.reflect.JDKSpecific$SerMethods.callReadObject(JDKSpecific.java:179)
(default task-2) org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:212)
(default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1746)
(default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1715)
(default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1715)
(default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1395)
(default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
(default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
(default task-2) org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
(default task-2) org.jboss.ejb.protocol.remote.EJBServerChannel$RemotingInvocationRequest.getRequestContent(EJBServerChannel.java:813)
(default task-2) org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:130)
(default task-2) org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleInvocationRequest(EJBServerChannel.java:451)
(default task-2) org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleMessage(EJBServerChannel.java:189)
(default task-2) org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
(default task-2) org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:949)
(default task-2) org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
(default task-2) org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
(default task-2) org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
(default task-2) org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
(default task-2) java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12032) java.rmi is not visible from wildfly.extension.io module
by David Lloyd (Jira)
[ https://issues.jboss.org/browse/WFLY-12032?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFLY-12032:
------------------------------------
Sure, it is related to class loading, but that's a very broad area with impacts in many systems and doesn't always mean it's a problem with JBoss Modules. In particular JBoss Modules is not sensitive to time delays, as its class loading algorithm is generally deterministic. In this case I'd look at how RMI is maintaining its resolution cache; perhaps the cache is not updated until after the entire message is deserialized.
> java.rmi is not visible from wildfly.extension.io module
> --------------------------------------------------------
>
> Key: WFLY-12032
> URL: https://issues.jboss.org/browse/WFLY-12032
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 16.0.0.Final
> Reporter: Tomas Hofman
> Priority: Major
>
> This is follow up issue for JBEAP-16725, which was resolved with a workaround - javax.rmi was added as a dependency of wildfly.extension.io module.
> The root cause is probably inside jboss-modules.
> The issue is following:
> * a standalone EJB client invokes remote EJB, and passes an object as an argument;
> * server (trying to use the remote object) fails with "java.lang.ClassNotFoundException: java.rmi.dgc.Lease" (stacktrace bellow).
> If a short delay ({{Thread.sleep(100)}}) is introduced on the server side, before manipulating the remote object, the invocation succeeds.
> {code}
> java.lang.ClassNotFoundException: java.rmi.dgc.Lease from [Module "org.wildfly.extension.io" version 6.0.12.Final-redhat-00001 from local module loader @6a024a67 (finder: local module finder @7921b0a2 (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base))] (no security manager: RMI class loader disabled)
> (default task-2) java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:97)
> (default task-2) sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:396)
> (default task-2) sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186)
> (default task-2) java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637)
> (default task-2) java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:264)
> (default task-2) sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:219)
> (default task-2) java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1868)
> (default task-2) java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751)
> (default task-2) java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2042)
> (default task-2) java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
> (default task-2) java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
> (default task-2) sun.rmi.transport.DGCImpl_Stub.dirty(DGCImpl_Stub.java:125)
> (default task-2) sun.rmi.transport.DGCClient$EndpointEntry.makeDirtyCall(DGCClient.java:382)
> (default task-2) sun.rmi.transport.DGCClient$EndpointEntry.registerRefs(DGCClient.java:324)
> (default task-2) sun.rmi.transport.DGCClient.registerRefs(DGCClient.java:160)
> (default task-2) sun.rmi.transport.LiveRef.read(LiveRef.java:312)
> (default task-2) sun.rmi.server.UnicastRef.readExternal(UnicastRef.java:489)
> (default task-2) java.rmi.server.RemoteObject.readObject(RemoteObject.java:455)
> (default task-2) sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2)
> (default task-2) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> (default task-2) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> (default task-2) java.lang.reflect.Method.invoke(Method.java:498)
> (default task-2) org.jboss.marshalling.reflect.JDKSpecific$SerMethods.callReadObject(JDKSpecific.java:179)
> (default task-2) org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:212)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1746)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1715)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1715)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1395)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> (default task-2) org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
> (default task-2) org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> (default task-2) org.jboss.ejb.protocol.remote.EJBServerChannel$RemotingInvocationRequest.getRequestContent(EJBServerChannel.java:813)
> (default task-2) org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:130)
> (default task-2) org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleInvocationRequest(EJBServerChannel.java:451)
> (default task-2) org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleMessage(EJBServerChannel.java:189)
> (default task-2) org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> (default task-2) org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:949)
> (default task-2) org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> (default task-2) org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> (default task-2) org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> (default task-2) org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> (default task-2) java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3949) "Diagram properties" is empty, if you'll go to Business Central you'll get error
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3949?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3949:
-----------------------------------
Sprint: 2019 Week 17-19
> "Diagram properties" is empty, if you'll go to Business Central you'll get error
> --------------------------------------------------------------------------------
>
> Key: DROOLS-3949
> URL: https://issues.jboss.org/browse/DROOLS-3949
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.21.0.Final
> Reporter: Yevgeniy Fomin
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: Stunner, drools-tools
> Attachments: Error.jpeg, Screenshot from 2019-04-29 15-22-18.png
>
>
> The "Diagram properties" is empty in any step of creation diagram(see attach), also you will receive an error after attempting to click on "Business Central" after using "Diagram properties".
> Please notice the issue affects also Business Processes. If user create new business process, the diagram properties panel is always empty.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson reassigned WFLY-12031:
---------------------------------------
Assignee: Cheng Fang (was: Thomas Jenkinson)
> 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
> 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);
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson commented on WFLY-12031:
-----------------------------------------
/cc [~tomekadamski]
> 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
> 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);
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3899) Submarine Jenkins fails the Quarkus REST test, using Quarkus >0.12
by Tibor Zimanyi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3899?page=com.atlassian.jira.plugi... ]
Tibor Zimanyi commented on DROOLS-3899:
---------------------------------------
Done, thanks.
> Submarine Jenkins fails the Quarkus REST test, using Quarkus >0.12
> ------------------------------------------------------------------
>
> Key: DROOLS-3899
> URL: https://issues.jboss.org/browse/DROOLS-3899
> Project: Drools
> Issue Type: Bug
> Affects Versions: 8.0.0.Final
> Reporter: Matteo Mortari
> Assignee: Tibor Zimanyi
> Priority: Major
> Labels: submarine
> Fix For: 8.0.0.Final
>
>
> -runtimes PR fails to run -example REST Quarkus test, when Quarkus version >0.12
> As demonstrated by history of Jenkins runs of this PR:
> https://github.com/kiegroup/submarine-runtimes/pull/26
> which as part of CI will also run this:
> https://github.com/kiegroup/submarine-examples/pull/15
> Error was:
> [ERROR] testGET Time elapsed: 0.007 s <<< ERROR!
> org.junit.jupiter.api.extension.TestInstantiationException: TestInstanceFactory [io.quarkus.test.junit.QuarkusTestExtension] failed to instantiate test class [org.kie.dmn.submarine.quarkus.example.ByNameDMNEndpointTest]: Failed to create the boostrap class loader
> Caused by: java.lang.IllegalStateException: Failed to create the boostrap class loader
> Caused by: io.quarkus.bootstrap.BootstrapException: Failed to locate current project among the loaded local projects
> Please notice especially the last line.
> I had the same problem locally with 0.13.1, but that was fixed locally with 0.13.3
> But trying with 0.13.3 keep failing on Jenkins CI when running -runtimes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months