Comment thread:

Christie: We heavily use this module for tracking applications and have been experiencing this issue regularly since build 4.0.57.30 (2019-04-05)

Build 4.0.58.1 introduced some minor improvements to the load speed of the Waiting List __________CONTENT_PLACEHOLDER_____________gt; Mange Client screen but did not fix the 500 error when trying to open and save client waiting list records when the list becomes large.

We have a local workaround for this issue where we create a new waiting list and move all open records via a database update into the new list when it starts breaking. We have had to implement this 6 times since 2019 when we first started using the waiting list to track funding applications.

, I didn’t know about this! Thanks @christie.scott for reporting!

, We have a similar issue trying to load a client profile that has 600 custom table records attached. When the 'Error 500' occurs, the following message is seen in the ELMAH logs:

The maximum message size quota for incoming messages (10485760) has been exceeded.
To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

This was escalated to HIFIS Support and they suggested the following which may be applicable to the Waitlist error.

The quick answers are, YES you simply increase the size of MaxReceivedMessageSize until the error stops (max of 2147483647), and NO there should be no impact to HIFIS but…there is always a limit to memory in which all services rely on.

The more involved answer will require some additional information. Within the config files each ENDPOINT defines a “binding configuration”. In this binding configuration you will need to change the above MaxReceivedMessageSize along with the MaxBufferSize attributes, these two settings should match to whatever you increase the size as all of our endpoints are buffered not streamed (see StackOverflow discussion threads below). For the most part, all of the endpoints use the same binding configuration either WSHttpBinding_Standard (http) or WSHttpsBinding_Secure (https). BUT if you change these config settings it will affect ALL of the endpoints that it references which is NOT really a big deal since all these endpoints are only accessed from within HIFIS. IF you wanted to be cautious, then you could make a copy WSHttpBinding_Standard OR WSHttpsBinding_Secure and rename it to something like WSHttpBinding_Standard_MaxedOut or WSHttpsBinding_Secure_MaxedOut. In these new binding configurations you could then modify them to open up some of the attributes and only use them for endpoints that require additional data throughput.

The caveat to keep in mind above, is all this data is kept in memory that is passed through these endpoints between the HIFIS.WEB and HIFIS.DOMAIN layers. So if there is a performance issue it may require additional memory.

, This does sound similar, but we get a slightly different error message in the logs when this is happening. (The operation has timed out.) We increased our timeout settings to 10 minutes, but the error persists.

, It’s so weird that just copying the data to a new waiting list fixes the problem (temporarily)!

, It sounds like a loading issue, with a solution being something like [Lazy Loading](https://www.imperva.com/learn/performance/lazy-loading/)… or am I way off base?

, Clients with closed waiting list entries have the problem still after we do the workaround of moving open clients to a new list, but once the waiting list entry is closed, we don’t have a need to edit it further.

, Not sure 🤷🏻‍♀️

Reported fixed in 4.0.61.1