XADisk unavailable after one application thread is interrupted

[Peter Beno]

Hi Nitin,

we are facing the problem of broken transaction log after one thread is interrupted in application. Project is using xadisk via local jca resource adapter participating xa transaction. It is serious problem that one transaction can stop whole xadisk instance by corruption of it's transaction log. And so broke up the whole application until restart and some clean ups. I have read discussion in issue https://java.net/jira/browse/XADISK-138, however I have failed to use xadisk remotely on wildfly 8.1(8.2) on windows os. All connections was frozen early in getConnection call.I have seen socket connection to port 9999 from app threads but no messages in log no activity until timeout. Using weblogic 12 I have successfully connected but I have got strange errors about permission and problems acquiring lock by xadisks native file-system subsystem (or how you call it), even if local adapter worked correctly under same xadisk instance.

I have tried also to decouple the xadisk call to new synchronized thread ignoring interrupts, in local connection, but I was not able to propagate container managed transaction context to that thread declaratively. So this approach was also not usable, because change of the application transaction management from declarative to programmatic is not acceptable.

Are working on some fix which allow xadisk work correctly with interrupt or at least recover the transaction log in interrupted thread not to stop/break up whole xadisk instance?

Can you give me also some hints what could be wrong with my test of remote connection. In jboss I have no idea how to check problem of frozen connection without any logged message and in weblogic I have following exceptions. Strange is that it is really non-deterministic,
sometimes I have got first and other times second.

Exception in thread "main" org.xadisk.filesystem.exceptions.InsufficientPermissionOnFileException: Permission of type [WRITE_FILE] is needed over the file/directory with path [c:\xadisk\test\storage\test.txt] for the i/o operation to succeed.
    at org.xadisk.filesystem.NativeSession.checkPermission(NativeSession.java:1157)
    at org.xadisk.filesystem.NativeSession.createXAFileOutputStream(NativeSession.java:191)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.xadisk.bridge.server.conversation.RemoteMethodInvocationHandler.handleRemoteInvocation(RemoteMethodInvocationHandler.java:145)
    at org.xadisk.bridge.server.conversation.RemoteMethodInvocationHandler.run(RemoteMethodInvocationHandler.java:67)
    at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:70)
    at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:45)
    at weblogic.connector.work.WorkRequest.run(WorkRequest.java:123)
    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)

   
Exception in thread "main" org.xadisk.filesystem.exceptions.LockingTimedOutException: A lock required over the file/directory [c:\xadisk\test\storage\test.txt], which was required for the operation, could not be acquired. The reason is : An attempt to acquire the lock has timed-out.
    at org.xadisk.filesystem.NativeConcurrencyControl.acquireExclusiveLock(NativeConcurrencyControl.java:165)
    at org.xadisk.filesystem.NativeConcurrencyControl.acquireFileLock(NativeConcurrencyControl.java:49)
    at org.xadisk.filesystem.NativeSession.acquireLockIfRequired(NativeSession.java:1165)
    at org.xadisk.filesystem.NativeSession.createXAFileOutputStream(NativeSession.java:190)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.xadisk.bridge.server.conversation.RemoteMethodInvocationHandler.handleRemoteInvocation(RemoteMethodInvocationHandler.java:145)
    at org.xadisk.bridge.server.conversation.RemoteMethodInvocationHandler.run(RemoteMethodInvocationHandler.java:67)
    at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:70)
    at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:45)
    at weblogic.connector.work.WorkRequest.run(WorkRequest.java:123)
    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
   

   
Thanks,
Peter

[Nitin Verma]

Hi Peter,

At present, I do not have a fix for the problem of threads being interrupted; though, as updated by Gunnar in jira issue #138, you may want to look at his fix and see if it suits you. Unfortunately, I haven't yet re-visited that issue till now, and couldn't review the fix sent by Gunnar. You may want to start a discussion with him directly. In the next few days, I will also try to review his fix and will let you know in this discussion thread. Thanks for bringing up the problem.

Now coming to remote connections. I will need a bit more descriptions on each of the 2-3 problems which you mentioned. The two exceptions must be having some valid reason, we need to find that. And to keep this discussion (for thread interruption) clean, we can also discuss them on a separate discussion thread. Please do so; pick one of those problems and give more details with the test-case code/conditions etc.

Thanks,
Nitin