AppServer Logging: log just the externally called procedure

Posted by bronco on 17-Mar-2017 08:25

Hi,

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.

thanks

All Replies

Posted by Peter Judge on 17-Mar-2017 08:38

I’m not sure if UBNet logging exists in 10.1B.  If it does, that will show the data sent on a request, which may suffice. You do need a high logging level and it’s probably overkill.
 
Depending on the reason why you care, you could add the procedures you know about to the SESSION:EXPORT() list and see if anyone complains when they try to run programs that aren’t in that list.
 
 
 

Posted by dbeavon on 17-Mar-2017 08:39

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:

ASPlumbing,DB.Connects,4GLTrace,4GLTrans

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.

Posted by bronco on 17-Mar-2017 08:52

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...

Posted by bronco on 17-Mar-2017 08:53

btw, the code base is rather large so adding log-manager calls is a last resort.

Posted by bronco on 17-Mar-2017 08:59

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.

Posted by lecuyer on 17-Mar-2017 09:00

I would hesitate to counsel customers to use UBNET logging (added in 10.1C, I think, when we did IPv6 support) for anything except temporary troubleshooting.  It generates TONS of output that is largely incomprehensible to customers and will kill performance as well as fill up disks quickly.  Also, it is a tremendous security hole, allowing clear text access to every aspect of a remote procedure call.

Peter

Posted by bronco on 17-Mar-2017 09:05

ASPlumbing w/ log-level 3 gives the information I need (and more). It's basically the application architecture which is making life miserable here :-)

This thread is closed