Hi Alexander,
I've seen you question is this blog and indeed I'm almost sure we had the same issue on a customer of us using AX2009 with RU7.
I opened a case at Microsoft and got the following answer. Implementing the workaround of MS solved our issue and now since about 6 month we never got the same problem again.
Here the statement of the MS engineer.
-----------------------------------
“My understanding of the issue here is that a particular AOS is showing the wrong label values for some labels. Restarting the AOS temporarily resolves the problem, but of course this involves interruption to the users and the problem will still reappears some time later.
There was an issue I’ve seen before which could mean that labels for non-user languages may randomly become unavailable until the AOS is restarted - to give a specific example: a customer that works primarily in German, all of their users may log in with the German language, but for some of their customers they print invoices in French or English, in an environment like this the French or English labels may periodically disappear on one AOS, so if a user tries to use this language then they just see label codes (like @SYS12345) instead of the expected French or English text values.
The basic label mechanisms work like this: a client may require some labels for an application object which a user has accessed - the client will make a request to it's AOS for those labels, the AOS will check it's own label cache to see if it already has the labels, and it will also check how old it's cache is, if it's older than 5 minutes it will go back and re-read the labels from the application folder - the specific reading mechanism is quite complex as in different scenarios we may be reading from a combination of the *.ald, *.alc, *.ali and *.alt files so I won't go into that in any detail here.
When the AOS has it's cache it will send a copy to the client and the client will keep that and use it for any labels that it needs to show. Although the AOS has this 5 minute lifespan on label cache, the client doesn't have this, it will just keep it's cache until either the client is closed, or until some more labels are needed that it doesn't have in it's cache, then it will make a new request to the AOS and receive a new cache. This is the normal basic process that happens all the time as clients consume labels.
Further on from this there are other "special" label operations which may occur - specific events which cause an AOS to re-evaluate it's current label caches and switch from one method of reading to another (for example it may switch from reading labels from *.ali and *.ald to only from *.ald and rebuild the *.ali), it is this area of "special" operations which I suspect may contain the cause of your issue. They are triggered when the last instance of Classes\Label for a specific language is disposed of. The kernel class Classes\Label (and SysLabel which extends from it) is the same class which is used internally within the AOS when it is working with labels. This means that when working with the Label class in X++ code, it is possible that you can be triggering off these internal "special" label operations within the AOS without realizing it. One of my articles touches on this same subject, although it is about flushing newly created labels, the basic principle still applies to other scenarios, as I have explained above, some specific use of Label class can influence the same type of operations. There's a link to the article below if you would like to read it:
blogs.msdn.com/.../how-label-flushing-works-under-the-hood.aspx
My recommendation to prevent labels from disappearing in this way is to implement a small code suggestion. In my description above I described how certain "special" label operations are triggered when the last instance of the kernel label class is disposed for a particular language - so when the final instance of label class for "de" is disposed in memory then the AOS will make some operations which refresh the language in a much deeper way than it would normally do. It is an unusual variation of this deep type of refresh/flush that I believe could be responsible for the problem in your environment - as from my analysis of the kernel this is the critical point at which an AOS may completely re-evaluate the label's it's reading.
We can prevent all of these "special" operations from happening by always keeping an instance of the label class for each language instantiated in memory in the AOS session. This is not 100% guaranteed to prevent the issue from occurring - as this issue is not reproducible, it is not possible to test whether this will definitely resolve it, however we can see that it is relevant to the behaviour we're seeing, as I've explained above, and so if it is possible to implement such a change so that we could see whether it resolves the issue then that would be great.
My code suggestion for you to do this is taken from the article I mentioned earlier, you can see that this is a very low impact change, it does not touch any business logic, we're simply instantiating some instances of the label class within the AOS main session when each AOS starts. To make the change: if we add some extra declarations to Classes\Application.ClassDeclaration() like this:”
Disclaimer:
“Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. This mail message assumes that you are familiar with the programming language that is being demonstrated and the tools that are used to create and debug procedures.”
Label label_de;
Label label_enUs;
Then I add some extra code to Classes\Application.new() so that we instantiate the languages once in the AOS session (debugging this I see we actually instantiate twice in each AOS session, but that doesn't cause a problem):
If(session.clientKind() == ClientType::Server)
{
label_de = new label('de');
label_enUs = new label('en-us');
}
----------------------------------------------------------