Skip to end of banner
Go to start of banner

MODQM-217 Spike: Determine a plan to address persistent 500 errors upon editing a quickMARC record

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

MODQM-217 - Getting issue details... STATUS

Objectives

  • what code change(s) maybe a contributing factor
  • how can we prevent 500 errors
  • Kafka
  • what additional Karate tests are needed 
  • how can we anticipate these issues rather than have customers identify
  • if the issue is related to multi-tenant versus single tenant 
  • if the issue is related to how the data is loaded (via data import or directly to storage)
  • if the issue is related to how the data is updated (via data import, inventory or MARC authority app UI or directly to storage)  

Analysis

500 error causes

IssueCauseDescription

MODQM-169

MODQM-170

Kafka topics configuration

Kafka consumers try to connect to existing consumer groups that have different assignment strategies. This led to mod-quick-marc doesn't receive any confirmation about successful/failed update. mod-quick-marc has a timeout (the 30s) for confirmation receiving. If the timeout is exceeded then respond with a 500 error. 







  • No labels