Hi Guozhang,
The async event trigger process is not running as a kafka streams application.
It offers REST interface where other applications post events which in turn
needs to go through App1's state and send requests to App2 via Kafka. Here is
the diagram:
KafkaTopics---> App1 ---> App2
|
V
REST ---->App3
REST API to App3 and read the local store of App1 (IQ) and send requests to
App2 (through kafka topic, not shown above). Conceptually it looks same as
your use case. What do people do if a kafka streams application (App1) has to
offer REST interface also ?
-thanks
Mohan
On 9/30/20, 5:01 PM, "Guozhang Wang" <wangg...@gmail.com> wrote:
Hello Mohan,
If I understand correctly, your async event trigger process runs out of the
streams application, that reads the state stores of app2 through the
interactive query interface, right? This is actually a pretty common use
case pattern for IQ :)
Guozhang
On Wed, Sep 30, 2020 at 1:22 PM Parthasarathy, Mohan <mpart...@hpe.com>
wrote:
> Hi,
>
> A traditional kafka streams application (App1) reading data from a kafka
> topic, doing aggregations resulting in some local state. The output of
this
> application is consumed by a different application(App2) for doing a
> different task. Under some conditions, there is an external trigger (async
> event) which needs to trigger requests for all the keys in the local store
> to App2. To achieve this, we can read the local stores from all the
> replicas and send the request to App2.
>
> This async event happens less frequently compared to the normal case that
> leads to the state creation in the first place. Are there any caveats
doing
> it this way ? If not, any other suggestions ?
>
> Thanks
> Mohan
>
>
--
-- Guozhang
