Releases: line/decaton
v9.1.0
Important
Please read the upgrade guide in https://github.com/line/decaton/releases/tag/v9.0.0 carefully
Breaking Changes
New Features
- Put back support to produce in the old DecatonTaskRequest for migration #248
Bug Fixes
Improvements
Other Changes
9.0.1
Important
Please read the upgrade guide in https://github.com/line/decaton/releases/tag/v9.0.0 carefully
Breaking Changes
New Features
Bug Fixes
Improvements
- Lower log level of partition processor core creation, to be virtual thread friendly #245
Other Changes
9.0.0
Important
Please read the upgrade guide section carefully
Breaking Changes
- TaskMetadata as header (#238)
decaton-client:DecatonClientno longer wraps tasks withDecatonTaskRequest-protobuf
decaton-processor:DecatonTaskRequestis moved tocom.linecorp.decaton.protocol.internaland marked as deprecated- Retry tasks are no longer produced in
DecatonTaskRequestformat unlessdecaton.retry.task.in.legacy.formatis set totrue KafkaProducerSuppliersignature changeTaskExtractorsignature change
- Please read below upgrade guide carefully!!!
- Make Decaton can consume any topic with deserializer (#241)
decaton-processor:ProcessorsBuilder#consuming(String topic, Deserializer<T> deserializer)no longer parses messages asDecatonTaskRequest-protobuf at all, unlessdecaton.legacy.parse.fallback.enabled
- Please read below upgrade guide carefully!!!
New Features
Bug Fixes
Improvements
Other Changes
- Fix potential key exposure in PKQ (#237)
- Add task batching doc (#150)
- Update docs and examples for 9.0.0 (#239)
Upgrade guide from 8.0.1 or earlier
- As described in "Breaking Changes" section, Decaton made two big breaking changes in this release.
- You MUST read below guide carefully and follow the instructions, or your application may encounter deserialization errors and fail to process tasks.
Depending on your use cases, there are 4 different upgrade paths.
| Using retry queueing? | Using DecatonClient? (i.e. tasks are parsed by Deserializer rather than TaskExtractor) |
Upgrade path |
|---|---|---|
| N | N | Case A |
| N | Y | Case B |
| Y | N | Case C |
| Y | Y | Case D |
Case A: No retry queueing && non-DecatonClient
In this case, you can upgrade as usual without any special care.
- Step1: Upgrade decaton-processors to 9.0.0 or higher.
- That's it.
Case B: No retry queueing && DecatonClient
- Step1: Upgrade decaton-processors to 9.0.0 or higher with
decaton.legacy.parse.fallback.enabled=true - Step2: Upgrade decaton-clients to 9.0.0 or higher
- Step3: Wait all old-format tasks are processed after Step2.
- You can monitor topic's committed offset is caught-up
- Step4: Set
decaton.legacy.parse.fallback.enabled=false
Case C: Retry queueing && non-DecatonClient
- Step1: Upgrade decaton-processors to 9.0.0 or higher with
decaton.retry.task.in.legacy.format=true,decaton.legacy.parse.fallback.enabled=true - Step2: After all decaton-processors are upgraded, set
decaton.retry.task.in.legacy.format=false - Step3: Wait all retry tasks are processed after Step2.
- You can monitor retry-topic's offset lag becomes 0.
- Step4: Set
decaton.legacy.parse.fallback.enabled=false
Case D: Retry queueing && DecatonClient
- Step1: Upgrade decaton-processors to 9.0.0 or higher with
decaton.retry.task.in.legacy.format=true,decaton.legacy.parse.fallback.enabled=true - Step2: Upgrade decaton-clients to 9.0.0 or higher
- Step3: After all decaton-processors are upgraded, set
decaton.retry.task.in.legacy.format=false - Step4: Wait all old-format tasks and retry tasks are processed after Step3.
- You can monitor topic's committed offset is caught-up and retry-topic's offset lag becomes 0.
- Step5: Set
decaton.legacy.parse.fallback.enabled=false
EDIT 2025.01.29
In addition to the above migration procedure, if you are using DecatonClient (decaton-client) in your application, which also runs a ProcessorSubscription (decaton-processor module) AND the tasks produced by the same app are coming back to the processor of the same app (i.e, looping-back), by you upgrading decaton-processor dep it also pulls a newer decaton-client dep which no longer produces tasks in the deprecated DecatonTaskRequest format.
Under this situation we also need to keep the DecatonClient producing tasks in the old format until all destination processors are upgraded and reasy to parse thew new header-based metadata, and for this case we've recently added a new flag to DecatonClientBuilder to instruct it keep using the deprecated format - produceInOldTaskRequest.
Please make sure to set the parameter if your application matches the above case.
See also #248.
DecatonClient.producing(topic, new ProtocolBuffersSerializer<HelloTask>())
...
.produceInOldTaskRequest(true) // This will make the resulting DecatonClient to keep using the old task format
.build();8.0.1
8.0.0
7.2.0
Breaking Changes
New Features
- Add delivery latency and scheduled delay metrics (#218)