Can someone point me to sample code that would use Progress.Lang.OERequestInfo?
Here is the documentation:
Apparently it is available via CURRENT-REQUEST-INFO attribute on the session's SESSION handle.
I don't know if it is made available to us, but what I'm most interested in is PASOE-related details. IE. shouldn't I be able to programmatically discover the webapp name that was used to enter into my ABL session? Shouldn't I be able to discover the HTTP session in tomcat that is associated with the current request?
These things would be extremely valuable for certain purposes (audit trails, admin, troubleshooting, etc). Hopefully there is a mechanism to access to those details.
[mention:77d0f2ca82a041a08c26cc89b12b968e:e9ed411860ed4f2ba0265705b8793d05]
Here are a few reference links on this topic. Some of them identify pieces that are applicable to PASOE only.
CURRENT-REQUEST-INFO attribute reference (with example):
documentation.progress.com/.../index.html
OERequestInfo class reference (this lists the properties of the Request you can access):
documentation.progress.com/.../index.html
SESSION handle reference:
documentation.progress.com/.../index.html
Hope this helps,
Tim
Thanks Tim, those are the places where I've been looking for context information that contains PASOE-related details. Unfortunately, it doesn't seem like any PASOE-related details are made available to the ABL session. I'm not sure how to find my related webapp name, or HTTP session ID from tomcat.
Perhaps OERequestInfo is not even the right thing to be looking at, which is why I was hoping to find some samples that show how it is used. It seems to allow some sort of persistent session/context for custom application purposes. (IE. perhaps it has nothing to do with exposing the details about a request that is coming in via PASOE or tomcat )
Thanks Peter, the docs about the "WEB-CONTEXT" handle didn't seem that applicable to APSV in PASOE:
documentation.progress.com/.../index.html
Thanks for the pointers, I will see if there is something in here that will help me to discover the current webapp name and the current HTTP session ID (from my ABL code).
If you would like to know the context information of the request which means the (WebApp,Transport and Unique Request ID) then you can try the MDC feature we added in 12.0 and 11.7.4. You can get it by running the below code
session:current-request-info:RequestID.
For example, a REST request to ROOT WebApplication should give this - ROOT:r:00000001.
Regards,
Irfan
Thanks for the tip Irfan,
I tried some of the "current-request-info" properties like so:
LOG-MANAGER:WRITE-MESSAGE(string(session:current-request-info:AdapterType)). LOG-MANAGER:WRITE-MESSAGE(session:current-request-info:ClientContextId). LOG-MANAGER:WRITE-MESSAGE(string(session:current-request-info:SessionId)). LOG-MANAGER:WRITE-MESSAGE(string(session:current-request-info:ThreadId)). LOG-MANAGER:WRITE-MESSAGE(string(session:current-request-info:AgentId)). LOG-MANAGER:WRITE-MESSAGE(session:current-request-info:ProcedureName). LOG-MANAGER:WRITE-MESSAGE(session:current-request-info:RequestId).
The results are promising for many properties:
APSV MWphYQb9c0Gp+XP07QVT+Q 8 4 31800 app/Production/Maintenance/AppServer/BurdenAltDescMaintenance.p&BrowseFirstPage
?
... However the session:current-request-info:RequestId is always being displayed as "?".
We only use the APSV transport. Perhaps that "RequestId" doesn't work for APSV?
Is there another way to retrieve the current WebApp name (and, ultimately, the HTTP session ID that would be recognized by the tomcat-manager-REST-interface)?
Perhaps I haven't got the correct prerequisites in place for MDC? ( documentation.progress.com/.../index.html ).
Is there a quick-start guide that I can look at for enabling MDC over APSV?
It should run for all transports. All you have to do to get it working in 11.7.4 is
Set the value "REQIDLOGGING" to "y" in openedge_setenv.bat in windows. By default it should be disabled.
That didn't seem to work. In fact I ran procmon while starting PASOE on windows and it never even uses openedge_setenv.bat, so far as I can tell.
I changed both the bat file in my instance (C:\OpenEdge\WRK\oepas1\bin\openedge_setenv.bat) and the one in the DLC directory. I removed the word "rem" in front of "set REQIDLOGGING=y". But there is no change in behavior when viewing the property in question: session:current-request-info:RequestId.
More to the point, will this help me to ultimately discover my HTTP session ID? That is what I'd really like to have.
Worked for me.
[19/03/18@16:05:03.982-0400] P-011480 T-038444 2 AS-7 R-ROOT:a:00000005 AS Application Server connected with connection id: CEC418C079AC70F4F9BA25EF3BD958D6AAE5BBA4F19F.testinst. (8358)
[19/03/18@16:05:04.025-0400] P-011480 T-038444 1 AS-7 R-ROOT:a:00000006 -- (Procedure: 'server2.p' Line:1) hello
[19/03/18@16:05:04.053-0400] P-011480 T-038444 2 AS-7 R-ROOT:a:00000007 AS Application Server disconnected with connection id: CEC418C079AC70F4F9BA25EF3BD958D6AAE5BBA4F19F.testinst. (8359)
Basically, the benefit of MDC is that you will have unqiue information across all the logs. So if you want to track a request failure or execution time, then you can do it using MDC as it can be used as a unique string to search across all the logs.
When I get a chance I will try again. It is odd that you are having me change a "set" statement in the "openedge_setenv.bat" which is a batch file that seems to be never used (at least according to my procmon traces).
(Next time perhaps I will try creating a totally new PASOE instance from scratch. I think the instance I'm using was created back in the days of 11.7.2 or so, and I've applied service packs and hotfixes since then.)
I believe that what you are showing me above is from the agent log for APSV traffic... and I'm really happy to see what appears to to be a tomcat session ID in there (ie. "CEC418C079AC70F4F9BA25EF3BD958D6AAE5BBA4F19F.testinst"). Hopefully if that is available for printing into the agent log then it is also available from our ABL sessions as well. Can you tell me how I can retrieve it (via session:current-request-info or any other way)?
>> Basically, the benefit of MDC is that...
Have there been any slide-decks or videos about MDC yet? It sounds pretty interesting. Whenever something serious goes wrong, I will be happy to be able to correlate it to a tomcat session ID. This may allow an application administrator to *expire* the session via the tomcat manager REST interface. Once these session ID's are expired, that seems to clear away any residual resources that are being held by the PASOE session manager.
Hi David,
If your goal is only get the HTTP Session information in the agent, then you can do it using SESSION:SERVER-CONNECTION-ID. This is basically a unique id for each APSV connection. For PASOE, this would be the HTTP SessionID.
If you were using 12.0 which has MDC enabled by default, you would get something like this in the localhost access log
172.30.1.119 - anonymousUser [2019-03-18T19:22:20.571-04:00] "POST /apsv?CONNHDL=9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3 HTTP/1.1" 200 269 ROOT:a:00000003
172.30.1.119 - anonymousUser [2019-03-18T19:22:20.579-04:00] "POST /apsv?CONNHDL=9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3 HTTP/1.1" 200 243 ROOT:a:00000004
172.30.1.119 - anonymousUser [2019-03-18T19:22:26.221-04:00] "HEAD /apsv HTTP/1.1" 200 - ROOT:a:00000005
172.30.1.119 - anonymousUser [2019-03-18T19:22:26.228-04:00] "POST /apsv HTTP/1.1" 200 252 ROOT:a:00000006
172.30.1.119 - anonymousUser [2019-03-18T19:22:26.233-04:00] "POST /apsv?CONNHDL=E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3 HTTP/1.1" 200 269 ROOT:a:00000007
172.30.1.119 - anonymousUser [2019-03-18T19:22:26.237-04:00] "POST /apsv?CONNHDL=E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3 HTTP/1.1" 200 243 ROOT:a:00000008
172.30.1.119 - anonymousUser [2019-03-18T19:22:26.709-04:00] "HEAD /apsv HTTP/1.1" 200 - ROOT:a:00000009
172.30.1.119 - anonymousUser [2019-03-18T19:22:26.716-04:00] "POST /apsv HTTP/1.1" 200 252 ROOT:a:0000000a
172.30.1.119 - anonymousUser [2019-03-18T19:22:26.720-04:00] "POST /apsv?CONNHDL=EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3 HTTP/1.1" 200 269 ROOT:a:0000000b
172.30.1.119 - anonymousUser [2019-03-18T19:22:26.723-04:00] "POST /apsv?CONNHDL=EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3 HTTP/1.1" 200 243 ROOT:a:0000000c
Similarly, in the agent log you will something like this
2019-03-18T19:22:20.549-0400 023540 023549 2 AS-7 ROOT:a:00000002 AS Application Server connected with connection id: 9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3. (8358)
2019-03-18T19:22:20.570-0400 023540 023549 1 AS-7 ROOT:a:00000003 -- (Procedure: 'server2.p' Line:1) CONNECTION-ID for this request is 9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3
2019-03-18T19:22:20.577-0400 023540 023549 2 AS-7 ROOT:a:00000004 AS Application Server disconnected with connection id: 9F291326E4E965D37F17911BA885F9EF30CD4316B31B.mysin3. (8359)
2019-03-18T19:22:26.228-0400 023540 023549 2 AS-7 ROOT:a:00000006 AS Application Server connected with connection id: E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3. (8358)
2019-03-18T19:22:26.232-0400 023540 023549 1 AS-7 ROOT:a:00000007 -- (Procedure: 'server2.p' Line:1) CONNECTION-ID for this request is E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3
2019-03-18T19:22:26.236-0400 023540 023549 2 AS-7 ROOT:a:00000008 AS Application Server disconnected with connection id: E7C3D67E1C97C56B445ECD98E7E168DD5FBBAE1BD216.mysin3. (8359)
2019-03-18T19:22:26.716-0400 023540 023549 2 AS-7 ROOT:a:0000000a AS Application Server connected with connection id: EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3. (8358)
2019-03-18T19:22:26.720-0400 023540 023549 1 AS-7 ROOT:a:0000000b -- (Procedure: 'server2.p' Line:1) CONNECTION-ID for this request is EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3
2019-03-18T19:22:26.723-0400 023540 023549 2 AS-7 ROOT:a:0000000c AS Application Server disconnected with connection id: EB21B1AAACEF9D360DADECB3919555B3C1EC57E1194D.mysin3. (8359)
Can you help us understand what exactly are you looking for and whats your use-case ? Wanted to make sure we are giving you the right information instead of providing you with the information that might not fit your scenario.
Regarding openedge_setenv.bat, this article says not to modify it:
knowledgebase.progress.com/.../pasoe-is-it-safe-to-modify-openedge-setenv-bat-sh
If PASOE finds a _setenv.sh in CATALINA_BASE/bin then it runs it. We have added openedge_setenv.bat|sh to add some additional environment variables so that file is specific to Progress. The intent of this kbase is If you want to load your own environment variables, then instead of modifying openedge_setenv.sh|bat create your own XXX_setenv.bat|sh and the environment variables mentioned there will be loaded for your application.
The general rule still applies: do not edit the openedge_setenv.x script as it may be overwritten in an update and loose all of the changes. In this one case Irfan is providing the instructions to edit the file in a very specific way - it does not mean that you can edit anything you like in the file. The MDC in 11.7.4 was a back-port into 11.7.4 from 12.0.0 and has to be turned on at the PASOE instance level to operate in the Agent log files. Hence the openedge_setenv.x environment variable.
As a side note: the 12.0.0 logging framework, including MDC, is the default and logging entry formats and configurations change subtly. Its a good idea to check the documentation set and migration information when beginning to work with version 12.
FYI: openedge_setenv.x is executed from the Tomcat startup's setenv.x found in the DLC/servers/pasoe/bin/ directory. The setenv.x scripts scan for, and execute, any *_setenv.x files found in the instances's bin/ directory (both OE supplied and ones you supply for your product's startup). So, you will not find a direct reference to it.
>> Can you help us understand what exactly are you looking for and whats your use-case ?
Hi Irfan, We are finding that certain remote openclients are able to create ad-hoc requests for APSV data that may run indefinitely long (eg. for three hours). But the client-side openclient HTTP timeout can be much shorter than that ... so the openclient will give up and close the connection (eg. after only one hour).
At that point the session manager notices that the remote connection was closed, and this fact is printed in the session manager log. It includes the tomcat session ID (but until now I've never known if/how there is a way to retrieve the session ID from custom ABL).
Despite the fact that the remote openclient is long-gone, (and the session manager was made aware of the fact) the tomcat session ID remains intact. And it holds onto resources within the ms-agent process. Based on my observations, even after the ABL session finally finishes its work (in three hours), it does NOT appear like the session manager wants to release hold of the ABL session (via the act of trimming-active-sessions for example). In other words, that session's resources seem to be "pinned" as long as the tomcat session ID remains intact (as viewed in the tomcat manager webapp for HTTP sessions). As a side note, our tomcat session timeouts are extremely long (24 hrs) for the sake of compatibility with the legacy "state-free/session-free" APSV connections.
To make a long story short, expiring tomcat session ID's seems to be the key to getting PASOE to release hold of certain resources within the ms-agent process. If the tomcat session ID is orphaned, and remains intact for 24 hours then there will be "pinned" resources in the ms-agent for that entire time.
Initially I am hoping to simply accumulate session ID's from these ad-hoc requests (based on the a list of usual suspects, as identified from "session:current-request-info:ProcedureName") . And the session ID's will be cross-referenced periodically against the tomcat manager REST interface. And any of these ad-hoc sessions that are still present after an hour will start triggering emails to the application administrators (along with the related tomcat session ID's and instructions on how to perform clean up via the tomcat "manager" webapp).
Hopefully this is clear. Let me know if not. I'm not trying to make things harder than they need to be. The problem is always with the greedy, ad-hoc requests from power users. I think there are some theoretical ways to handle this in ABL too (STOP-AFTER) but it doesn't seem to work reliably. I'd rather inform PASOE about the HTTP session's expiration, and force PASOE to deal with those runaway ABL sessions.
Thanks,
David