D
dbeavon
Guest
The repro is certainly the hard part, when it comes to concurrency issues. There have been other issues like this in the past as well. Fortunately they are quite rare. The root problem, based on my investigation of decompiled code, seems to be the unprotected static members within the OpenClient classes (static hashtables, dictionaries, collections etc.) In one of our most important windows services, I eventually had to resort to using critical sections to avoid bugs. The critical sections are placed around code where I create new instances of Connection and AppObject (constructors of Progress.Open4GL.Proxy.Connection and Progress.Open4GL.Proxy.AppObject) because I know that those constructors have never been especially thread-safe (especially in relation to "session-managed" connections to PASOE - which ostensibly should be using totally independent appobjects and connections). Once the concurrency issues arise we start getting the errors (" NoAvailableSessions / Unable to resolve hostname "). They will keep happening for any subsequent attempt to use the openclient. The only way to get things working again is to kill the entire process or app domain. It is clear that internally the process is developing a corruption of some kind - probably in the underlying static members. Another fun example happened in one of our .net openclient applications today. This is an application that connects to PASOE. It started complaining about a NameServerInterruptException, which is especially interesting given that the PASOE architecture doesn't rely on nameserver. Progress.Open4GL.Exceptions.NameServerInterruptException: Connect Failure: Timeout or Interrupt occurred while attempting to communicate with NameServer. (8231) Unfortunately the ToString() implementations of these openclient exceptions have never provided the full callstack. I think the Progress developers went out of their way to obscure the callstack, and/or they neglected to attach inner exceptions whenever an exception was rethrown in the API. To make a long story short, today's exception was yet another example of a corruption in the static members of the API, because after simply restarting the .Net process, things started working again and the exceptions stopped being thrown. The attempts to use the openclient stopped having any more complaints about a " NameServerInterruptException ". Just an FYI for others who use the .net openclient.
Continue reading...
Continue reading...