Questions
Chris21 API delays and timeouts
Connecting from UNIFYConnect to my customer's Chris21 via PortBridge I am seeing some strange API delays.
For DET I see the following - connection successful, then a one minute delay before all the records come through:
For POS it's a bit more problematical - connection successful, but nearly 5 minute delay before the records come through, accompanied by a "loop time limit" timeout error which aborts the import:
Do you have any suggestions what might be going on to result in this behaviour?
The customer is filtering the results we see to just a small number of records, as this is a small-scale POC.
Answer
Hi Adrian,
Those delays mean that the response from Chris21 is slow.
The order you're seeing the log messages in is correct:
- We issue a login request to get an authentication token for the first set of requests
- If you've got a chunk count set on the connector, we log what the chunk count is (chunking [x] is implemented)
- We then make the request to Chris21 API to return that subset of results
- We then process the results they've returned, counting the number of records returned.
Once everything is complete (whether an error line was returned or not) we issue a log out command.
In the case of your DET connector, it looks like everything is running fine - albeit a bit slow.
For your POS connector, that error is coming from Chris21. The only thing I can recommend in this scenario is to reduce the chunk size of the connector, which sets the page size for each outgoing call. Try starting with a lower number to see what the response time is for each call.
There might be some tweaks that the customer needs to do on their end for optimal GTR performance, as it's not normal for the data reads to take that long.
There's generally a test site (same URL as the c21connect.asp - called post21.htm. For example https://localhost/Scalable/post21.htm)
If the customer has this page running, you can normally send a login line and then request lines to test API responses. This might help to confirm the delays on the Chris21 side.
Seems like this problem is occuring because the customer has defined server-side filtering of the records returned to us, and sometimes the backend runs for over 280 seconds without passing a result back to the Chris21 web service, at which point it times out. Sadly, we haven't been able to find where that 280 seconds delay is configured yet. But the issue is definitely on the Chris21 end.
It should be OK to set this ticket non-private, I was careful to redact customer details and credentials.
Customer support service by UserEcho
Seems like this problem is occuring because the customer has defined server-side filtering of the records returned to us, and sometimes the backend runs for over 280 seconds without passing a result back to the Chris21 web service, at which point it times out. Sadly, we haven't been able to find where that 280 seconds delay is configured yet. But the issue is definitely on the Chris21 end.
It should be OK to set this ticket non-private, I was careful to redact customer details and credentials.