Dashboard > Timeout: After a timeout, the UI is stuck and I cannot use the refresh button anymore...

[LucasBrazi06]

Jump from session screen with session ID and wait for the timeout + try to click on the refresh button above the list:

https://slf.evse.cfapps.eu10.hana.ondemand.com/logs?Search=1894409169

To get back the app youo are forced to refresh the browser.

And we maybe have too increase the timeout for this scenario which is finding all the logs related to a transaction or maybe a new field is needed in the DB (Session ID) + a new filter in the UI.

[jerome-benoit]

To get back the app youo are forced to refresh the browser. And we maybe have too increase the timeout for this scenario which is finding all the logs related to a transaction or maybe a new field is needed in the DB (Session ID) + a new filter in the UI.

That kind of issue are triggered by the network link quality between SCP and MongoDB Atlas. That never happens locally or on AWS.

If a VPN like can be build with Atlas and SAP-IT SCP for MongoDB connections, all querying on the logs will as fast as it should be and without triggering any timeout.

-- Jérôme Benoit aka fraggle Piment Noir - https://piment-noir.org OpenPGP Key ID : 27B535D3 Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3

[LucasBrazi06]

That kind of issue are triggered by the network link quality between SCP and MongoDB Atlas. That never happens locally or on AWS. If a VPN like can be build with Atlas and SAP-IT SCP for MongoDB connections, all querying on the logs will as fast as it should be and without triggering any timeout.

But you don't have to go through 8 millions records neither on AWS nor locally and this lasts more that 30 secs. Whenever there is also an HTTP 500 error the UI is also broken.

[jerome-benoit]

That kind of issue are triggered by the network link quality between SCP and MongoDB Atlas. That never happens locally or on AWS. If a VPN like can be build with Atlas and SAP-IT SCP for MongoDB connections, all querying on the logs will as fast as it should be and without triggering any timeout.

But you don't have to go through 8 millions records neither on AWS nor locally and this lasts more that 30 secs.

Locally, we are using a production dump of the DB and no search patterns are longer than 3s or 4s. On AWS, all tests were done on the production DB, including complex search in logs. None of them have last more than 5s.

Whenever there is also an HTTP 500 error the UI is also broken.

The way backend connection errors are handled in the dashboard was there before and that networking quality issue just reveals it to be not user friendly.

[LucasBrazi06]

Locally, we are using a production dump of the DB and no search patterns are longer than 3s or 4s. On AWS, all tests were done on the production DB, including complex search in logs. None of them have last more than 5s.

The new dump does not contain the logs, which one do you use?

[jerome-benoit]

Locally, we are using a production dump of the DB and no search patterns are longer than 3s or 4s. On AWS, all tests were done on the production DB, including complex search in logs. None of them have last more than 5s.

The new dump does not contain the logs, which one do you use?

On my local install, a very old one with specific setups for load tests. On AWS, that was the real production DB during the tests before putting the landscape in production

++

-- Jérôme Benoit aka fraggle Piment Noir - https://piment-noir.org OpenPGP Key ID : 27B535D3 Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3

[LucasBrazi06]

On my local install, a very old one with specific setups for load tests. On AWS, that was the real production DB during the tests before putting the landscape in production

On AWS you have only 700k logs on the monaco tenant and 6 millions on slf. Not comparable in the end. Maybe on your local env you have more and on mine I cannot test because I imported the latest one which has no logs.

[jerome-benoit]

On my local install, a very old one with specific setups for load tests. On AWS, that was the real production DB during the tests before putting the landscape in production

On AWS you have only 700k logs on the monaco tenant and 6 millions on slf.

Tests were done on the SCP production DB before putting the landscape in production.

So the issues here are:

• Change the backend connection issue handling in the dashboard: no reload required, user friendly error reporting.
• Fix networking issue between SCP and Atlas.

For the latter, extending the timeout length is a temporary workaround that will not fix the root cause.

[LucasBrazi06]

I won't change the timeout, 60s is largely enough I think! And we have to search only on indexed field, I will create a Text index. But it's not only between the backend and the DB but also between the front-end and the backend: two 500 errors and you are forced to refresh the browser :-(. Weird!

[jerome-benoit]

I can't reproduce the 'stuckiness' here. If the HTTP server return a HTTP timeout error code, the dashboard display the notification popup but nothing is stuck.

I think the issue with two HTTP 500 error code in a row need a specific issue.

[LucasBrazi06]

I can't reproduce the 'stuckiness' here. If the HTTP server return a HTTP timeout error code, the dashboard display the notification popup but nothing is stuck.

I think the issue with two HTTP 500 error code need a specific issue.

Ok, I'll let you know.