Event Endpoint Management continues to be enhanced

Event Endpoint Management continues to be available and enhanced as part of IBM's integration platforms.

End of Marketing announcement for IBM Event Automation

Event Streams and Event Processing are deprecated and no enhancements will be provided. Support and security fixes will be provided in line with published support lifecycle policies. Future event-driven solutions that make use of Apache Kafka and Apache Flink will be delivered by IBM Confluent.

For more information, see how you can plan your transition.

Events are silently dropped in flows that contain a watsonx.ai node

Symptom

When running a flow that contains a watsonx.ai node, some events are not enriched and do not appear in the output. The flow continues to run and no errors are reported.

The Flink Task Manager logs display the following warning:

WARN  com.getindata.connectors.http.internal.table.lookup.JavaNetHttpPollingClient [] - Returned Http status code was invalid or returned body was empty. Status Code [429]

Causes

This issue affects flows that were created before Event Processing 1.5.5, or flows that have been reverted to the earlier implementation.

In the earlier implementation, the watsonx.ai node issued HTTP calls to watsonx.ai concurrently (asyncPolling: true). When multiple events arrive at the node at the same time, the number of concurrent requests can exceed the rate limit of the watsonx.ai service, which returns an HTTP 429 (Too Many Requests) status code. Because the earlier implementation used 'http.source.lookup.continue-on-error' = 'true', the error is suppressed, the affected events are not enriched, and they are silently dropped from the output.

For more information about the asyncPolling and http.source.lookup.continue-on-error options, see the Flink HTTP connector documentation.

Resolving the problem

In Event Processing 1.5.5 and later, the watsonx.ai node uses an updated implementation where HTTP calls to watsonx.ai are issued sequentially ('asyncPolling' = 'false'). This prevents concurrent requests from triggering rate limiting, so no events are lost.

To use the new implementation, open and save the flow in the Event Processing UI. The flow is automatically updated to use the new implementation.

Note:

  • Sequential HTTP calls might affect the throughput of your flow. If the watsonx.ai response time is a concern for your use case, monitor flow performance after updating.
  • If you are using a version earlier than 1.5.5, or if you revert nodes to the earlier implementation, ensure that the volume of concurrent events does not exceed the rate limit of your watsonx.ai deployment.