Hi Willem,
thanks for the update.
The maturity model assessment draft looks overall good to me.
I will add the resolution proposal draft on the wiki as well.
Regards
JB
On 15/08/2018 11:09, Willem Jiang wrote:
> With the ServiceComb java-chassis 1.0.0-incubating and service-center
>
We cannot guarantee to update the redis and DB at the same time, we can
just do the retry in our code.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Aug 16, 2018 at 10:29 AM, fu chengeng wrote:
> Hi Willem
> why not just store 'finished transacation' data to db in a async
Hi Willem
why not just store 'finished transacation' data to db in a async way.can we
guarantee update on both
db and redis are success at same time when the transation is aborted?
发件人: Willem Jiang
发送时间: 8月16日星期四 09:40
主题: Re: Performance tuning of ServiceComb Saga Pack
收件人:
Thanksk Willem, it looks like the redis cluster is the better choice.
2018-08-16 9:57 GMT+08:00 Lance Ju :
> Here is an abstracted design of how redis works:
> https://raw.githubusercontent.com/crystaldust/saga-
> performance-optimization/master/saga-redis.jpg
>
> Willem Jiang 于2018年8月16日周四
Sure, I'll reply the emails in the other mailing list.
Willem Jiang 于2018年8月15日周三 下午8:44写道：
> Hi Lance,
>
> I already already introduced the background of performance tuning here[1].
> We could improve the performance by leverage the redis cache without
> looking up the events with the complex
Here is an abstracted design of how redis works:
https://raw.githubusercontent.com/crystaldust/saga-performance-optimization/master/saga-redis.jpg
Willem Jiang 于2018年8月16日周四 上午9:40写道：
> Hi Amos
>
> Alpha send response to the Omega once the message is updated into redis,
> then we just store the
Hi Amos
Alpha send response to the Omega once the message is updated into redis,
then we just store the transaction events into the database in async way
(we don't change the states here).
Current Redis cluster provides the persistent storage, it could reduce lot
of effort of us.
Now we just use
Does it have the risk to lose the data ? If we write the data to the redis
and it fails to persistent data just like crashing ?
what is the aof mode of the redis ? Does it guarantee the data consistence
?
2018-08-16 9:28 GMT+08:00 fu chengeng :
> Hi
> can we use the write back way to use
Hi
can we use the write back way to use redis? only write data to redis, and
redis use the aof mode to persistent data. alpha uses an asynchronous thread to
put these 'cold data' to db and delete it from redis. alpha only read and write
with redis.
?取 Outlook for
+1
As one of the committers of the Apache ServiceComb project invited by willem, I
am so glad to hear that ServiceComb is finally approaching graduation.
I am not the initial committers but so interested in microservice, also not
good at writing Java, thanks for the good team atmosphere, I can
Hi Willem,
It makes sense to use the redis to store the pending transactions (I assume
that you mean these are the "HOT" ones). But we could be very careful to
"write" the transaction status, and it should be stored in the database at
last. So I think we must make sure the transaction status in
Hi Lance,
I already already introduced the background of performance tuning here[1].
We could improve the performance by leverage the redis cache without
looking up the events with the complex SQL query.
As the mailing list have some trouble to display the picture that you want
to use.
Maybe you
Hi, gang,
I've made some tests and looked into the implementation of saga
recently. Currently, the alpha-server relies on some complex SQL queries
for compensation and status maintenance. I'm thinking if it is possible to
make some optimizations on this. We can replace the database with
Good thread, ServiceComb is getting more and more mature now
Willem Jiang 于2018年8月15日周三 下午5:09写道：
> With the ServiceComb java-chassis 1.0.0-incubating and service-center
> 1.0.0-incubating release officially out.
> We believe it is time to discuss what requirements remains to consider
>
With the ServiceComb java-chassis 1.0.0-incubating and service-center
1.0.0-incubating release officially out.
We believe it is time to discuss what requirements remains to consider
graduation to the TLP.
I just updated the ServiceComb Project Status for it:
15 matches
Mail list logo
