search

zkfan / tungsten-replicator

Automatically exported from code.google.com/p/tungsten-replicator
0 stars 0 forks source link

waitForAppliedSequenceNumber can return before the sequence number event was actually committed #90

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The following log example shows this issue :

INFO   | jvm 1    | 2011/05/26 23:21:56 | 2011-05-26 23:21:56,845 WARN  
replicator.pipeline.SingleThreadStageTask [q-to-dbms-0] Applying event: 
seqno=374 fragno=0 doCommit=false
INFO   | jvm 1    | 2011/05/26 23:21:56 | 2011-05-26 23:21:56,847 WARN  
replicator.pipeline.StageProgressTracker [q-to-dbms] setLastProcessedEvent: 374
INFO   | jvm 1    | 2011/05/26 23:21:56 | 2011-05-26 23:21:56,847 INFO  
management.tungsten.TungstenPlugin SyncEvent-WaitSeqno: Sequence number 374 
found or surpassed with sequence number: 374
INFO   | jvm 1    | 2011/05/26 23:21:56 | 2011-05-26 23:21:56,847 WARN  
replicator.pipeline.StageProgressTracker [q-to-dbms] setLastProcessedEvent: 374
INFO   | jvm 1    | 2011/05/26 23:21:56 | 2011-05-26 23:21:56,847 WARN  
replicator.store.ParallelQueueExtractor parallel queue size for task 0 = 0
INFO   | jvm 1    | 2011/05/26 23:21:56 | 2011-05-26 23:21:56,847 WARN  
replicator.applier.JdbcApplier Empty event
INFO   | jvm 1    | 2011/05/26 23:21:56 | 2011-05-26 23:21:56,848 WARN  
replicator.applier.JdbcApplier Committing in applier

What is the expected output? What do you see instead?
SyncEvent-WaitSeqno: Sequence number 374 found or surpassed with sequence 
number: 374 happens before commit (on the last line of the example). It should 
actually not.

Note that event 374 is applied with doCommit = false, which implies that the 
applier will not commit just after event is applied.

Original issue reported on code.google.com by Steph.Giron on 26 May 2011 at 9:36

GoogleCodeExporter commented 9 years ago 
This is breaking tests in some cases, especially for row replication, but 
causes minimal problems in production situations.  The key thing to remember is 
that with large block commit sizes and slow slave DBMS you can think something 
is "done" when it is not.  

It will not make the 2.0.3 build but will be fixed as soon as possible 
thereafter.

Original comment by berkeley...@gmail.com on 3 Jun 2011 at 7:25

GoogleCodeExporter commented 9 years ago

Original comment by stephane...@gtempaccount.com on 4 Jul 2011 at 12:35

GoogleCodeExporter commented 9 years ago

Original comment by berkeley...@gmail.com on 8 Sep 2011 at 5:04

GoogleCodeExporter commented 9 years ago

Original comment by robert.h...@continuent.com on 23 Jan 2012 at 6:50

GoogleCodeExporter commented 9 years ago

Original comment by robert.h...@continuent.com on 1 Mar 2012 at 9:45

GoogleCodeExporter commented 9 years ago

Original comment by robert.h...@continuent.com on 1 Mar 2012 at 9:46

GoogleCodeExporter commented 9 years ago 
This is fixed by the changes for Issue 8.  waitForAppliedSequenceNumber now 
waits for a successful commit.

Original comment by robert.h...@continuent.com on 19 Sep 2012 at 2:59

GoogleCodeExporter commented 9 years ago

Original comment by robert.h...@continuent.com on 15 Oct 2012 at 3:47