The request channel timed out while using ODATA REST API
We have recently upgraded to FSM 6UPD9 to make use of the ODATA REST APIs in order to integrate our external applications with FSM.
Very often we are getting a request channel timeout while using the ODATA REST API’s. Once this starts every call fails.
Message:Error occurred while getting EDM model from app server. System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9970047. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
The ODATA rest API's makes a call to the FSM server "<perform_get_updated_odata_edm>" to get the data model. It basically asks for the database table structure of ~1200 tables in FSM, which looks to be a very time-consuming operation. We have observed that the ODATA API attempts to refresh the EDM model every time there is a server restart/ IIS reset or whenever we do a refresh cache (full) from FSM smart client. The refresh cache is something we are doing every time we make any change using the FSM smart client.
Anyone else experiencing the same ? and is there any fix /workaround to this?
Page 1 / 1
Hi Sourabh,
This issue is fixed in UPD14.
Hi @TDCSOURABH ,
You may need to take a look at this post. There’s a workaround for UPD9 but as @Sajith Anushan mentioned, this issue has been resolved in UPD14
Hi @Saranga Amaraweera ,
It looks to be a restricted content.
Can you provide more details regarding the workaround?
--
Sourabh Jain
Hi, Information from R&D : what they said was in the first service call, it requests metadata from server to build the EDM model. Hence, getting the metadata from the application server takes a bit of time. Also as per the comments, there was a bug in which they have fixed it on update 11. They are doing furthermore enhancements to improve the performance on the OData API calls.
Workaround:
If you’re using FSM on premise, then you may go to OData API application pool in IIS and go to the advanced properties of the application pool. Then set the start mode as AlwaysRunning instead of OnDemand (which is the default mode)
Also set the idle timeout setting as 0 instead of 20 minutes.
If your installation is in the cloud then, the application pool has to be with the correct setting, but your workaround could also work based on the schedule to keep it warm. You might be able to check the idle timeout if you have access to cloud server configuration.
Hi,
Thanks a lot.
Does setting start mode to “AlwaysRunning” ensures that the refresh EDM model is automatically invoked after the full server restart or will it wait for the 1st API call.
And setting idleTimeout to 0 will ensure there are no automatic pool restarts, but how does it behave with full server restarts or refresh cache from FSM client.
--
Sourabh Jain
Hi,
Thanks a lot.
Does setting start mode to “AlwaysRunning” ensures that the refresh EDM model is automatically invoked after the full server restart or will it wait for the 1st API call.
And setting idleTimeout to 0 will ensure there are no automatic pool restarts, but how does it behave with full server restarts or refresh cache from FSM client.
--
Sourabh Jain
Only the very first call in the pool might take a bit of time to load the full EDM model (similarly a cold start) and then setting always running property in the app pool will keep the connection warm so that it would not require to load the EDM model for ongoing requests. Refresh cache on FSM client happens actually in the fsm application pool and it’s not dependent with the Odata app pool
Hi,
Ok, so it is not automatic we have to manually trigger the first call after full server restarts to ensure the reload of EDM model and then the always running property will kick in to keep the connections warm.
We have seen that whenever we do Refresh Cache (full) from FSM smart client then after the API calls also behaves same, they time out and starts working after ~5-10 mins
--
Sourabh Jain
“We have seen that whenever we do Refresh Cache (full) from FSM smart client then after the API calls also behaves same, they time out and starts working after ~5-10 mins ”
Same behavior when doing “Refresh Cache” as well.
--
Sourabh Jain
“We have seen that whenever we do Refresh Cache (full) from FSM smart client then after the API calls also behaves same, they time out and starts working after ~5-10 mins ”
Same behavior when doing “Refresh Cache” as well.
--
Sourabh Jain
Hi @TDCSOURABH ,
Have you tested the same with the given settings above?
Hi,
Yes, It is same after changing the above settings.
