D
dbeavon
Guest
I'm wondering if these error messages from the CLR bridge are somehow correlated to the amount of load that is placed on the PASOE agent. I really don't remember any occurrences of this issue prior to the recent deployment of a new application. Perhaps there is a way to synchronize the calls to the CLR bridge so it becomes less busy. With some synchronization, the bridge will think there is only one ABL session running in the process at a time. The REST methods (called via the WebClient) normally take only about five milliseconds but, under heavy load, they might take a bit longer. I suspect that whenever the PASOE agent is under heavy load, there is a greater possibility of overlapping calls to the CLR bridge. Hopefully I will be able to find a workaround. If synchronization is the key, then I should only need to synchronize the ABL sessions within a given agent. Perhaps I can create a table (CLR_IS_BUSY_RESTING) that has a primary key based on the process ID of the agent. Prior to using the CLR bridge, I will create/lock a record associated with the process ID. Then I'll call the REST methods using the CLR bridge. Then I'll release the record again at the end. It certainly isn't a "pretty" solution but I don't have any other ideas at the moment. The REST method calls are pretty critical to our PASOE connection procedure. Hopefully it won't add more than one additional millisecond to do the synchronization. It should still be faster than using OpenEdge.Net.HTTP for these REST methods. (I use that API in other places but our PASOE connection procedures require really fast performance that I can't seem to get without using the .Net WebClient).
Continue reading...
Continue reading...