Random clients crashes and/or AOS server instability


Recently I had the problem that random clients crashed in different parts of the application.


The following error message was shown:

Communication error:The server needs to free resources. Your session has been terminated.

In the application event log on the AOS server warnings with the event ID 180 were logged:

Object Server 01: RPC error: Client provived an invalid session ID xx

In other instances users get error messages

“Error executing code: Insufficient memory to run script.”.
The system becomes unusable after a while; only a restart of the AOS service resolves the problem temporarily. The following two event log entries appear frequently and normally together at the same time:


Dialog issued for client-less session 1: The upper limit of open cursors for Microsoft Dynamics has been exceeded (90). Use the -OPENCURSORS parameter, or modify the X++ code.


RPC error: Exception 3221225495 occurred in session 1


Increasing the number of open cursors doesn’t make a difference.


In all these cases it has always been identified that too high values in the AOS Configuration on the Database Tuning tab is specified. For example in one instance we had:


  • Array Fetch Ahead was set to 1

  • Maximum open cursors was set to 500

  • Max Buffer size was set to 100

These parameters should not be changed unless there is a real need behind it.
My experience shows me that changing these parameters can lead to AOS stability problems.


Finally we could solve the problem by just setting back the parameters to the default values (blank) which are:


  • Array Fetch Ahead: 100

  • Maximum open cursors: 90

  • Maximum Buffer size: 24 (KB)

It is quite common to increase the maximum buffer size, however the value specified needs to be in Kilobytes (e.g 28) and not bytes (28000), and it is often seen as the root cause of most AOS instability issues as we find the values are specified in thousands.


Please find additional information here: http://msdn.microsoft.com/en-us/library/aa569634(AX.10).aspx


If the maximum buffer size values are specified as the default or within a small increase, and yet you get the error “Error executing code: Insufficient memory to run script.” then review tis link for other causes and solutions.

Comments (5)

  1. Chris Rothery says:

    I’ve been suffering from exactly your first error for the last week or so so this post speaks directly to me 🙂

    Unfortunately we don’t have any settings for database tuning but we’re still having random client disconnects (at times they mention resource, or just that the AOS can’t be contacted) to the point where it’s hard to compile the AOT or do a large source code check in as it will disconnect and the client will crash before it completes.

    We have multiple 2009 AOS’s on the same server (one per developer) and sql server on the same box (originally the theory behind this was to gain performance over our old setup as we don’t do heavy database use – our developers companies aren’t very big etc).

    Any other tips for improving stability ?

    Thanks

  2. You might got into this situation before… you are working in the Dynamics AX Client as usual and all

  3. Hi Chris

    There are soem other reasons that may cause stability issues with AOS.

    We will proceed with publishing information on this topic in future.

    The latest one is here:

    http://blogs.msdn.com/emeadaxsupport/archive/2009/06/08/why-does-the-server-need-to-free-resources-and-terminates-client-sessions.aspx

    Regards,

    Daniel

    (member of the EMEA Dynamics AX Support Blog Team)

  4. Blitz says:

    See below

    support.microsoft.com/…/913184

    ————————————————–

    The above RPC fix only applies if you are running Windows Server 2003 R2 SP1. The fix is included in Windows Server 2003 SP2 as is recommended.

    Other issues that could lead to plausible randon anomalies especially if you have multiple environments (Test, Staging, Development, production) and are accessing all these from the same client, and they all share the same copy of the AX database, than review http://blogs.msdn.com/b/emeadaxsupport/archive/2010/01/25/identical-ax-2009-auc-file-created-for-multiple-ax-installations.aspx for more details.

    –Anup