[FOLIO-2684] Sequential requests to MODOAIPMH are distributed between two module instances Created: 10/Jul/20  Updated: 17/Jul/20  Resolved: 13/Jul/20

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: P2
Reporter: Mikhail Fokanov Assignee: Unassigned
Resolution: Done Votes: 0
Labels: devops
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks MODOAIPMH-192 Resumption token fails from time to t... Closed
Relates
relates to MODINVSTOR-536 Separate filtering from response gene... Closed
Sprint:
Development Team: FOLIO DevOps

 Description   

Only one instance of MODOAIPMH should be deployed (as sticky session cannot be done with current infrastructure).

In terms of performance and availability there will be no issues with having one instance of MODOAIPMH module.

The underlying business case is the following:
1.) MODOAIPMH starts http connection (for streaming fetching from database) to mod-inventory-storage by user request
2.) MODOAIPMH sends part of data to user
3.) User make another request to MODOAIPMH for the second part of data

Expected result:
The second and all following user requests should go to the same OAI-PMH module instance (the same java app).

Actual result:
Following requests are randomly distributed between two OAI-PMH module instances.

Note: Priority P2 is set for the issue after discussion with Anastasiia Zakharova, as it causes significant problems for OAI-PMH harvesting



 Comments   
Comment by Wayne Schneider [ 10/Jul/20 ]

I can see how you could provide session stickiness between an outside client and edge-oai-pmh, but how can you provide that through to mod-oai-pmh, which is proxied by Okapi?

Adam Dickmeiss – any thoughts?

Comment by Anastasiia Zakharova [ 13/Jul/20 ]

Only one instance of mod-oai-pmh was deployed instead of being clustered. This is a temporary solution, mod-oai-pmh should become stateless in future.

Generated at Thu Feb 08 23:22:29 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.