Hello,
I've looked online, and from what I can tell: there's no information on either of the question. We've run into an issue where a call is issued, but the operation is terminated or cancelled, but there's no way to signal the same to UniVerse.
The other problem we've is: we "believe" we're hitting the maximum connections allowed, which leads to delayed responses on the front end as the call "waits" for the connection to become available again. I wonder is there a way to check the connection availability ahead of time, instead of just sitting there.
Thank you!
Naqqash,
You don't mention whether you are using Connection Pooling or not (which can be very relevant). As a start I recommend checking the timeout and lifetime parameters as a start in the latest .NET documentation which is referenced from rbc.rocketsoftware.com under 'Resources/Product Avalability'.
If using Connection Pooling then U2 database sessions are shared by all client requests with the same worker thread signature. The server connection is NOT persistent but the process persists waiting for a fresh connection and request until it eventually times out due to inactivity. Multiple server processes can be started in parallel to share workload subject to the maximum pool size (as licensed and as configured). In the event of all available server processes being busy and the maximum population size for a connection pool being reached, then new requests will typically queue for service.
If NOT using Connection Pooling then a server process created when a connection is opened is dedicated solely to that client process by a persistent TCP connection. Closing the connection at either end should cause the disconnection to be detectable at the other end. In the case of the server process it will terminate, whereas the client process can check the connection status for a status (see PDF referenced for details).
As a start for Connection Pooling:
- Connection Lifetime
The length of time a connection can be idle before its returned to the pool (connection lifetime).
- Connection Reset
Defines whether or not the current connection will be put in the connection pool when it is closed (connection reset).
- Connect_Timeout
Length of time for a connection request to wait for a connection. default value is 60 seconds..
The overall server process timeout can be configured in 'unirpcservices'.
While it is possible to create an RPC process outside U2.NET to check on server process availability this is typically of limited usage as the status can change in milliseconds and a status as to free capacity at any point in time has little relevance even a few milliseconds later. As a general check on whether the U2 database service is running however it does have some utility - though with the same caution.
I'll also add a caution about TCP resources.
- It's possible to exhaust available TCP resources - and this can affect the ability to create new connections. On bust Windows systems especially I recommend uplifting the number of available concurrent conn4ctions. The TcpTimeWaitDelay would be first on my list - see https://learn.microsoft.com/en-us/answers/questions/482793/tcp-ip-concurrent-connections for more detail Unix server configuration depends upon the O.S and the NIC so I;ll leave that with a general advisory to check and uplift the number of concurrent connections and decrease the timeout.
- Please note that a TCP resource released is generally not immediately avalable for re-use - there is a delay - sometimes a significant delay. You should configure for a peak-busy load witha handsome extra margin.
Hoping this helps - even if only a little.
JJ
