resetTokens

Imported from Google Groups
#1

Hi.

There seem to be three different ways to reset the tokens for a processor:

`
public void resetTokens(){}
public void resetTokens(Function<StreamableMessageSource, TrackingToken> initialTrackingTokenSupplier) {}
public void resetTokens(TrackingToken startPosition) {}

`

When we perform a reset we also have a @ResetHandler to cleanout tables.

This is where we are hitting a problem
The resetHandler can have the ResetTriggeredEvent in its signature but it does not contain any indication of the reset timepoint.

So currently we can only do a reset to the beginning of time because in that case we know we have to delete the entire contents of the tables/views.

But we would like to also have the ability to reset to, for example, last week.
In that case we would need to know the reset timestamp in the resethandler.

Is there a way to get that information or is it maybe a feature that could be added (enrich the resetTriggerEvent with some useful data about the reset)

Kr

Tom.

#2

Hi Tom,

that would indeed be an interesting feature. The way it works right now, secretly, is by emitting an event of type “ResetTriggeredEvent” to all the handlers that are registered under the processor that is reset.
We should be able to add some data to that event so that the handler can pick that up. It’s probably interesting to include the token to which the processor will be reset and perhaps some form of representation that explains whether it was a HEAD, TAIL, TIME_BASED or CUSTOM reset.

Another idea: we could change the @ResetHandler to not be an event handler for Events with a “ResetTriggeredEvent” payload, but rather a MessageHandler for messages of type ResetTriggeredMessage, and then have a customizable payload. Then invoking reset, you can pass an optional payload. In case, you have more freedom to provide information that you find useful.

What would you feel gives you the flexibility that you’d need?

Cheers,

#3

Hi Allard,

I feel like a customizable payload would be the most flexible.
That way we could even program eplicit reset flows for certain usecases which makes maintenance a lot easier.

Kr

Toml