View Issue Details

IDProjectCategoryView StatusLast Update
0003801SymmetricDSBugpublic2019-08-23 16:46
Reporterjosh-a-hicks Assigned To 
Prioritynormal 
Status closedResolutionfixed 
Product Version3.9.0 
Target Version3.10.4Fixed in Version3.10.4 
Summary0003801: Ignoring a batch in RQ status with an extract error can cause replication to stop
DescriptionDuring a load a batch failed to extract and after further analysis the table was not needed for replication. Configuration was removed and the batch was ignored. The current load though did not proceed and extract errors continued. The load was cancelled and a new one was started but extract errors continued. It turns out the sym_extract_request still had requests from the original load in NE status and were still failing from the original problem even though the load and batches were cancelled/ignored.
Tagsinitial/partial load

Relationships

related to 0004043 closedJJ_Starrett SymmetricDS Pro Load Data screen does not reflect the fact that a previous load has been cancelled 

Activities

elong

2019-05-22 20:07

developer   ~0001506

Is this fixed in 3.10?

hanes

2019-07-17 15:39

developer   ~0001558

It appears there's still one scenario where the extract row in sym_extract_request is not marked as OK. The scenario occurs when you start a second full row. The batch that's having troubles being extracted is marked as okay, but the underlying extract request still shows as NE Cancelling the existing load seems to clean up the extracts, as does ignoring the specific batch. Tough scenario to test though. Used two tables, turned off extract request job. Then deleted triggers for one table, and locked that table. Then ran extract request

elong

2019-08-09 18:24

developer   ~0001569

The queuing of an initial load should cancel any outstanding loads. In the DataService.insertReloadEvents() method, it checks isFullLoad, and then calls OutgoingBatchService.markAllAsSentForNode(), but it also needs to cancel extract requests and table reload requests.

Issue History

Date Modified Username Field Change
2018-11-19 20:18 josh-a-hicks New Issue
2019-04-25 14:46 elong Tag Attached: initial/partial load
2019-04-25 14:48 elong Assigned To => hanes
2019-04-25 14:48 elong Status new => assigned
2019-05-22 20:07 elong Note Added: 0001506
2019-07-17 15:39 hanes Assigned To hanes => elong
2019-07-17 15:39 hanes Status assigned => feedback
2019-07-17 15:39 hanes Note Added: 0001558
2019-07-22 18:49 elong Relationship added related to 0004043
2019-08-09 18:24 elong Note Added: 0001569
2019-08-09 18:24 elong Assigned To elong =>
2019-08-09 18:24 elong Status feedback => acknowledged
2019-08-09 18:24 elong Target Version => 3.10.5
2019-08-09 20:03 elong Status acknowledged => resolved
2019-08-09 20:03 elong Resolution open => fixed
2019-08-09 20:03 elong Fixed in Version => 3.10.4
2019-08-09 20:03 elong Target Version 3.10.5 => 3.10.4
2019-08-23 16:46 admin Status resolved => closed