You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ratis.apache.org by Asad Awadia <as...@gmail.com> on 2022/03/01 03:37:46 UTC

Re: Log applying threading

Ok thank you!
________________________________
From: Tsz Wo Sze <sz...@gmail.com>
Sent: Monday, February 28, 2022 3:17:59 AM
To: user@ratis.apache.org <us...@ratis.apache.org>
Subject: Re: Log applying threading

Ratis implements Raft which has strong consistency.  It probably is not easy to relax the consistency model of Ratis (or Raft) to eventual consistency.

Sorry, I don't have a good answer here.

Best regards,
Tsz-Wo



On Mon, Feb 28, 2022 at 12:30 PM Asad Awadia <as...@gmail.com>> wrote:
>It depends on the consistency model and other requirements such as the fault tolerance model.  For eventual consistency, it can achieve such parallelism.  This is a hard question in general and probably is a Ph.D. thesis.

Given that eventual consistency is ok - Do you know if there is a ratis to achieve that?

Would I look for hybrid logical clocks/vector clocks to do what raft does here?

Regards,
Asad

On Sat, Feb 26, 2022 at 4:52 AM Tsz Wo Sze <sz...@gmail.com>> wrote:
> How would error handling work then? ...

What kinds of errors?

Not sure if you are talking about this kind of error: In the FileStore example, suppose the user does not have the permission (for discussion only, the permission feature is not implemented.) to create the file.  The StateMachine should just complete the future exceptionally with permission-denied.  Ratis will wrap the exception and then return it back to the client.  It won't affect the other transactions.

> Do you know of a way to get a distributed datastore but keep it multi threaded all the way down to disk writes? What would I have to trade off to get that requirement?

It depends on the consistency model and other requirements such as the fault tolerance model.  For eventual consistency, it can achieve such parallelism.  This is a hard question in general and probably is a Ph.D. thesis.

Tsz-Wo


On Sat, Feb 26, 2022 at 3:04 PM Asad Awadia <as...@gmail.com>> wrote:
How would error handling work then? Is the processing of a Queue completely halted when an error occurs?


Do you know of a way to get a distributed datastore but keep it multi threaded all the way down to disk writes? What would I have to trade off to get that requirement?
________________________________
From: Tsz Wo Sze <sz...@gmail.com>>
Sent: Saturday, February 26, 2022 12:19:00 AM
To: user@ratis.apache.org<ma...@ratis.apache.org> <us...@ratis.apache.org>>
Subject: Re: Log applying threading

Hi Asad,

These are good questions.

This depends on the StateMachine implementations.  Like most of the Ratis APIs, the StateMachine interface is asynchronous.  In particular, the applyTransaction(..) method returns a future as shown below.  Ratis *submits* the async calls to StateMachine sequentially.  The StateMachine may choose to *process* those calls in parallel.

//StateMachine.java
  CompletableFuture<Message> applyTransaction(TransactionContext trx);

For example, the FileStoreStateMachine processes the write requests in parallel when writing to different files. Of course, the writes within the same file are sequential.  In more detail, each file has its own TaskQueue.  In applyTransaction, FileStoreStateMachine only puts on the write requests to the corresponding TaskQueue.  There is a separated thread pool to process the tasks from the queues.  Therefore, the tasks in different queues are processed in parallel.

Thanks.
Tsz-Wo

On Sat, Feb 26, 2022 at 7:06 AM Asad Awadia <as...@gmail.com>> wrote:
Hello,

Since raft is dependent on applying the raft log in order does that mean that only a single thread is looping over them and applying it?

If yes, does that not cause performance bottle necks?

Regards,
Asad