Just a simple quick post, one of the reason for AOS appearing as "Dead" on the "Online users" form could be the database is giving error (Eg. Database transaction log is full).
A good place to look at is the Event Log on the AOS, it should give you the error message indicating what happened there.
hi Peter,
ReplyDeleteWe've seen the 'dead' status of an AOS in combination with deadlock entries in the application log on that AOS server.
I've found a post (https://community.dynamics.com/ax/f/33/p/35869/63023.aspx, dated over 3 years ago) where similar behavious is experienced.
Was it 'only' the transaction log being full in your situation? Or did you find deadlocks in the application log as well?
This blog post (http://blogs.msdn.com/b/daxis/archive/2008/01/20/dynamics-ax-4-0-session-management.aspx?Redirected=true) explains why a AOS would get the 'dead' status in Ax 4.0.
I could assume this hasn't changed in Ax2012, but then the question arises why the AOS would not be able to ping the DB server, while it has a background thread to do this.
Here's my theory:
we've limited the amount the AOS service can use to 75% (the maxMemLoad setting in the server config can do that).
When you then try to log on to an AOS that reached 75% of the memory usage, the AOS won't allow your session (and shows an appropriate message informing you about the max memory condition).
My (assumed) point:
If this background thread that is pinging the DB is also experiencing this max. memory condition situation and is unable to create an Ax session,
it is unable to ping the DB and that could explain why the AOS is presumed 'dead' while it becomes 'alive' again little later (when memory is free-ed again, after x minutes).
I don't see a direct link with the deadlocks in the eventlog though :-(
Lots of 'if's and assumptions though ... if anyone got any ideas or theories about this behaviour, please share.
kind regards,
Tom