Thank you for sharing the information. I have been able to reproduce the issue. An issue with ID EMAILNET-39850 has been created in our issue tracking system to further investigate and resolve the issue. This thread has been linked with the issue so that you may be notified once the issue will be fixed.
Ok thanks, Iāll look forward to hearing an update.
Weāve got another hanging issue when opening PDFs and converting to PDF/A as well now
If you are trying to open PDF and having issue converting that to PDF/A then I suggest you to please make a separate inquiry in Aspose.PDF forum with sample PDF and sample code used.
Hello, I have encountered some more MSG files that hang when doing a simple conversion to MHTML, using the latest Aspose.Email for .NET (20.6) with the same code as above:
var mapi = Aspose.Email.Mapi.MapiMessage.FromFile("input.msg");
var msg = mapi.ToMailMessage(new Aspose.Email.Mapi.MailConversionOptions());
var saveOpts = new Aspose.Email.MhtSaveOptions();
msg.Save("output.mhtml", saveOpts); // <-- never finishes
Sample file: input.zip (101.2 KB)
Can you please fix this, as it is a problem when the whole process hangs on random emails.
Thanks
The new file appears to hang on saving to MHTML. A ticket with ID EMAILNET-39873 has been created to further investigate and resolve the issue. We will share the good news with you as soon as the issue will be fixed.
@mudassir.fayyaz
We seem to be going round in circles finding individual issues and fixing them. My request is that after a specified period the save will timeout instead of hanging your customers applications.
Weāve had to implement a timeout function using sub-processes which has absolutely destroyed our performance, mainly due to having to license Aspose on each sub-process execution. We shouldnāt need to go to such measures just to make sure our application doesnāt go into a zombie state.
I understand your developers need to fix these individual problems but can you confirm if the developers are looking to ensure the code never hangs?
I can understand your concerns. However, the issue of hanging is not related to single situation in API. In MHTML export multiple APIs are involved. For example, in case of EMAILNET-39850, the issue happened in with Aspose.Words on saving MHTML rather than Aspose.Email. and we have added a new ticket with ID WORDSNET-20729 to address that.
I understand that may be the case but from our point of view there are two main touchpoint where we experience zombie states - loading and saving on aspose librariesā¦
My request is that you add some catches in these methods to prevent hanging code. Without proper timeouts implemented we lose faith in your great libraries, just waiting for the next time we try to load or save a document with some unknown element in it that causes a hang. Like I said, the code we HAD to implement to work around the zombie state some of the load and save methods can cause has destroyed our conversion performance and it makes us start to look elsewhere for alternatives, which we donāt want to do.
You are very right in your observation and points. However, from our perspective whenever we receive any reported case, its root cause is investigated and fixed. Apparently the symptoms of issue are same on surface level but deep inside they have several testicles. Like consider the last case where apparently the issue of hanging was same but when it was investigated, it was found to be related with Aspose.Words. We encounter situations during our development and some are reported via customers. We tend to consider and resolve all.
Iām not suggesting you donāt investigate individual issues; I absolutely think that should continue and we will continue to contribute in the effort to improve the variety of documents you can support.
The problem is, as customers, we need the Aspose libraries to do something other than hang and go into a zombie state upon an issue like those found here; a timeout is a possible solution but your developers may well be able to come up with a better solution. At least our applications can then complete without us having to find individual documents that failed, exclude them and then restart processing. It just leaves a bad taste in the mouth when paying thousands to use your libraries only to find they can hang our apps.
On receiving a timeout exception we can then report individual documents to Aspose as and when they occur.
Based on your request, I have created an investigation ticket with ID EMAILNET-39876 in our issue tracking system to further assess the requirements. We will share the feedback with you as soon as it will be share by teamā¦
Thanks for starting an investigation into the request - we appreciate your understanding and assistance.
The issues you have found earlier (filed as EMAILNET-39876,EMAILNET-39873) have been fixed in this update.
The update has resolved the most recent problem, thank you!
The time-out is a very good feature too. Now can you please ask the Aspose.PDF team to implement a similar time-out/interrupt for their API? 
It has been āunder investigationā for 5 years (!): Abort PDF Save thread. I submitted another confirmed example over a year ago, they said it would be investigated in February this year, but still no progress: Problems with text extraction on vector-based PDFs
Thank you for sharing the feedback. I have informed Aspose.PDF team as well to share the updates for concerned threads as well with you.
Hi Mudassir,
Apologies - somehow I missed this update. We will put this version into our code and do some testing - thanks for the update and investigation.
Would you mind explaining what we can expect to find (the link ultimately leads to a 404 on the release notes)? I understand the individual issue has probably been fixed so weāre not going to see the hanging issue anymore but what will happen when we come across a similar problem - is there still a potential for the aspose library to hang or will we get a timeout or similar? If so can we have some details of what exception to expect so we can trap it and handle it in our application?
The issues you have found earlier (filed as WORDSNET-20729) have been fixed in this Aspose.Words for .NET 21.4 update and this Aspose.Words for Java 21.4 update.