Greetings
Moving on from my earlier questions (that some kind person marked "answered").
The system I am working on at the moment has a .net application that talks via an appserver to a front end OO ABL program that talks via another appserver to another OO ABL program that accesses the database (please don't ask me why).
The problem is that for at least 3 years (possibly longer), there has been a gradual build up until the internal appserver agents start to crash and the external report a 3244 error (too many temp-tables). Given that the "too many" is 32767, I suspect that there might be an issue :)
After the system (and the appservers) are restarted, the problem goes away...
For a while.
I've narrowed the problem down to one single temp-table that is used in just about every single transaction in the system. The external programs repeatedly run a back end program to check on a user's and customer's credentials. To put it in context, looking through the external appserver's log I saw that the credential checking program was run from the external app some 226 times in less than a minute (it's a /very/ busy WAN based system).
I've checked for any dynamic temp-tables right across the entire system - there are none.
I've checked for persistent procedures right across the entire system. There are only two and neither of them use the table in question.
One of the things that is bothering me is having the two appservers in the equation - not something I'm familiar with. The external one runs as state-free whilst the internal one runs as stateless. Is it possible that the internal appserver (the one that fails) is somehow not cleaning up the temp-table? It looks like every time the object that defines the temp-table is instantiated, it is somehow "staying there" and adding to the load until it eventually crashes.
Has anyone any experience with this type of setup? Anyone who would like to suggest any possibilities I should be focussing on?
TIA
Nigel.
Well, in the previous thread you didn't mention you were using OO code ;)
Class instances behave a lot like persistent procedures when it comes to this: They stick around until deleted, and so do any static temp-tables they define.
Main difference is that classes can get garbage collected as well as being explicitly deleted, and starting with 10.2B they can get cached for faster re-use instead of being completely removed.
The class caching can be ruled out by starting the appserver agent with -reusableObjects 0 startup parameter.
The article How to detect ABL Memory Leaks with Dynamic Objects Logging Julian already referred to in the previous thread can also be used to detect leaking classes, assuming the DynObjects.Class subtype is being logged.