D
dbeavon
Guest
>>I can see that the client request is stuck in "Reading State" and is still latched to one of the Agents How are you monitoring? Is it done from the OEE console? >> ... can eventually lock all Sessions preventing any new requests from being serviced by the agent(s). I'm assuming you mean "ABL sessions"? How do you know they are locked if they say IDLE? I've also noticed in the past that certain ABL sessions in the agent are not candidates to be trimmed via the oemanager, and I've wondered if they were internally locked in some way. I'd be curious to know how you determine when things are locked. FYI, there is a less drastic approach to trimming msagent resources. Using the oemanager REST interface you can trim the underlying ABL sessions, rather than the agent as a whole. I think there is a REST method named "trim idle sessions" or something like that. We call it very frequently (hourly). The msagent process itself will remain intact, and this operation has no impact at all on client applications. What is the impact on the client side? (APSV open client) You haven't mentioned it, so I'm assuming that is not a concern. Perhaps they are short-lived clients. Or perhaps it was the client that had aborted and died in the first place (maybe the user lost network connection or killed the client process). >> Given enough time this can eventually lock all Sessions preventing any new requests from being serviced by the agent(s). There may be a mechanism that would fix the problem automatically in time. Have you deployed the tomcat manager app? ( localhost:8810/.../html) It will show you the HTTP sessions related to APSV. Can you try to expire/detach the sessions from there and see if it clears up your issue? If so, there is a web.xml config file in the conf directory with a "session-timeout" value that is set to 30 mins by default. It will essentially do the same thing as expiring sessions from the manager. The only thing to be careful of is your "session-free"/"state-free" clients if you use them. Oddly enough, those are the ones that are particularly dependent on long-lived HTTP sessions. And if sessions expire after 30 mins of inactivity, then the OpenClient will misbehave the next time the user tries to interact with appserver. It will crash. For this reason we had to increase the session-timeout to 3000 mins or something crazy like that. Is there anything else in the logs? You only showed the "session manager" logs. Many times an error in there is paired with an error in the related "*agent*" log file. Would you please keep us in the loop on the progression of your case? I'm considering opening a similar case as well, but I'm a bit hesitant since I suspect Progress is not that interested in working on 11.7.x anymore. They might just tell you to upgrade to 12.x. Is that an option? For my part, we are probably not going to be ready to upgrade to 12.x for a couple years.
Continue reading...
Continue reading...