What to do when ctx.ErrC channel provides an error?

[maustin75]

This is more of a question and not an issue:

I'm trying to figure out what we should do when we get an error. I don't want to skip oplog messages.

Some initial ideas:

1. We keep going thinking that gtm will handle and we won't skip oplog records
2. Stop (ctx.Stop() ) and restart with gtm.Start using the offset we have been saving when we get a success handling of ctx.OpC

Your thoughts would be appreciated. Basically, to ensure handling of all oplog messages, how would we deal with ctx.ErrC events?

Thanks,
Mike

[rwynn]

@maustin75 Sorry for taking a while to respond to your question. I guess it depends on the error and in this regard gtm could probably give you more structured information about what happened future updates. You are doing what I would do which is to keep track of the offset for records which you have successfully processed. In addition to the ctx.Stop there is also a ctx.Since which takes a Timestamp. The latter is lighter and simply updates the oplog query to include events occurring after the argument, so you can use it to effectively go backward and reprocess events. Stop on the other hand will cause all the go routines to shut down. Stop will also cause any direct reads to shut down whereas Since only works on the go routine tailing the oplog.

For the most part the errors you would encounter would be serialization errors (more common if you use your own function since by default a generic map is used) and connection type errors. For connection errors gtm simply keeps retrying the connection until it is stopped by user code or reconnects. Since gtm holds on to the last successful oplog entry processed it should pick up where it left off for connection type errors.