{"id":888,"date":"2022-09-05T06:58:32","date_gmt":"2022-09-05T06:58:32","guid":{"rendered":"https:\/\/craftcookcode.com\/?p=888"},"modified":"2024-07-10T02:36:14","modified_gmt":"2024-07-10T02:36:14","slug":"qlik-replicate-json-doesnt-start-with-xxxxxxx-at_cjson-c1773-error","status":"publish","type":"post","link":"https:\/\/craftcookcode.com\/?p=888","title":{"rendered":"Qlik Replicate – “Json doesn’t start with ‘{‘ [xxxxxxx] (at_cjson.c:1773)” error"},"content":{"rendered":"\n

Had a shocker of a week.<\/p>\n\n\n\n

You know those weeks; where everything went wrong.<\/p>\n\n\n\n

Busy fixing other systems; after Operating system patching done by our IT team I didn’t look closely to our Qlik Replicate nodes that have been running smoothly over the past year <\/p>\n\n\n\n

After all there were no alerts; and a quick glance all our tasks were in a running status and none were in suspended or error status.<\/p>\n\n\n\n

Next day One of our junior admin the pointed out some Qlik tasks using a high amount of memory.<\/p>\n\n\n\n

I looked in and my stomach dropped.<\/p>\n\n\n\n

Although the task was “green” and running; no changes were getting through to the destinations (AWS S3 and GCS).\u00a0 The log file was filled with errors like:<\/p>\n\n\n

\n00002396: YYYY-MM-DDT15:21:14 [AT_GLOBAL ]E: Json doesn't start with '{' [xxxxxxx] (at_cjson.c:1773)\n00002396: YYYY-MM-DDT15:21:14 [AT_GLOBAL ]E: Cannot parse json: [xxxxxxx(at_protobuf.c:1420)\n<\/pre><\/div>\n\n\n
And hundreds and thousands of transactions were waiting to be written out.<\/p>\n\n\n\n
The problem only existed on one QR cluster and only jobs that were writing to AWS S3 and GCS; the Kafka one was fine.  The other QR clusters were running fine<\/p>\n\n\n\n
The usual “Turn it off and on again” didn’t work in either stopping or resuming the task; or restarting the server.<\/p>\n\n\n\n
In the end I contacted Qlik Supported.<\/p>\n\n\n\n
They hypothesised that the blanked patching caused the Qlik Replicate cluster to fail over and corrupt the captured changes stored up waiting to be written out in the next batch process.  When QR tried to read the captured changes – the json was corrupted.<\/p>\n\n\n\n
Their fix strategy was:<\/p>\n\n\n\n
    \n
  1. Stop the task<\/li>\n\n\n\n
  2. Using the log file; find out the last successful time or stream position that the task.\u00a0 This is usually found at the end of the log files.<\/li>\n\n\n\n
  3. Using the Run -> Advance Run option; restart the task from the time last written out.<\/li>\n<\/ol>\n\n\n\n
    If this didn’t work; the recommended rebuilding the whole task and following the above steps<\/p>\n\n\n\n
    Luckily their first steps worked.  After finding the correct timestamps we could restart the QR tasks from the correct position.<\/p>\n\n\n\n
    Now looking into some alerting to prevent this problem again.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Had a shocker of a week. You know those weeks; where everything went wrong. Busy fixing other systems; after Operating system patching done by our IT...<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[13,16],"tags":[],"class_list":["post-888","post","type-post","status-publish","format-standard","hentry","category-code","category-qlik-replicate"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t