servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zheng Feng <zh.f...@gmail.com>
Subject Re: [Saga] About Omega's timeout process
Date Thu, 25 Apr 2019 07:57:22 GMT
I'm not sure if the Thread.interrupt() could be working as you expect. From
the Java doc [1]

Unless the current thread is interrupting itself, which is always
permitted, the checkAccess method of this thread is invoked, which may
cause a SecurityException to be thrown.

   - If this thread is blocked in an invocation of the wait(), wait(long),
   or wait(long, int) methods of the Object class, or of the join(),
   join(long), join(long, int), sleep(long), or sleep(long, int), methods of
   this class, then its interrupt status will be cleared and it will receive
   an InterruptedException.


   - If this thread is blocked in an I/O operation upon an interruptible
   channel then the channel will be closed, the thread's interrupt status will
   be set, and the thread will receive a ClosedByInterruptException.


   - If this thread is blocked in a Selector then the thread's interrupt
   status will be set and it will return immediately from the selection
   operation, possibly with a non-zero value, just as if the selector's wakeup
   method were invoked.


   - If none of the previous conditions hold then this thread's interrupt
   status will be set.


   - Interrupting a thread that is not alive need not have any effect.


So I think we have to catch the SecurityException when the thread is  can
not been interrupted. Also ClosedByInterruptException could be thrown if
the thread is doing some I/O operations especially by the socket. Anyway,
we could understand the interrupt() could be no effect in some cases, e.g.
if the thread is busy with the CPU times, just while(true);

I think we had similar timeout handling before but removed it at [2] and
the SCB-239 [3]. I can recall that we store the timeout setting in the
alpha side rather than the omega side just because the alpha can persistent
into the back end database and could resume the compensate operations when
recovery from the crash scenario or the omega side is failed.

Thanks,
Zheng Feng

[1]
https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt()
[2]
https://github.com/apache/servicecomb-pack/commit/46096fe2f0f0d3d03fb256ed2fd5f221c0b9e851
[3] https://issues.apache.org/jira/browse/SCB-239

Zhang Lei <zhang_lei@boco.com.cn> 于2019年4月24日周三 下午7:09写道:

> At present, Omega's timeout only stores to the database, find timeout Tx
> transactions and compensation through database scans. This may cause the
> commit of the Tx transaction after the compensation.
> I think it can be improved TransactionAspect class, Terminates the
> execution of the method when the timeout and throws a custom exception
>
> So we can control the rollback of the transaction within the method when
> timeout. I wrote an example to show my thoughts
> https://github.com/coolbeevip/playground/tree/master/timeoutaspect-demo <
> https://github.com/coolbeevip/playground/tree/master/timeoutaspect-demo>
>
> You can use ApplicationTest to quickly verify
>
> Any suggestion?
>
>
> Lei Zhang

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message