Why does Uodotnet with Connection Pooling timeout?

Question

We're trying to get connection pooling working with uodotnet and currently failing miserably. When we turn connection pooling off everything works as expected, but when we turn it on we often get timeouts or errors with one of the following trace outputs:

2011-03-28T15:09:28 System.Exception: Non-negative number required.
Parameter name: millisecondsTimeout Source: UniObjects Class Method: Boolean ObjWait(Boolean, Int32, System.Object)   at System.Threading.Monitor.ObjWait(Boolean exitContext, Int32 millisecondsTimeout, Object obj)
   at System.Threading.Monitor.Wait(Object obj, Int32 millisecondsTimeout, Boolean exitContext)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniObjects.OpenSession(String hostname, Int32 port_number, String userid, String password, String account, String service, Int32 min_poolsize, Int32 max_poolsize)
   at OurNamespace.UniversePage.OpenSession()
   at OurNamespace.UniversePage.Page_Init(Object sender, EventArgs e)
   at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e)
   at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
   at System.Web.UI.Control.OnInit(EventArgs e)
   at System.Web.UI.Page.OnInit(EventArgs e)
   at System.Web.UI.Control.InitRecursive(Control namingContainer)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Or:

2011-03-28T15:09:32 System.Exception: [IBM U2][UODOTNET - UNICLIENT][ErrorCode=81015] The connection has timed out Source: UniObjects Class Method: IBMU2.UODOTNET.UniSession FindSession(Int32)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniPool.FindSession(Int32 pTimeout)
   at IBMU2.UODOTNET.UniObjects.OpenSession(String hostname, Int32 port_number, String userid, String password, String account, String service, Int32 min_poolsize, Int32 max_poolsize)
   at OurNamespace.UniversePage.OpenSession()
   at OurNamespace.UniversePage.Page_Init(Object sender, EventArgs e)
   at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e)
   at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
   at System.Web.UI.Control.OnInit(EventArgs e)
   at System.Web.UI.Page.OnInit(EventArgs e)
   at System.Web.UI.Control.InitRecursive(Control namingContainer)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Not all the requests fail (for example, when run through a load testing tool, 7/20 requests failed with the timeout problem).

It seems that the sessions are remaining in the pool and new attempts to create a session are repeating until the timeout limit is reached (30 seconds). We're using uodotnet.dll version 2.1.1.7196 and UniVerse version 10.3. running on an HP-UX server. We've got a single license on the dev machine we're testing on with 10 connections available in the pool (theoretically!). We're writing an ASP.Net web site, and we create a new session in the Page_Load() event which is passed to all UniVerse routines and then call close on the session in Page_Unload()/Page_Error().

Any ideas as to what we're doing wrong? We expected that connection pooling would improve performance, falling back on the standard mechanism if the pool was full, but whereas the non-pooled version works fine with 20 simultaneous requests, the pooled version regularly fails. We've set the connection pooling on in the application's web.config, setting MinPoolSize to 1 and MaxPoolSize to 10, leaving everything else at the defaults.

Answer 1

This was due to a lack of UniVerse licences. We thought we had 10, but in fact we only had 1. Calling the connection pooling code asking for more licenses than we're entitled to throws an error, but only after the connection attempt has timed out.

Just to confuse matters, using UniVerse 10.1 there was a bug which meant you could have as many connections as you liked, it was only a recent upgrade to 10.3 that enforced the limit of the number of licences you owned.