CLR存储过程线程异常

Question

I have the follow code that works in an exe and even works on small xml files in the CLR but once they get larger than 10mb I get a thread abortion error. Is there something I need to configure in SQL Server?

Try

    sStream = HttpRequest.GetRequestStream()
    sStream.Write(baByteArray, 0, baByteArray.Length)
    sStream.Close()
    wrWebResponse = HttpRequest.GetResponse()
    sStream = wrWebResponse.GetResponseStream()
    Dim readStream As New StreamReader(sStream, System.Text.Encoding.UTF8)
    strXmlResponse = readStream.ReadToEnd() ' Errors out here
    strXmlResponseDoc.LoadXml(strXmlResponse)
    wrWebResponse.Close()
    sStream.Close()
    readStream.Close()

Catch ex As Exception

    SqlContext.Pipe.Send(ex.ToString())
    clsE.LogError(ex.ToString())

End Try

Error message:

System.Threading.ThreadAbortException: Thread was being aborted.
 at System.Threading.Thread.AbortInternal()
 at System.Threading.Thread.Abort(Object stateInfo)
 at   System.Data.SqlServer.Internal.ClrLevelContext.CheckSqlAccessReturnCode(SqlAccessApiReturnCode eRc)
 at System.Data.SqlServer.Internal.ClrLevelContext.SendMessageToPipe(String message, SmiEventSink eventSink)
 at Microsoft.SqlServer.Server.SqlPipe.Send(String message)
 at MacCLR.MacClass.RequestXml(String strXmlToSend)
 at MacCLR.StoredProcedures.ProcessShippingXML_1(String iOrderNumb, String iXmlFilePath, String iXmlFileName, SqlInt32& iResult, SqlString& iResult_String)

Answer 1

Every object you create that implements the IDisposable interface needs to be in a Using block. That ensures the object is cleaned up promptly, regardless of exceptions. That includes the two streams, the WebResponse, and the StreamReader.

This is especially critical for code that's running inside of the SQL Server process.

Answer 2

After putting in a using block for each of the IDisposable interfaces I was still getting an error about but it led me to realize that it is a 32 bit SQL Server installation and from what I read it handles CLR memory differently than 64-bit. Using the ;-g384 startup parameter at least bandaided the error until I can implement a more robust solution. Thanks for the help.