D
dbeavon
Guest
>> the HTTP session should close after failing to inititialize. This type of situation not at all uncommon, and shouldn't be treated as the end of the world from a PASOE perspective. Encountering an issue like the "-n" limit is something that I would NOT want to cause a critical or permanent failure in PASOE. It may happen during high load, or in a preproduction environment where the "-n" is set a lot lower than it is in production. I don't mind the temporary failures - as long as I know they will go away again on their own. Ideally the recovery would be automated (either by Progress or by us). We already do something similar to your proposed "refreshAgent" - we trim all the inactive ABL sessions of all the msagents. This happens every half hour. However that approach isn't sufficient to fix this particular issue because the "session manager" has already corrupted itself. The failed HTTP sessions, in this case, appear to be latching on to ABL sessions, and preventing anything from being trimmed via the oemanager API. It is a really ugly predicament. At this stage it is almost as if there needs to be yet another API to manage the failed HTTP sessions as well. But there doesn't appear to be an easy way to determine which of them are the corrupted ones (that had failed to initialize) and target them for immediate expiration. It would be far better if the *PASOE* (session manager) would immediately expire the sessions that had failed to initialize. That seems like the obvious answer and I'd go so far as to call it a bug. I can't imagine the design of PASOE involves allowing HTTP sessions to stick around after they had failed to initialize.
Continue reading...
Continue reading...