I have yet to see one where there was an explanation.
1 Like
2 Likes
And spoil the fun!?
1 Like
I know some of this stuff is frustrating specially if you are the one dealing with the angry users’ but let’s not devolve too far please 
Bees… Honey etc.
Hey All - Happy Friday!!
The Client Lockup error has been corrected and Epicor Cloud customers will get a quick Auto-Update next time the Smart Client is started. This has been distributed to Live, Pilot, and Additional environments running 2024.2.
There are actually a couple of issues at play here. The Client lockup was due to a longstanding race condition in the Client caching code - the error has existed for more than 15 years. With 2024.2, that error was reliably triggered due to Server code changes made in 2024.2 in combination with large amounts of metadata being downloaded during Client logon. The potential for the race condition “lockup” involves Client performance (runtime and hardware), network speed, Server performance, and data packet size.
The quick workaround to the issue was to prevent or reduce the size of the Class Attributes cache download during logon. That is controlled by the MaxClssAttrMRU setting in the Client Sysconfig. Now that we have corrected the software error, you should go ahead and reset the values in the 2 MRU setting - start conservative with 60 for the BOMRU and 40 for the ClssAttrMRU.
Those setting control 2 XML files that are built up as the client is used and forms request metadata from the Server. The metadata for a Service (BO) or Dataset (ClssAttr) is the same regardless of what form needs the information so it is fetched once per Client session and then it is cached in Client memory - not in the disk cache. Every time a form requests the metadata for a Service or Dataset the client tracks that and increments a counter associated with the Service / Dataset reference.
When the Client is closed, we run through the “reference counts” and we build an XML document with the top nn most used Services and Datasets - where nn is the value of the MRU Settings in the Sysconfig. The XML documents are then written out into the Client disk cache so that next time the Client starts, we will pre-load the Metadata into memory so that the Client forms will open faster since the necessary metadata is already on the client.
The Service and Dataset metadata is fetched individually as a form loads and can add several seconds to form startup - a large form like Sales Order makes over 25 different metadata requests as it loads. When the BO and Class Attributes are pre-loaded during logon, we request all nn definitions in one call. While that reduces the overall time required to get the data it does result in a large data payload that needs to be processed and loaded into memory. To prevent the pre-fetch from slowing initial logon, it is done on a background thread where we need to manage concurrency, and it was in that code where we had the potential for a race condition lockup.
Okay - so for all of you who have stuck it out and have read all of this, congratulations!
For all of you tech types that have taken the time to understand this convoluted writeup and are scratching your heads and saying “But Rich, those Sysconfig Settings sound like Most Frequently Used (MFU) and not Most Recently Used (MRU)”. You are correct - our naming of those Sysconfig settings is misleading and you should reward yourself with an extra adult beverage for recognizing that.
18 Likes
Thanks for the update @Rich have a great weekend
2 Likes
That’s wonderful news. I see the update on our environments this morning.
1 Like
Unfortunately the bug is not fixed, either that or a new problem has been introduced. It is now impossibly slow to log in (3+ minutes) and often fails completely:
More errors after logging in:
4 Likes
This seems like a completely different issue although maybe trying to deserialize some of those XML files is causing the error.
If you blow away those files (all of those files) does it go away? Does it happen to everyone
This is after deleting every scap of epicor from the pc and doing a clean reinstall.
System Information
==================
AppServer Connection:
Form Name: ShellMenuForm
Customization Name:
Menu ID:
Software Version: 4.3.200.0
============
Application Error
Exception caught in: Epicor.ServiceModel
Error Detail
============
##!Message:##! Attempted to perform an unauthorized operation.
##!Program:##! Epicor.ServiceModel.dll
##!Method:##! CallWithCommunicationFailureRetry
Client Stack Trace
==================
at Epicor.ServiceModel.Channels.ImplBase.CallWithCommunicationFailureRetry(String methodName, ProxyValuesIn valuesIn, ProxyValuesOut valuesOut, RestRpcValueSerializer serializer)
at Epicor.ServiceModel.Channels.ImplBase.CallWithMultistepBpmHandling(String methodName, ProxyValuesIn valuesIn, ProxyValuesOut valuesOut, Boolean useSparseCopy)
at Epicor.ServiceModel.Channels.ImplBase.Call(String methodName, ProxyValuesIn valuesIn, ProxyValuesOut valuesOut, Boolean useSparseCopy)
at Ice.Proxy.Lib.ClientCacheImpl.GetClassInformation(String token, String additionalTokens, Boolean& objectAccess, String& restrictedColumns, String& restrictedMethods, String& additionalTokenAccess, String nameSpace)
at Ice.Lib.SecRights.SecRightsHandler.GetSecSettings(String BO, Session Session, ArrayList& RestrictedMethods, HybridDictionary& RestrictedColumns)
at Ice.Lib.Framework.EpiBaseAdapter.BOConnect()
at Erp.UI.App.CustomerTracker.Transaction.TransactionLoad()
Yes
2 Likes
@klincecum you guys not seeing this same issues right?
It doesn’t seem to be an issue that has hit everyone.
We’re Cloud/SaaS and never saw this issue. Even after the update over the weekend, our browsers are still fine and my client updated this morning and let me right in.
Wish I could help more, but I can at least attest to it not being an issue that has hit all customers.
2 Likes
The two complaints I am getting from everyone are:
-Impossibly slow/can’t log in at all
-Reading beyond end of stream error
I’m a version behind.
I just get to watch.
3 Likes
We have an urgent/critical ticket with Epicor assigned to their cloud team. All of our users are experiencing issues. I’ll attach some screenshots of the examples
Update: “We are checking the issue.”
4 Likes
Oh no! Odd as we’re cloud too and we’re up and running. However, we still have our clear cache batch file running at user login but plan to remove it soon. So far zero people have reported errors opening Epicor.
I wonder if some patch didn’t quite get installed right for you since it’s affecting every one of your users. That’s just a WAG. Or you angered the Epicor gods. 
We’re now getting server offline too. Bad to worse.
2 Likes
