Seeking architectural advice

  • Thread starter Thread starter Grant Johnson
  • Start date Start date
G

Grant Johnson

Hello,

I've run across an application design problem I was hoping someone may
have some thoughts on.

I have some .NET code (C#) that uses a third party API (using COM
Interop) to convert email messages. The application has to convert
potentially thousands of messages.

Under some circumstances, the API freezes on a (presumably) dud email
message and never returns. I don't get any notifications of the freeze.
I can't have this happen in a production environment, so was trying to
come up with a design to simply log these events and move on.

Initially I was going to run the API conversion in a new thread, and
Join() the thread with a timeout value. This appeared to be simple
enough. However, the API preclude the use of free-threading - I can't
pass the RCW object from the thread it was created on the to the new
joined thread.

I considered creating a new AppDomain to run the conversion in, and
Unload the AppDomain after a reasonable amount of time. However, I'm
not sure how to design this so I can create an AppDomain in the primary
thread, then monitor it for some pre-determined period of time, finally
Unloading it if the API (instantiated in the AppDomain) doesn't return.

I would really appreciate any thoughts anyone may have.

Regards,

Grant
 
Initially I was going to run the API conversion in a new thread, and
Join() the thread with a timeout value. This appeared to be simple
enough. However, the API preclude the use of free-threading - I can't
pass the RCW object from the thread it was created on the to the new
joined thread.
Click to expand...


You can specify MTA apartment to use with thread
Thread newThread =
new Thread(new ThreadStart(ThreadMethod));
newThread.ApartmentState = ApartmentState.MTA;

Thread option is more lightweight. Creating AppDomain will introduce greate
overhead.
 
Have you considered writing your own class to parse email messages? They
are, after all, "Simple" (Mail Transport Protocol). Pure text. And not many
rules.

In the long run, you may spend more time and resources trying to come up
with a workaround for a faulty Interop than you would writing your own
class.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
 
Thanks for the response. Unfortunately we don't have access to the
RFC822 representation of the message. Our only access is via a third
party COM API we don't have any control over.

Thanks,

Grant
 
Back
Top