[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Resolution: Fixed Fix Version/s: 0.99.0 Status: Resolved (was: Patch Available) This was committed a while back. Resolving. Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Fix For: 0.99.0 Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt, 11135v5.txt, 11135v5.txt, 11135v6.txt, 11135v7.txt, 11135v8.addendum.doc.txt, 11135v8.txt, 11135v8.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Attachment: 11135v2.txt More cleanup. Let me get some perf numbers now. Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[
https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-11135:
--
Attachment: 11135v5.txt
[~jeffreyz] has been reviewing offline. Comments that if CP is slow doing
pre/post append, then as is, we will slow throughput. But as he notes, this is
as it is in 0.98 and not really a way around it since cp, and wal listeners are
inline w/ the actual append.
In this patch over most of the appendNoSyncs to use new method (so
edit/sequence id is availble on return out of append). Changed the append to
use a latch. This gained me back a few percent... maybe 5%... but this patch
makes us slower appending. When 200 threads contending, about 1/3rd slower
again (180seconds vs 280 seconds to complete test):
{code}
$ for i in 1 3 5 10 50 200; do for j in 1 2 3; do perf stat
./hbase-0.99.0-SNAPSHOT/bin/hbase --config /home/stack/conf_hbase
org.apache.hadoop.hbase.regionserver.wal.HLogPerformanceEvaluation -threads $i
-iterations 10 -keySize 50 -valueSize 100
/tmp/wpatch_latch_barrier.${i}.${j}.txt; done; done
{code}
I tried then also using a cyclicbarrier in the SyncFuture for the handler
thread and the the sync'ing thread to coordinate around but no noticeable
difference (perhaps a little slower).
I'd be good committing this for now since it simplifies the unification of mvcc
and sequence id. Even when we are 1/3rd slower we are still ahead of 0.98 in
trunk since the claim in HBASE-10156 is that it doubled our throughput at 200
threads.
After the unification happens, we can come back here again to do see if we can
get perf back.
Change region sequenceid generation so happens earlier in the append cycle
rather than just before added to file
Key: HBASE-11135
URL: https://issues.apache.org/jira/browse/HBASE-11135
Project: HBase
Issue Type: Sub-task
Components: wal
Reporter: stack
Assignee: stack
Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt
Currently we assign the region edit/sequence id just before we put it in the
WAL. We do it in the single thread that feeds from the ring buffer. Doing
it at this point, we can ensure order, that the edits will be in the file in
accordance w/ the ordering of the region sequence id.
But the point at which region sequence id is assigned an edit is deep down in
the WAL system and there is a lag between our putting an edit into the WAL
system and the edit actually getting its edit/sequence id.
This lag -- late-binding -- complicates the unification of mvcc and region
sequence id, especially around async WAL writes (and, related, for no-WAL
writes) -- the parent for this issue (For async, how you get the edit id in
our system when the threads have all gone home -- unless you make them wait?)
Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of
getting the region sequence id near-immediately. We'll run two ringbuffers.
The first will mesh all handler threads and the consumer will generate ids
(we will have order on other side of this first ring buffer), and then if
async or no sync, we will just let the threads return ... updating mvcc just
before we let them go. All other calls will go up on to the second ring
buffer to be serviced as now (batching, distribution out among the sync'ing
threads). The first rb will have no friction and should turn at fast rates
compared to the second. There should not be noticeable slowdown nor do I
foresee this refactor intefering w/ our multi-WAL plans.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Status: Patch Available (was: Open) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Attachment: 11135v8.txt Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt, 11135v5.txt, 11135v5.txt, 11135v6.txt, 11135v7.txt, 11135v8.txt, 11135v8.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Attachment: 11135v5.txt Retry for hadoopqa Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt, 11135v5.txt, 11135v5.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Attachment: 11135v8.txt Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt, 11135v5.txt, 11135v5.txt, 11135v6.txt, 11135v7.txt, 11135v8.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Attachment: 11135v8.addendum.doc.txt [~jeffreyz] I committed this addendum to make comments match the implementation. Thanks for review. Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt, 11135v5.txt, 11135v5.txt, 11135v6.txt, 11135v7.txt, 11135v8.addendum.doc.txt, 11135v8.txt, 11135v8.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Attachment: 11135.wip.txt wip Includes doc cleanup from HBASE-11109. Does not do double ring buffer. Instead, when we appendNoSync, we just wait for the append to complete before returning (early-binding instead of late-binding). Also changed signature for HLog#appendNoSync so it takes a HLogKey. We stick the region edit/sequence id into the HLogKey so it is available on return from appendNoSync. Region sequence id is now always updated by the WAL system (Need to finish getting an id -- plumb it through). Should fix HBASE-11109. This patch includes the HBASE-11109 tests. Need to see how much perf we are losing doing this wait on append and then a wait on sync. Need to do cleanup too. Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Attachment: 11135v6.txt The TestLogRolling was a real issue (I love unit tests). TestMultiParallel is not me. This has just started failing generally. Fix line lengths. Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt, 11135v5.txt, 11135v5.txt, 11135v6.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Attachment: 11135v7.txt Fix findbugs and javadoc. The failure is odd (says only one replica). Can't repro down here. Retry. Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt, 11135v5.txt, 11135v5.txt, 11135v6.txt, 11135v7.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11135) Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file
[ https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11135: -- Attachment: 11135v5.txt Change region sequenceid generation so happens earlier in the append cycle rather than just before added to file Key: HBASE-11135 URL: https://issues.apache.org/jira/browse/HBASE-11135 Project: HBase Issue Type: Sub-task Components: wal Reporter: stack Assignee: stack Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt, 11135v5.txt Currently we assign the region edit/sequence id just before we put it in the WAL. We do it in the single thread that feeds from the ring buffer. Doing it at this point, we can ensure order, that the edits will be in the file in accordance w/ the ordering of the region sequence id. But the point at which region sequence id is assigned an edit is deep down in the WAL system and there is a lag between our putting an edit into the WAL system and the edit actually getting its edit/sequence id. This lag -- late-binding -- complicates the unification of mvcc and region sequence id, especially around async WAL writes (and, related, for no-WAL writes) -- the parent for this issue (For async, how you get the edit id in our system when the threads have all gone home -- unless you make them wait?) Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of getting the region sequence id near-immediately. We'll run two ringbuffers. The first will mesh all handler threads and the consumer will generate ids (we will have order on other side of this first ring buffer), and then if async or no sync, we will just let the threads return ... updating mvcc just before we let them go. All other calls will go up on to the second ring buffer to be serviced as now (batching, distribution out among the sync'ing threads). The first rb will have no friction and should turn at fast rates compared to the second. There should not be noticeable slowdown nor do I foresee this refactor intefering w/ our multi-WAL plans. -- This message was sent by Atlassian JIRA (v6.2#6252)
