We have a web api controller in c# from which I create a background thread to call a long running method in a dll. There is a wrapper class for that DLL, which gets a delegate as a parameter that eventually gets called from the dll to update a message queue(MSMQ) by the status update messages.
[HttpPut]
public HttpResponseMessage DoSomeLongRunningWork([FromBody]MyRequest myReq)
{
//Start thread to do some work
ThreadStart myThreadStart = delegate { DoSomeWork(myReq); };
Thread thread = new Thread(myThreadStart);
thread.IsBackground = true;
thread.Start();
}
private void DoSomeWork(MyRequest req)
{
//Make component call with setting and callback function
ComponentInterface.DoWork(req,UpdateQueue);
}
public void UpdateQueue(string sQueueId, IProgressResponse response)
{
String sProgressMsg = JsonConvert.SerializeObject(response);
// Writes the response to the queue with the unique Id
MSMQEnqueue(sQueueId, sProgressMsg);
}
// Retrieves or Creates private queues with the key and sends a message to it
public static void MSMQEnqueue(string sKey, string sMessage)
{
MessageQueue queue = GetOrCreateQueue(sKey);
try
{
Message message = new Message();
message.Body = sMessage;
queue.Purge();
queue.Send(message);
}
finally {
queue.Close();
queue.Dispose();
}
}
the delegate which is passed down to the wrapper and is responsible for updating the message queue looks like this:
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate void UpdateProgressDelegate(string sQueueId, IProgressResponse response);
I have another end point to read the messages from the message queue and show a progress bar with the latest progress. This works for the most part but sometimes I get this exception:
First-chance exception at 0x000007fef2096a15 in w3wp.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
This is totally sporadic and doesn't break at the same place. sometime it breaks at the 25% of progress sometimes 89%. I can't quite tell what's wrong because the visual studio debugger doesn't break where the exception happens.
Any help is greatly appreciated.
Update
It turns out the problem has to do with the number of times the callback is being called from the dll to write to the MSMQ. not sure what the bottle neck/ limitation is though. Since every message purges and removes whatever message there is in the queue before writing to it.
User contributions licensed under CC BY-SA 3.0