为什么使用连接池的 Uodotnet 会超时?
我们正在尝试让连接池与 uodotnet 一起工作,但目前严重失败。当我们关闭连接池时,一切都会按预期工作,但是当我们打开它时,我们经常会遇到以下跟踪输出之一的超时或错误:
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)
或者:
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)
并非所有请求都会失败(例如,当通过负载测试工具运行时, 7/20 请求因超时问题而失败)。
会话似乎仍保留在池中,并且会重复创建会话的新尝试,直到达到超时限制(30 秒)。我们使用的是 uodotnet.dll 版本 2.1.1.7196 和 UniVerse 版本 10.3。在 HP-UX 服务器上运行。我们在正在测试的开发机器上有一个许可证,池中有 10 个可用连接(理论上!)。我们正在编写一个 ASP.Net 网站,并在 Page_Load() 事件中创建一个新会话,该事件将传递给所有 UniVerse 例程,然后在 Page_Unload()/Page_Error() 中调用关闭该会话。
关于我们做错了什么有什么想法吗?我们预计连接池会提高性能,如果池已满,则退回到标准机制,但是非池化版本可以在 20 个并发请求下正常工作,而池化版本经常失败。我们已在应用程序的 web.config 中设置连接池,将 MinPoolSize 设置为 1,将 MaxPoolSize 设置为 10,将其他所有内容保留为默认值。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这是由于缺乏 UniVerse 许可证造成的。我们以为我们有 10 个,但实际上只有 1 个。调用连接池代码请求比我们有权获得的许可证更多的许可证会引发错误,但只有在连接尝试超时后才会发生。
令人困惑的是,使用 UniVerse 10.1 有一个错误,这意味着您可以拥有任意数量的连接,只是最近升级到 10.3 强制执行了您拥有的许可证数量的限制。
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.