Changing Events Max-In-Flight in Subscriptions
In this tutorial, you learn how to set idle "in-flight messages" limit in Kyma Subscriptions. The "in-flight messages" config defines the number of events that Kyma Eventing forwards in parallel to the sink, without waiting for a response.
Prerequisites
NOTE: Read about Istio sidecars in Kyma and why you want them. Then, check how to enable automatic Istio sidecar proxy injection. For more details, see Default Istio setup in Kyma.
- Follow the Prerequisites steps for the Eventing tutorials.
- Create a Function.
For this tutorial, instead of the default code sample, replace the Function source with the following code. To simulate prolonged event processing, the Function waits for 5 seconds before returning the response.
- Kyma Dashboard
- kubectl
Create a Subscription with Max-In-Flight config
Create a Subscription custom resource. Subscribe for events of the type: order.received.v1
and set the maxInFlightMessages
to 5
, so that Kyma Eventing forwards maximum 5 events in parallel to the sink without waiting for a response.
- Kyma Dashboard
- kubectl
Trigger the workload with multiple events
You created the lastorder
Function, and subscribed to the order.received.v1
events by creating a Subscription CR.
Next, publish 15 events at once and see how Kyma Eventing triggers the workload.
- Port-forward the Event Publisher Proxy Service to localhost, using port
3000
. Run:Click to copykubectl -n kyma-system port-forward service/eventing-event-publisher-proxy 3000:80 Now publish 15 events to the Event Publisher Proxy Service. In another terminal window, run:
- CloudEvents Conformance Tool
- curl
Verify the event delivery
To verify that the events ware properly delivered, check the logs of the Function (see Verify the event delivery).
You will see the received events in the logs as:
Processing event: { orderCode: '1' }Processing event: { orderCode: '2' }Processing event: { orderCode: '3' }Processing event: { orderCode: '4' }Processing event: { orderCode: '5' }Completely processed event: { orderCode: '1' }Processing event: { orderCode: '6' }Completely processed event: { orderCode: '2' }Processing event: { orderCode: '7' }Completely processed event: { orderCode: '3' }Processing event: { orderCode: '8' }Completely processed event: { orderCode: '4' }Processing event: { orderCode: '9' }Completely processed event: { orderCode: '5' }Processing event: { orderCode: '10' }Completely processed event: { orderCode: '6' }Processing event: { orderCode: '11' }Completely processed event: { orderCode: '7' }Processing event: { orderCode: '12' }Completely processed event: { orderCode: '8' }Processing event: { orderCode: '13' }Completely processed event: { orderCode: '9' }Processing event: { orderCode: '14' }Completely processed event: { orderCode: '10' }Processing event: { orderCode: '15' }Completely processed event: { orderCode: '11' }Completely processed event: { orderCode: '12' }Completely processed event: { orderCode: '13' }Completely processed event: { orderCode: '14' }Completely processed event: { orderCode: '15' }
You can see that only 5 events at maximum were delivered to the Function in parallel and as soon as the Function completes the processing of the event and returns the response, Kyma Eventing delivers the next in-line event to the Function.