D
dbeavon
Guest
No problem. I can provide lots of code. I also sent a full repro to tech support already. Here is a sample of the code that gets a "session free" connection. This happens via the .Net openclient API: public static Progress.Open4GL.Proxy.Connection GetConnection() { // Create the connection Progress.Open4GL.Proxy.Connection ConnectionObj = new Progress.Open4GL.Proxy.Connection( @" localhost:8815/.../apsv" , userId: "uuu", password: string.Empty, appServerInfo: "aaa,bbb"); // Change the session model. int MyStateFreeSessionFree = 1; ConnectionObj.SessionModel = MyStateFreeSessionFree; // Time in seconds for the session pool ConnectionObj.ConnectionLifetime = 120; // Return it return ConnectionObj; } Once created, this connection gets reused frequently (and an internal session pool is associated with it, allowing the benefit of improved performance). But after a period of inactivity, once the tomcat session has already expired, then any further use of it will result in a fatal exception. Note that the tomcat session timeouts for PASOE are 30 mins by default. That is when the exception occurs. It is quite consistent. Because of that very large PASOE session timeout of 30 mins, I was really hopeful that I could set a client-side "ConnectionLifetime" of two minutes. You can see that in the code above. The purpose of that is to trim sessions out of the .Net session pool after a period of time. In general the "ConnectionLifetime" works as expected. However, I think the way it generally works is by making one round-trip TOO MANY after the connection lifetime was supposed to have expired. I imagine that is a bug that is unrelated, and has been around for many versions of OE that predated PASOE . While "classic appserver" may have allowed for that final round-trip to be made, PASOE is less forgiving and won't allow any round-trips to be made after it's own 30 minute timeout. Thus far my workaround is to extend the PASOE session timeout indefinitely. Another option is to do my own maintenance of the session pool for the "session free" connection (as shown below). This is something that I'd really rather avoid since (1) I'm messing with implementation details in the openclient that may change in future versions, and (2) there would be a need to do this before each attempt to use a "session free" connection, and (3) even with this session pool maintenance, I'm not guaranteed to avoid the problem since the tomcat server may STILL expire a session in the short amount of time between this code and the attempt to use the connection. // Reserve all the available sessions. int NumberSessionsAvailable = ActiveAppServer.StateFreeConnection.GetSessionPool().availableSessions(); for (int LoopCount = 0; LoopCount < NumberSessionsAvailable; LoopCount++) { // Capture a session and reserve it temporarily Session ReservedSessionObj = ActiveAppServer.StateFreeConnection.GetSessionPool().reserveSession(); SessionsReserved.Add(ReservedSessionObj); } // Immediately release sessions again. foreach (Session LoopSession in SessionsReserved) { ActiveAppServer.StateFreeConnection.GetSessionPool().releaseSession(LoopSession.SessionID); } Anyway, I'm still waiting on someone to reproduce these issues on the Progress side. I'm not sure why it has never come up before now. I don't think we are doing anything too unusual. My hope is that Progress will find a better workaround than the ones I've come up with on my own (or better yet, start fixing some bugs in the APSV transport with PASOE).
Continue reading...
Continue reading...