I'm bit stuck with logging. I want to see what .p's are run from a client, just that. 4GLTrace doesn't work for since that displays everything which is run in a request.
I'm on 10.1B here (really) so current-request-info is unfortunately no option.
Would it work to use a different logging entry type? Or a different logging level? For each entry in the logs, it tells you what log entry type was in effect and what logging level caused the entry to be written. So you can decrease the logging level until you stop seeing the excessive logging, and you get information in less detail.
if decreasing the logging level does not work, you can try a different logging entry type. I normally use these:
But if 4GLTrace is too noisy, I take it out altogether (since "ASPlumbing" will show when a round trip to appserver is started and stopped, along with the external .p that is being called.)
As a last resort, you do your own custom logging and rely on that instead of the built-in log entry types. Custom logging involves calling methods on the LOG-MANAGER. When doing your own custom logging, you can make it as sparse or verbose as needed.
Hope this helps.
4GLTrace generates wwwaaayyy to much data. I'm trying to figure out something in a production environment with about 500 state-aware agents...
But the reason for the question is: in our production we intermittent ran into an agent which for some reason performs dramatically slow for no apparent reason. I'm trying to see if I can smartly figure out what this appserver have run before becoming so slow...
btw, the code base is rather large so adding log-manager calls is a last resort.
Ah, wait a minute. I see a lot of calls which I confused for calls within the session but are actually calls from the client (we're talking state-aware here) to persistent procedures on the server.
ASPlumbing w/ log-level 3 gives the information I need (and more). It's basically the application architecture which is making life miserable here :-)