I created a support ticket for this question, however I still wanted to share it here as the audience might be different.
Scenaro: We recently implement Event Handling in our ooABL code to handle writing error messages to a common object between the layers of our logic (Workflow manager -> Business Layer -> DAL). When the compiled *.r files are ported to an appServer environment, we find that with each subsequent incoming message (xml-based) from .net client, the response time to the client increases (typically doubling in time). For example, client #1 sends message #1 to the appServer and receives a reply in 2.1 seconds. Client #1 then sends message #2 (the same message body/format as sent in message #1) and the appServer replies in 2.3 seconds. Client #1 sends message #3 and the reply comes in 4.4 seconds. Message #4 replies in 8.9 seconds, etc.
These results leads me to believe there is a memory leak in our code that is allowing an instantiated object from the previous message (that contains an Event:Subscribe call) to persist after the message has been processed by appServer logic. Thus, when subsequent messages come in and and an event is published, the previous event handlers that subscribed to this event are also being fired.
It would be ideal if I could see what instantiated class objects are still in scope after a message has been successfully processed and the DELETE OBJECT calls have been made to destroy the objects. I would speculate our code has missed a DELETE OBJECT call and an object (or more) are still in scope.
I am open to any advice and constructive comments you care to share. Thank you for your review.
Start from SESSION:FIRST-OBJECT and go from there using the NEXT-SIBLING reference of the Progress.Lang.Object .
When subscribing to events, you need to keep in mind, that that actually creates a reference to the event handler at the instance that raises the event.
Have you looked at traversing the SESSION Object tree? Something like ...
define variable oTemp as Object no-undo.
oTemp = session:first-object.
do while valid-object(oTemp):
oTemp = oTemp:next-sibling.
end.
You can also see object creation and deletion (explicit via DELETE OBJECT and via garbage collection) using the LOG-MANAGER's DynObject.* LOG-TYPE.
If you're using Architect / Dev Studio you can very easily enable this logging in the launch configurations.
-- peter
Thank you for the reminder Mike. Greatly appreciated!
Woo hoo, Peter! Thank your for the snippet and the pointer to support within OEA for this question. I am going to review both now and share with my colleagues.
I am not suprised that you and Mike were the first to reply. I have learned through several years of lurking these forums that the comments from the two of you are generally worthwhile and educational. My thanks to you both.
This was successful Peter. I modified your example, based on the example found in OpenEdge Development: Object-Oriented Programming.
DEFINE VARIABLE myObj AS CLASS Progress.Lang.Object NO-UNDO.
myObj = SESSION:FIRST-OBJECT.
REPEAT:
IF myObj EQ ? THEN LEAVE.
MESSAGE myObj:GetClass( ):TypeName VIEW-AS ALERT-BOX.
myObj = myObj:NEXT-SIBLING.
END.
Thank you very much sir. I was able to very quickly identify the root cause and will be coding a solution.