Done
Details
Details
Assignee
Andrii Paias
Andrii Paias(Deactivated)Reporter
Sobha Duvvuri
Sobha DuvvuriLabels
Priority
Story Points
2
Sprint
None
Development Team
Spitfire
Fix versions
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created September 27, 2019 at 7:01 PM
Updated October 18, 2019 at 1:22 PM
Resolved October 18, 2019 at 1:22 PM
A few points to note:
1. Two tenants - fs00000000 and fs00001000 are running in the same container on the same EC2 instance.
2. Both tenants are using different RM API accounts - fs00000000 is using "ns187805" and fs00001000 is using "s3911979"
Please see attached logs:
1. Few interesting things to note in logs are while the load process is running for fs00000000 at 20:48:00:092 and imported 100,000 at 20:48:01:458 we receive signal to start the process again and it restarts for tenant fs00000000 eventually resulting in error
2. Soon after at 20:48:02:721, we see an error with tenant fs00001000 and error is from RM API as below:
which results in an Internal Server error in our code.
Either RM API holdings process or our holdings process is having an issue with parallel processes getting holdings information although using 2 different custids.
Note: Please do not use custid = s3911979 for testing purposes. It is a real production account. Use 'apidvcorp' and 'apidvgvmt' production accounts.
Holdings Status table for fs00000000 - this is probably stuck there because we removed RM API configuration since this was a tenant not in use
Holdings status table for fs00001000 -
Acceptance Criteria:
1. Investigate the root cause and see if we can come up with a solution.
2. See if we already fixed this in newer version of code. These logs are from q3.1 release version.
3. Create user stories to fix the issue as necessary