Versions Compared

Old Version 103

changes.mady.by.user Joseph Keenan

Saved on

compared with

New Version 104

changes.mady.by.user Joseph Keenan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Modify REST endpoint to include param topic (1)
  2. Add logic to send response and request (2a & 2b) 
  3. Add producer to DMI (implementation and config) (31 & 3b)
  4. Add consumer to NCMP (implementation and config) (4a)
  5. Add Producer to NCMP (implementation and config) (4b)
  6. Demo & Test (5)


Alternative Approaches


#PersonApproach
1

Renu Kumari 

It would be good to have async implementation only dependent on NCMP. So that it does not break or work with only few DMI plugins. 
I think a DMI plugin independent async flow would be like 
1. Once request is receievd, check if  dmi plugin exist. If exists, generate request uuid, send the message to the Kafka topic (or store it in DB), and send an accepted response back to client.
2. NCMP will listen to the same topic or read from the DB. Process it by calling appropriate DMI Plugins synchronously. After it receives the response back, it sends to to kakfa topic provided in the input by user. 

In this implementation, we are not dependent on the DMI implementation. 
We do need persistence for storign async request. It can be a stored in DB or Kafka, it does not matter as long as we can read it in the same order. 

The main points are
1. No dependency on the DMI for async behaviour

2. No async request get lost because of pod restart or JVM crash. 


Kafka config & Implementation

...