You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicecomb.apache.org by Zhang Lei <zh...@boco.com.cn> on 2019/04/24 11:09:14 UTC
[Saga] About Omega's timeout process
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
Re: [Saga] About Omega's timeout process
Posted by zhang_lei <zh...@boco.com.cn>.
Oh, I haven’t been able to simulate my guess.发送自我的三星盖乐世智能手机。
-------- 原始信息 --------由： Zheng Feng <zh...@gmail.com> 日期: 2019/4/26 18:52 (GMT+08:00) 收件人： dev@servicecomb.apache.org 主题： Re: [Saga] About Omega's timeout process Why does this happen I mean that Thread.interrupt causes the ThreadLocalvariables lost the value ? It should be running in the same thread. Also itdoes not mention in the Java API docs [1].I do agree that the compensate method could have this issue since it hasbeen invoking in the different thread. But for the Zhang Lei's proposal forthe timeout solution, I don't think this could happen or maybe Imisunderstand something else.Regards,Zheng Feng[1]https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt()Willem Jiang <wi...@gmail.com> 于2019年4月26日周五 下午6:41写道：> Yeah, that's exactly what want to say.>> Willem Jiang>> Twitter: willemjiang> Weibo: 姜宁willem>> On Fri, Apr 26, 2019 at 4:14 PM Zhang Lei <zh...@boco.com.cn> wrote:> >> > Hi, Willem Jiang> >> > You mean that Thread.interrupt will cause the variables in the thread to> be lost, so we need to provide a way for the user to restore the thread> variables?> >> > Lei Zhang> >> > > 在 2019年4月26日，上午8:36，Willem Jiang <wi...@gmail.com> 写道：> > >> > > We could introduce a Context object to let the user copy the thread> > > local variable across the thread.> > > The context can be inject into the method which is annotated with> > > Compasiable. We may need to inject the Context object into the remote> > > service caller.> >>
Re: [Saga] About Omega's timeout process
Posted by Zheng Feng <zh...@gmail.com>.
Why does this happen I mean that Thread.interrupt causes the ThreadLocal
variables lost the value ? It should be running in the same thread. Also it
does not mention in the Java API docs [1].
I do agree that the compensate method could have this issue since it has
been invoking in the different thread. But for the Zhang Lei's proposal for
the timeout solution, I don't think this could happen or maybe I
misunderstand something else.
Regards,
Zheng Feng
[1]
https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt()
Willem Jiang <wi...@gmail.com> 于2019年4月26日周五 下午6:41写道：
> Yeah, that's exactly what want to say.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Apr 26, 2019 at 4:14 PM Zhang Lei <zh...@boco.com.cn> wrote:
> >
> > Hi, Willem Jiang
> >
> > You mean that Thread.interrupt will cause the variables in the thread to
> be lost, so we need to provide a way for the user to restore the thread
> variables?
> >
> > Lei Zhang
> >
> > > 在 2019年4月26日，上午8:36，Willem Jiang <wi...@gmail.com> 写道：
> > >
> > > We could introduce a Context object to let the user copy the thread
> > > local variable across the thread.
> > > The context can be inject into the method which is annotated with
> > > Compasiable. We may need to inject the Context object into the remote
> > > service caller.
> >
>
Re: [Saga] About Omega's timeout process
Posted by Willem Jiang <wi...@gmail.com>.
Yeah, that's exactly what want to say.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Apr 26, 2019 at 4:14 PM Zhang Lei <zh...@boco.com.cn> wrote:
>
> Hi, Willem Jiang
>
> You mean that Thread.interrupt will cause the variables in the thread to be lost, so we need to provide a way for the user to restore the thread variables?
>
> Lei Zhang
>
> > 在 2019年4月26日，上午8:36，Willem Jiang <wi...@gmail.com> 写道：
> >
> > We could introduce a Context object to let the user copy the thread
> > local variable across the thread.
> > The context can be inject into the method which is annotated with
> > Compasiable. We may need to inject the Context object into the remote
> > service caller.
>
Re: [Saga] About Omega's timeout process
Posted by Zhang Lei <zh...@boco.com.cn>.
Hi, Willem Jiang
You mean that Thread.interrupt will cause the variables in the thread to be lost, so we need to provide a way for the user to restore the thread variables?
Lei Zhang
> 在 2019年4月26日，上午8:36，Willem Jiang <wi...@gmail.com> 写道：
>
> We could introduce a Context object to let the user copy the thread
> local variable across the thread.
> The context can be inject into the method which is annotated with
> Compasiable. We may need to inject the Context object into the remote
> service caller.
Re: [Saga] About Omega's timeout process
Posted by Willem Jiang <wi...@gmail.com>.
We could introduce a Context object to let the user copy the thread
local variable across the thread.
The context can be inject into the method which is annotated with
Compasiable. We may need to inject the Context object into the remote
service caller.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Apr 25, 2019 at 3:59 PM Zheng Feng <zh...@gmail.com> wrote:
>
> Hi Willem,
>
> Can you explain more clear ? I can not understand why we need this API and
> how it could be used for passing the ThreadLocal variables ?
>
> Thanks,
> Zheng Feng
>
> Willem Jiang <wi...@gmail.com> 于2019年4月25日周四 下午2:34写道：
>
> > What I mean is if the user using the ThreadLocal variable to store the
> > classloader or security token, we need to have an API to let the user
> > pass these kind of information into the calling thread.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Apr 25, 2019 at 10:14 AM Zhang Lei <zh...@boco.com.cn> wrote:
> > >
> > > In my example, I defined a runtime exception TimeoutAspectException,
> > user can know that a timeout has occurred when catching the exception
> > >
> > > The following unit test case tested a custom exception
> > TimeoutAspectException
> > >
> > > @Test(expected = TimeoutAspectException.class)
> > > public void timeoutCatchTimeoutAspectExceptionTest() throws
> > TimeoutAspectException {
> > > List<User> users = new ArrayList<>();
> > > users.add(User.builder().id(1).name("zhanglei").build());
> > > myService.save(users, 3000);
> > > }
> > >
> > > Lei Zhang
> > >
> > >
> > > > 在 2019年4月24日，下午10:16，Willem Jiang <wi...@gmail.com> 写道：
> > > >
> > > > As the calling thread is change, we need to tell the user about it.
> > >
> >
Re: [Saga] About Omega's timeout process
Posted by Zheng Feng <zh...@gmail.com>.
Hi Willem,
Can you explain more clear ? I can not understand why we need this API and
how it could be used for passing the ThreadLocal variables ?
Thanks,
Zheng Feng
Willem Jiang <wi...@gmail.com> 于2019年4月25日周四 下午2:34写道：
> What I mean is if the user using the ThreadLocal variable to store the
> classloader or security token, we need to have an API to let the user
> pass these kind of information into the calling thread.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Apr 25, 2019 at 10:14 AM Zhang Lei <zh...@boco.com.cn> wrote:
> >
> > In my example, I defined a runtime exception TimeoutAspectException,
> user can know that a timeout has occurred when catching the exception
> >
> > The following unit test case tested a custom exception
> TimeoutAspectException
> >
> > @Test(expected = TimeoutAspectException.class)
> > public void timeoutCatchTimeoutAspectExceptionTest() throws
> TimeoutAspectException {
> > List<User> users = new ArrayList<>();
> > users.add(User.builder().id(1).name("zhanglei").build());
> > myService.save(users, 3000);
> > }
> >
> > Lei Zhang
> >
> >
> > > 在 2019年4月24日，下午10:16，Willem Jiang <wi...@gmail.com> 写道：
> > >
> > > As the calling thread is change, we need to tell the user about it.
> >
>
Re: [Saga] About Omega's timeout process
Posted by Willem Jiang <wi...@gmail.com>.
What I mean is if the user using the ThreadLocal variable to store the
classloader or security token, we need to have an API to let the user
pass these kind of information into the calling thread.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Apr 25, 2019 at 10:14 AM Zhang Lei <zh...@boco.com.cn> wrote:
>
> In my example, I defined a runtime exception TimeoutAspectException, user can know that a timeout has occurred when catching the exception
>
> The following unit test case tested a custom exception TimeoutAspectException
>
> @Test(expected = TimeoutAspectException.class)
> public void timeoutCatchTimeoutAspectExceptionTest() throws TimeoutAspectException {
> List<User> users = new ArrayList<>();
> users.add(User.builder().id(1).name("zhanglei").build());
> myService.save(users, 3000);
> }
>
> Lei Zhang
>
>
> > 在 2019年4月24日，下午10:16，Willem Jiang <wi...@gmail.com> 写道：
> >
> > As the calling thread is change, we need to tell the user about it.
>
Re: [Saga] About Omega's timeout process
Posted by Zhang Lei <zh...@boco.com.cn>.
In my example, I defined a runtime exception TimeoutAspectException, user can know that a timeout has occurred when catching the exception
The following unit test case tested a custom exception TimeoutAspectException
@Test(expected = TimeoutAspectException.class)
public void timeoutCatchTimeoutAspectExceptionTest() throws TimeoutAspectException {
List<User> users = new ArrayList<>();
users.add(User.builder().id(1).name("zhanglei").build());
myService.save(users, 3000);
}
Lei Zhang
> 在 2019年4月24日，下午10:16，Willem Jiang <wi...@gmail.com> 写道：
>
> As the calling thread is change, we need to tell the user about it.
Re: [Saga] About Omega's timeout process
Posted by Willem Jiang <wi...@gmail.com>.
Yeah， I think it's a good start.
In this way we could let the SagaStarter and LocalTransaction
excecutor knows about the timeout.
As the calling thread is change, we need to tell the user about it.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Wed, Apr 24, 2019 at 7:09 PM Zhang Lei <zh...@boco.com.cn> wrote:
>
> 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
Re: [Saga] About Omega's timeout process
Posted by Zheng Feng <zh...@gmail.com>.
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 <zh...@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