You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+50-7Lines changed: 50 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@
7
7
8
8
[Nakadi](https://github.com/zalando/nakadi) is a distributed event bus that implements a RESTful API abstraction instead of Kafka-like queues.
9
9
10
-
The goal of this Spring Boot starter is to simplify the reliable integration between event producer and Nakadi. When we send events from a transactional application, a few recurring challenges appear:
10
+
The goal of **this** Spring Boot starter is to simplify the reliable integration between event producer and Nakadi. When we send events from a transactional application, a few recurring challenges appear:
11
11
- we have to make sure that events from a transaction get sent, when the transaction has been committed,
12
12
- we have to make sure that events from a transaction do not get sent, when the transaction has been rolled back,
13
13
- we have to make sure that events get sent, even if an error occurred while sending the event,
@@ -24,7 +24,8 @@ This project is mature, used in production in some services at Zalando, and in a
24
24
25
25
Be aware that this library **does neither guarantee that events are sent exactly once, nor that they are sent in the order they have been persisted**. This is not a bug but a design decision that allows us to skip and retry sending events later in case of temporary failures. So make sure that your events are designed to be processed out of order (See [Rule 203 in Zalando's API guidelines](https://opensource.zalando.com/restful-api-guidelines/#203)). To help you in this matter, the library generates a *strictly monotonically increasing event id* (field `metadata/eid` in Nakadi's event object) that can be used to reconstruct the message order.
26
26
27
-
Unfortunately this approach is not compatible with Nakadi's compacted event types – it can happen that the last event submitted (and thus the one which will stay after compaction) is not the last event which was actually been fired. For this reason, the library currently also doesn't provide any access to Nakadi's [`partition_compaction_key`](https://nakadi.io/manual.html#definition_EventMetadata*partition_compaction_key) feature.
27
+
Unfortunately this approach is fundamentally incompatible with Nakadi's compacted event types – it can happen that the last event submitted (and thus the one which will stay after compaction) is not the last event which was actually been fired.
28
+
We still provide means to set the compaction key, see [compacted event types](#compacted-event-types) below.
28
29
29
30
## Versioning
30
31
@@ -107,7 +108,7 @@ token. The easiest way to do so is to include the [Zalando Tokens library](https
107
108
</dependency>
108
109
```
109
110
110
-
This starter will detect and auto configure it.
111
+
This starter will detect and autoconfigure it.
111
112
112
113
If your application is running in Zalando's Kubernetes environment, you have to configure the credential rotation:
113
114
```yaml
@@ -158,16 +159,18 @@ nakadi-producer:
158
159
```
159
160
160
161
#### Implement Nakadi authentication yourself
161
-
If you do not use the STUPS Tokens library, you can implement token retrieval yourself by defining a Spring bean of type `org.zalando.nakadiproducer.AccessTokenProvider`. The starter will detect it and call it once for each request to retrieve the token.
162
+
If you do not use the STUPS Tokens library, you can implement token retrieval yourself by defining a Spring bean of
163
+
type [`AccessTokenProvider`](nakadi-producer-spring-boot-starter/src/main/java/org/zalando/nakadiproducer/AccessTokenProvider.java).
164
+
The starter will detect it and call it once for each request to retrieve the token.
162
165
163
166
### Creating events
164
167
165
168
The typical use case for this library is to publish events like creating or updating of some objects.
166
169
167
-
In order to store events you can autowire the [`EventLogWriter`](src/main/java/org/zalando/nakadiproducer/eventlog/EventLogWriter.java)
170
+
In order to store events you can autowire the [`EventLogWriter`](nakadi-producer/src/main/java/org/zalando/nakadiproducer/eventlog/EventLogWriter.java)
168
171
service and use its methods: `fireCreateEvent`, `fireUpdateEvent`, `fireDeleteEvent`, `fireSnapshotEvent` or `fireBusinessEvent`.
169
172
170
-
To store events in bulk the methods `fireCreateEvents`, `fireUpdateEvents`, `fireDeleteEvents`, `fireSnapshotEvents` or `fireBusinessEvents` can be used.
173
+
To store several events of the same type in bulk, the methods `fireCreateEvents`, `fireUpdateEvents`, `fireDeleteEvents`, `fireSnapshotEvents` or `fireBusinessEvents` can be used.
171
174
172
175
You normally don't need to call `fireSnapshotEvent` directly, see below for [snapshot creation](#event-snapshots-optional).
173
176
@@ -222,14 +225,51 @@ For business events, you have just two parameters, the **eventType** and the eve
222
225
You usually should fire those also in the same transaction as you are storing the results of the
223
226
process step the event is reporting.
224
227
228
+
#### Compacted event types
229
+
230
+
Nakadi offers a "log-compaction" feature, where each event (on an event type) has a
231
+
[`partition_compaction_key`](https://nakadi.io/manual.html#definition_EventMetadata*partition_compaction_key), and
232
+
Nakadi will (after delivering to live subscribers) clean up events, but leave the latest event for each
233
+
compaction key available long-term.
234
+
235
+
This library (by design) doesn't guarantee the submission order of events – especially when there are problems
236
+
on Nakadi side and some events fail (and are retried later), earlier produced events (for the same entity)
237
+
can be submitted after later events. For log-compacted event types this means that an outdated event will remain
238
+
in the topic for future subscribers to read.
239
+
It is therefore generally **not recommended** to use this library (or any solution which doesn't guarantee the order)
240
+
for sending events to a compacted event type.
241
+
242
+
In some cases, like when there usually are large time gaps between producing events for the same compaction key,
243
+
the risk of getting events for the same key out-of-order is small.
244
+
For these cases, you just can define a bean of type [`CompactionKeyExtractor`](nakadi-producer/src/main/java/org/zalando/nakadiproducer/eventlog/CompactionKeyExtractor.java) , and then all events of that event
245
+
type will get sent with a compaction key.
246
+
247
+
```java
248
+
@Configuration
249
+
public class NakadiProducerConfiguration {
250
+
@Bean
251
+
public CompactionKeyExtractor extractorForWarehouseEvents() {
The service class sending the event looks exactly the same as above.
258
+
259
+
For corner cases: You can have multiple such extractors for the same event type, any one where the class object
260
+
matches the payload object (in undefined order) will be used.
261
+
There are also some more factory methods with different signatures for more special cases, and you can also write
262
+
your own implementation (but for the usual cases, the one shown here should be enough).
263
+
264
+
225
265
### Event snapshots (optional)
226
266
227
267
A Snapshot event is a special type of data change event (data operation) defined by Nakadi.
228
268
It does not represent a change of the state of a resource, but a current snapshot of its state. It can be useful to
229
269
bootstrap a new consumer or to recover from inconsistencies between sender and consumer after an incident.
230
270
231
271
You can create snapshot events programmatically (using EventLogWriter.fireSnapshotEvent), but usually snapshot event
232
-
creation is a irregular, manually triggered maintenance task.
272
+
creation is an irregular, manually triggered maintenance task.
233
273
234
274
This library provides a Spring Boot Actuator endpoint named `snapshot_event_creation` that can be used to trigger a Snapshot for a given event type. Assuming your management port is set to `7979`,
235
275
@@ -260,6 +300,9 @@ your `application.properties` includes
Copy file name to clipboardExpand all lines: nakadi-producer-spring-boot-starter/src/main/java/org/zalando/nakadiproducer/NakadiProducerAutoConfiguration.java
Copy file name to clipboardExpand all lines: nakadi-producer-spring-boot-starter/src/main/java/org/zalando/nakadiproducer/eventlog/impl/EventLogRepositoryImpl.java
+3-2Lines changed: 3 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -87,16 +87,17 @@ public void persist(Collection<EventLog> eventLogs) {
Copy file name to clipboardExpand all lines: nakadi-producer-spring-boot-starter/src/test/java/org/zalando/nakadiproducer/eventlog/impl/EventLogRepositoryIT.java
+5-1Lines changed: 5 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -38,19 +38,22 @@ public class EventLogRepositoryIT extends BaseMockedExternalCommunicationIT {
0 commit comments