Thread was being aborted.
Application Type
Traditional Web, Reactive, Service
Service Studio Version
11.53.8 (Build 60995)
Platform Version
11.12.1 (Build 30218)

Please help to resolve this issue.
Functionality: An email gets sent by attaching few documents. These documents are fetched from the REST API one by one.
Getting error with message "Thread was being aborted."
Logs show that source is "REST (Consume) ".
This issue occurred for only 3 hours in Production for around 15 times. But this issue should not happen in future so, trying to find the root-cause.
Due to this issue end users are getting affected.
Stack: Thread was being aborted.
   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   at System.Net.ConnectStream.ProcessWriteCallDone(ConnectionReturnResult returnResult)
   at System.Net.HttpWebRequest.WriteCallDone(ConnectStream stream, ConnectionReturnResult returnResult)
   at System.Net.ConnectStream.CallDone(ConnectionReturnResult returnResult)
   at System.Net.ConnectStream.ResubmitWrite(ConnectStream oldStream, Boolean suppressWrite)
   at System.Net.HttpWebRequest.EndWriteHeaders_Part2()
   at System.Net.HttpWebRequest.EndWriteHeaders(Boolean async)
   at System.Net.HttpWebRequest.WriteHeadersCallback(WebExceptionStatus errorStatus, ConnectStream stream, Boolean async)
   at System.Net.ConnectStream.WriteHeaders(Boolean async)
   at System.Net.HttpWebRequest.EndSubmitRequest()
   at System.Net.HttpWebRequest.GetResponse()
   at ssSME_Insurance_IS.CcAzureTomcatWebService_QnB.ActionPostRetrieveDocument(HeContext heContext, ICcAzureTomcatWebService_QnBCallbacks _callbacks, String inParamLoginId, String inParamAuthorization, STRetrieveDocumentQuoteStructure inParamRequest, String inParamAuthKey, STRetrieveDocumentResponseStructure& outParamResponse) 



Hello Nagesh,

Can you tell us a bit more about the way these emails are generated? Are they being created and the files being fetched while a user interacts with the application, or does it all run inside a Timer?

What about the API itself? Do you have access to any logs on that end? Can you confirm if it processed the requests successfully and returned the expected responses?

Hi Afonso,

In application a button is provided to send a single email. 
In this button, logic for composing the email and fetching the documents from API is present.
User can not interact with the application until email does not sent successfully.

We don't have access to any logs from API side.



Do you know the average response times for the API and the email generation itself? Have any application users mentioned the process being slow?

Without more information, I can only speculate, but my advice would be to try and encapsulate this logic in an asynchronous, retriable fashion.

I believe the logic might be too heavy to be attached to a synchronous operation started by a user. I've had a similar issue on a previous project - during an approval flow, a user would click a button stating their decision, and we'd generate an email with a PDF attachment created by SQL Reporting Services. Sometimes this attachment could take 60-90 seconds to generate, and we'd see "Thread was being aborted" errors. We had to refactor the logic to add this generation to a queue, and we'd use a Timer to process the queue and send emails/generate attachments one by one. The upside of this is that since we had the data inside an Entity, we could reprocess any failed emails automatically, without the user having to intervene.

Hi Afonso,
Average response times for the API is 20 seconds.
No Idea on time required to generate email.
Have any application users mentioned the process being slow = Yes.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.