|
|
You're in the
dotnet web services
group:ThreadAbort Exceptions !! HELP !!
dotnet web services:
with the infamous Response.Redirect without the second parameter. Our web team assures me they've exhaustively gone thru the entire website and taken care of this issue on their end. We still get a handful of these during our busiest times. The stack trace seems to usually point at a webservice not an aspx page. For instance... System.Threading.ThreadAbortException: Thread was being aborted. at System.Threading.WaitHandle.WaitOneNative(IntPtr waitHandle, UInt32 millisecondsTimeout, Boolean exitContext) at System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean exitContext) at System.Net.HttpWebRequest.GetRequestStream() at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at WWDBV2.wsOrders.Orders.GetDetailsByOrderID(Int32 lngIBO, String strSession, Int32 lngOrderID, Boolean blnGetDetails, Boolean blnIncludeDeleted, ViewModes vm) at WWDBV2.eApp.Details.Page_Load(Object sender, EventArgs e) where WWDBV2.wsOrders is a webservice on a different server inside the firewall. Since our webservices are obviously not redirecting anything then that is not the issue. During busy times we might have a 5-600 users consistently using our ordering system. With a 4-cluster web front-end and a 2-cluster webservice middle-tier I'd think we should not have any performance issues. Our SQL Server is a single dual-proc machine (soon to be clustered with another 4-proc box). Our current box rarely goes over 75% CPU and all other stats are fine. The only thing I haven't personally monitered is the network stats. The web cluster is wired to the middle tier on a 100MB connection. The middle tier is connected to the SQL box by a dedicated 1 GB connection so I really cannot imagine bandwidth as a problem here. I'm pulling my hair out here and I already don't have enough of that!! Does anyone have a clue what I could be missing here? The manager in the web department is freaking out on us and insisting that the "data guys" have screwed something up. Thank you for any help ... anything at all.
Yes that has been completely verified but again the stack traces point to
the aborts occurring during a call to a webservice. In fact every single thread abort we are getting is like that. [quoted text, click to view] "Stuart Irving" <spam@stuartirving.net> wrote in message news:%23M2Cw8LVGHA.736@TK2MSFTNGP12.phx.gbl... > Using Response.Redirect or Server.Transfer from within error handling > structures (try / catch) will cause this, but I suppose you've verified > that? > > "Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> wrote in message > news:OG5n8tFVGHA.5092@TK2MSFTNGP10.phx.gbl... >> I've seen many blogs address this issue and always end up associating it >> with the infamous Response.Redirect without the second parameter. Our >> web team assures me they've exhaustively gone thru the entire website and >> taken care of this issue on their end. >> >> We still get a handful of these during our busiest times. The stack >> trace seems to usually point at a webservice not an aspx page. >> For instance... >> >> System.Threading.ThreadAbortException: Thread was being aborted. at >> System.Threading.WaitHandle.WaitOneNative(IntPtr waitHandle, UInt32 >> millisecondsTimeout, Boolean exitContext) at >> System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean >> exitContext) at System.Net.HttpWebRequest.GetRequestStream() at >> System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String >> methodName, Object[] parameters) at >> WWDBV2.wsOrders.Orders.GetDetailsByOrderID(Int32 lngIBO, String >> strSession, Int32 lngOrderID, Boolean blnGetDetails, Boolean >> blnIncludeDeleted, ViewModes vm) at WWDBV2.eApp.Details.Page_Load(Object >> sender, EventArgs e) >> >> >> where WWDBV2.wsOrders is a webservice on a different server inside the >> firewall. Since our webservices are obviously not redirecting anything >> then that is not the issue. During busy times we might have a 5-600 >> users consistently using our ordering system. With a 4-cluster web >> front-end and a 2-cluster webservice middle-tier I'd think we should not >> have any performance issues. >> >> Our SQL Server is a single dual-proc machine (soon to be clustered with >> another 4-proc box). Our current box rarely goes over 75% CPU and all >> other stats are fine. The only thing I haven't personally monitered is >> the network stats. The web cluster is wired to the middle tier on a >> 100MB connection. The middle tier is connected to the SQL box by a >> dedicated 1 GB connection so I really cannot imagine bandwidth as a >> problem here. >> >> I'm pulling my hair out here and I already don't have enough of that!! >> Does anyone have a clue what I could be missing here? >> >> The manager in the web department is freaking out on us and insisting >> that the "data guys" have screwed something up. >> >> Thank you for any help ... anything at all. >> > >
Using Response.Redirect or Server.Transfer from within error handling
structures (try / catch) will cause this, but I suppose you've verified that? [quoted text, click to view] "Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> wrote in message news:OG5n8tFVGHA.5092@TK2MSFTNGP10.phx.gbl... > I've seen many blogs address this issue and always end up associating it > with the infamous Response.Redirect without the second parameter. Our > web team assures me they've exhaustively gone thru the entire website and > taken care of this issue on their end. > > We still get a handful of these during our busiest times. The stack trace > seems to usually point at a webservice not an aspx page. > For instance... > > System.Threading.ThreadAbortException: Thread was being aborted. at > System.Threading.WaitHandle.WaitOneNative(IntPtr waitHandle, UInt32 > millisecondsTimeout, Boolean exitContext) at > System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean > exitContext) at System.Net.HttpWebRequest.GetRequestStream() at > System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String > methodName, Object[] parameters) at > WWDBV2.wsOrders.Orders.GetDetailsByOrderID(Int32 lngIBO, String > strSession, Int32 lngOrderID, Boolean blnGetDetails, Boolean > blnIncludeDeleted, ViewModes vm) at WWDBV2.eApp.Details.Page_Load(Object > sender, EventArgs e) > > > where WWDBV2.wsOrders is a webservice on a different server inside the > firewall. Since our webservices are obviously not redirecting anything > then that is not the issue. During busy times we might have a 5-600 users > consistently using our ordering system. With a 4-cluster web front-end > and a 2-cluster webservice middle-tier I'd think we should not have any > performance issues. > > Our SQL Server is a single dual-proc machine (soon to be clustered with > another 4-proc box). Our current box rarely goes over 75% CPU and all > other stats are fine. The only thing I haven't personally monitered is > the network stats. The web cluster is wired to the middle tier on a 100MB > connection. The middle tier is connected to the SQL box by a dedicated 1 > GB connection so I really cannot imagine bandwidth as a problem here. > > I'm pulling my hair out here and I already don't have enough of that!! > Does anyone have a clue what I could be missing here? > > The manager in the web department is freaking out on us and insisting that > the "data guys" have screwed something up. > > Thank you for any help ... anything at all. >
Hmm no I haven't checked that one. The focus by everyone else has been SQL
Server and I just don't believe that's the problem. Thanks for the input. Sunday night is our heavy processing time so I'll have to wait till then to try this out. [quoted text, click to view] "Patrice" <scribe@chez.com> wrote in message news:u5EmrLOVGHA.4792@TK2MSFTNGP14.phx.gbl... > As this is in WaitOne my first thought would be a timeout. Not an expert > but could it be something like not having enough worker threads to process > incoming requests ? Have you checked performance counters for queued > requests ? > > Please let us know. > -- > Patrice > > "Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> a écrit dans le > message de news: OG5n8tFVGHA.5092@TK2MSFTNGP10.phx.gbl... >> I've seen many blogs address this issue and always end up associating it >> with the infamous Response.Redirect without the second parameter. Our >> web team assures me they've exhaustively gone thru the entire website and >> taken care of this issue on their end. >> >> We still get a handful of these during our busiest times. The stack >> trace seems to usually point at a webservice not an aspx page. >> For instance... >> >> System.Threading.ThreadAbortException: Thread was being aborted. at >> System.Threading.WaitHandle.WaitOneNative(IntPtr waitHandle, UInt32 >> millisecondsTimeout, Boolean exitContext) at >> System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean >> exitContext) at System.Net.HttpWebRequest.GetRequestStream() at >> System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String >> methodName, Object[] parameters) at >> WWDBV2.wsOrders.Orders.GetDetailsByOrderID(Int32 lngIBO, String >> strSession, Int32 lngOrderID, Boolean blnGetDetails, Boolean >> blnIncludeDeleted, ViewModes vm) at WWDBV2.eApp.Details.Page_Load(Object >> sender, EventArgs e) >> >> >> where WWDBV2.wsOrders is a webservice on a different server inside the >> firewall. Since our webservices are obviously not redirecting anything >> then that is not the issue. During busy times we might have a 5-600 >> users consistently using our ordering system. With a 4-cluster web >> front-end and a 2-cluster webservice middle-tier I'd think we should not >> have any performance issues. >> >> Our SQL Server is a single dual-proc machine (soon to be clustered with >> another 4-proc box). Our current box rarely goes over 75% CPU and all >> other stats are fine. The only thing I haven't personally monitered is >> the network stats. The web cluster is wired to the middle tier on a >> 100MB connection. The middle tier is connected to the SQL box by a >> dedicated 1 GB connection so I really cannot imagine bandwidth as a >> problem here. >> >> I'm pulling my hair out here and I already don't have enough of that!! >> Does anyone have a clue what I could be missing here? >> >> The manager in the web department is freaking out on us and insisting >> that the "data guys" have screwed something up. >> >> Thank you for any help ... anything at all. >> > >
As this is in WaitOne my first thought would be a timeout. Not an expert but
could it be something like not having enough worker threads to process incoming requests ? Have you checked performance counters for queued requests ? Please let us know. -- Patrice "Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> a écrit dans le message de news: OG5n8tFVGHA.5092@TK2MSFTNGP10.phx.gbl... [quoted text, click to view] > I've seen many blogs address this issue and always end up associating it > with the infamous Response.Redirect without the second parameter. Our > web team assures me they've exhaustively gone thru the entire website and > taken care of this issue on their end. > > We still get a handful of these during our busiest times. The stack trace > seems to usually point at a webservice not an aspx page. > For instance... > > System.Threading.ThreadAbortException: Thread was being aborted. at > System.Threading.WaitHandle.WaitOneNative(IntPtr waitHandle, UInt32 > millisecondsTimeout, Boolean exitContext) at > System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean > exitContext) at System.Net.HttpWebRequest.GetRequestStream() at > System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String > methodName, Object[] parameters) at > WWDBV2.wsOrders.Orders.GetDetailsByOrderID(Int32 lngIBO, String > strSession, Int32 lngOrderID, Boolean blnGetDetails, Boolean > blnIncludeDeleted, ViewModes vm) at WWDBV2.eApp.Details.Page_Load(Object > sender, EventArgs e) > > > where WWDBV2.wsOrders is a webservice on a different server inside the > firewall. Since our webservices are obviously not redirecting anything > then that is not the issue. During busy times we might have a 5-600 users > consistently using our ordering system. With a 4-cluster web front-end > and a 2-cluster webservice middle-tier I'd think we should not have any > performance issues. > > Our SQL Server is a single dual-proc machine (soon to be clustered with > another 4-proc box). Our current box rarely goes over 75% CPU and all > other stats are fine. The only thing I haven't personally monitered is > the network stats. The web cluster is wired to the middle tier on a 100MB > connection. The middle tier is connected to the SQL box by a dedicated 1 > GB connection so I really cannot imagine bandwidth as a problem here. > > I'm pulling my hair out here and I already don't have enough of that!! > Does anyone have a clue what I could be missing here? > > The manager in the web department is freaking out on us and insisting that > the "data guys" have screwed something up. > > Thank you for any help ... anything at all. >
Well we checked for queued requests last night and there were none during
the busiest 3 hour period of the week. Looks like our SQL server box is really just this busy. We will have to go down a different road. Thanks for taking time to respond! [quoted text, click to view] "Patrice" <scribe@chez.com> wrote in message news:u5EmrLOVGHA.4792@TK2MSFTNGP14.phx.gbl... > As this is in WaitOne my first thought would be a timeout. Not an expert > but could it be something like not having enough worker threads to process > incoming requests ? Have you checked performance counters for queued > requests ? > > Please let us know. > -- > Patrice > > "Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> a écrit dans le > message de news: OG5n8tFVGHA.5092@TK2MSFTNGP10.phx.gbl... >> I've seen many blogs address this issue and always end up associating it >> with the infamous Response.Redirect without the second parameter. Our >> web team assures me they've exhaustively gone thru the entire website and >> taken care of this issue on their end. >> >> We still get a handful of these during our busiest times. The stack >> trace seems to usually point at a webservice not an aspx page. >> For instance... >> >> System.Threading.ThreadAbortException: Thread was being aborted. at >> System.Threading.WaitHandle.WaitOneNative(IntPtr waitHandle, UInt32 >> millisecondsTimeout, Boolean exitContext) at >> System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean >> exitContext) at System.Net.HttpWebRequest.GetRequestStream() at >> System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String >> methodName, Object[] parameters) at >> WWDBV2.wsOrders.Orders.GetDetailsByOrderID(Int32 lngIBO, String >> strSession, Int32 lngOrderID, Boolean blnGetDetails, Boolean >> blnIncludeDeleted, ViewModes vm) at WWDBV2.eApp.Details.Page_Load(Object >> sender, EventArgs e) >> >> >> where WWDBV2.wsOrders is a webservice on a different server inside the >> firewall. Since our webservices are obviously not redirecting anything >> then that is not the issue. During busy times we might have a 5-600 >> users consistently using our ordering system. With a 4-cluster web >> front-end and a 2-cluster webservice middle-tier I'd think we should not >> have any performance issues. >> >> Our SQL Server is a single dual-proc machine (soon to be clustered with >> another 4-proc box). Our current box rarely goes over 75% CPU and all >> other stats are fine. The only thing I haven't personally monitered is >> the network stats. The web cluster is wired to the middle tier on a >> 100MB connection. The middle tier is connected to the SQL box by a >> dedicated 1 GB connection so I really cannot imagine bandwidth as a >> problem here. >> >> I'm pulling my hair out here and I already don't have enough of that!! >> Does anyone have a clue what I could be missing here? >> >> The manager in the web department is freaking out on us and insisting >> that the "data guys" have screwed something up. >> >> Thank you for any help ... anything at all. >> > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |