kafkaprotocol support, with
cache_serverkinds combine to provide a persistent cache of
topicconfiguration for message expiration and compaction. Messages ordering is guaranteed per
partitionand messages are merged into a unified stream for the
cache_serverkind supports proactive
fetchof messages to keep the cache fresh in preparation for new consumers. This is enabled by configuring a list of
bootstraptopics for the binding.
cache_clientkind supports filtering by
kafkamessage key, headers or a combination of key and headers.
kafkatopics, where a slower consumer that is not keeping up with the latest messages can safely skip over each older message that has effectively been replaced by a newer message with the same key.
topicis not compacted, then the binding can be configured to either replay historical messages first, or start with upcoming live messages instead.
cache_serveralso combine to provide a staging area when producing new messages as
kafkarequires exact message length up front when producing new messages and
kafkadoes not support producing multiple messages in parallel over the same network connection.
kafkabinding receives inbound application streams and encodes each as a network stream via
kafkarequest-response protocol. Note that the same network stream can be reused to encode multiple
kafkarequests, including both
topicnames are used to route these network streams to an
exitbinding that ultimately reaches a