PASOE: SESSION:CURRENT-REQUEST-INFO:ThreadId

Posted by fredrik.richtner on 22-Oct-2019 13:41

Hi,

We are in the process of moving from classic appserver to PASOE. With classic appserver we in some cases log the PID of the executing agent i the database. With PASOE we are thinking of logging also the ThreadId of the executing thread of the Multi-session-agent as reported by "ps" command. Our system is running on Linux RedHat 7.7.

When testing we notice that the value of SESSION:CURRENT-REQUEST-INFO:ThreadId is not the same value as reported by "ps" but a number identifying the thread, a number in the span 1-<max-number-of-threads-configured-for-this-multi-session-agent>

Is there a reason why SESSION:CURRENT-REQUEST-INFO:ThreadId differs from the threadid reported by "ps" ?

Does someone know if is it possible to get the threadid as reported by "ps" some other way if we would like to log it ?

/Fredrik

All Replies

Posted by gus bjorklund on 22-Oct-2019 17:16

you could call the c runtime library function gettid() from your 4gl code. but: what will you gain?

Posted by Michael Jacobs on 22-Oct-2019 19:59

I follow your tracking of the classic AppServer's OS process-id as the ABL Session ID.  If you had the real OS thread-id within a multi-session agent, how would you use it?  

Posted by David Cleary on 03-Dec-2019 14:58

Not sure why you are interested in thread ids. They aren't useful for debugging. Sessions are what is important. Threads come and go and do not hold any state.

Posted by frank.meulblok on 03-Dec-2019 16:34

Sessions ("logical threads") can and will hop to different process threads in the same agent ("physical threads") . If you're using shared libraries/dlls that can be a trigger for threading issues.

That's the one case I can think of where you would be interested in knowing the actual threadIDs. Especially if you have debug access to the 3rd-party library the actual threadID is something you should be able to recognise on the library's side to see the whole roundtrip of the call. What I assume to be the sequence number of  the thread within the thread pool the PASOE agent maintains isn't going to be too helpful in that case.

This thread is closed