Author |
|
ramiss Newbie
Joined: 18 March 2009 Location: United States
Online Status: Offline Posts: 5
|
Posted: 23 February 2012 at 1:40am | IP Logged
|
|
|
Hello,
First of all let me say that we love your components and use them in several commercial products.
Our latest endeavor is to create a tool that can scan IMAP accounts for corrupt messages and then delete them. It is working quite well but I thought I would give you a heads up about an issue we had to learn the hard way.
In a nutshell... If you call imp.BeginDownloadEnvelopes and then the server disconnects due to a corrupt message we have discovered that you MUST then call imp.EndDownloadEnvelopes BEFORE reconnecting.
If you don't cleanup every Begin with an End then the final imp.EndDownloadEnvelopes call just hangs indefinitely. I'm not sure if this is a bug or intended behavior.
If it is intended then what would be nice is to have a method to loop through all of the Begin threads and End them - Abort() does not appear to do this. At the very least a method to see if a Begin thread is still active even after a disconnect.
Any thoughts or ideas are very welcome.
Thank you!
Richard
|
Back to Top |
|
|
Alex AfterLogic Support
Joined: 19 November 2003
Online Status: Offline Posts: 2206
|
Posted: 23 February 2012 at 2:17am | IP Logged
|
|
|
Every BeginXXX MUST be followed by the corresponding EndXXX. It's a strict rule which has nothing to do with IMAP, network connections or anything like that. It's how async threading works in .NET.
Regards,
Alex
|
Back to Top |
|
|
ramiss Newbie
Joined: 18 March 2009 Location: United States
Online Status: Offline Posts: 5
|
Posted: 23 February 2012 at 1:55pm | IP Logged
|
|
|
Hi Alex,
Thanks for that information. Since we are essentially forcing disconnects with our application is there any method to monitor whether a Begin statement has started and is waiting for an End statement?
Thanks for any info.
Richard
|
Back to Top |
|
|
Alex AfterLogic Support
Joined: 19 November 2003
Online Status: Offline Posts: 2206
|
Posted: 25 February 2012 at 2:56am | IP Logged
|
|
|
It should work naturally this way if you follow the patterns of async programming. When you execute BeginXXX, you specify a callback. This callback executes EndXXX. If somewhere in the middle you call .Abort (forced disconnect), the callback gets executed and EndXXX gets executed as well. There is no need to specially remember which method is in progress.
Regards,
Alex
|
Back to Top |
|
|
ramiss Newbie
Joined: 18 March 2009 Location: United States
Online Status: Offline Posts: 5
|
Posted: 26 February 2012 at 12:40am | IP Logged
|
|
|
Alex wrote:
It should work naturally this way if you follow the patterns of async programming. When you execute BeginXXX, you specify a callback. This callback executes EndXXX. If somewhere in the middle you call .Abort (forced disconnect), the callback gets executed and EndXXX gets executed as well. There is no need to specially remember which method is in progress.
Regards,
Alex |
|
|
I agree that is the way it "should" work. However, we are running this against a mailbox with known corrupt messages. There are quite a few reasons that the connection disconnects all by itself, usually with error 55, due to the server not being able to serve the corrupt message.
In this case it is necessary to keep track of the Begin and End when looping through the mailbox.
|
Back to Top |
|
|
Alex AfterLogic Support
Joined: 19 November 2003
Online Status: Offline Posts: 2206
|
Posted: 27 February 2012 at 1:00am | IP Logged
|
|
|
This does not change anything. If the server disconnects by itself, you still have to execute EndXXX. There is no situation when you call BeginXXX but later you don't call EndXXX. Maybe you thought that BeginXXX won't call the callback unless everything completes fine. That's no so. The callback is called anyway. And this callback should execute EndXXX the first thing. Thus, you end up with the guaranteed call of EndXXX no matter what happened during BeginXXX.
Regards,
Alex
|
Back to Top |
|
|