We have been experiencing intermittent timeouts when connecting to an Exchange server using the .NET 4.3.0 library. I have seen in other posts that the issue has been addressed in NETWORKNET-34421 but the link takes me to the latest version of the dll (17.5.0). My question is in what version exactly was the issue addressed. We have utilized the dll’s in multiple releases of our products ranging from 5.2.0 to 6.3.0 and are about to release with 17.1.0. As you can see we to find exactly in what Aspose version fixed the issue so not to release with a known bug.
Hi Cameron,
Hi Kashif,
OK, we have multiple customer’s experiencing problems with timeouts when connecting via IMAP using the 5.3.0 Aspose.Email. Please see the below error and code that causes the error. We have not seen the issue with customers using the 6.3.0
Thanks,
Cameron
Error-
=== Mailbox Importer Log === Failed to get the mailbox info for account 'AP Invoices'. Reason: 'ConnectFailure' Failed to get the mailbox info for account 'AP Invoices'. Reason: '004 NO LOGIN failed.' Failed to get the mailbox info for account 'AP Invoices'. Reason: 'An imap command couldn't be processed within 40000 ms'
Code-
private ImapClient createImapClient()
{
ImapClient client = new ImapClient();
client.Host = SubscriptionAccount.ConnectionInfo.ServerAddress;
client.Username = SubscriptionAccount.ConnectionInfo.UserName;
client.Password = SubscriptionAccount.ConnectionInfo.Password;
client.Port = (int)SubscriptionAccount.ConnectionInfo.Port;
if (SubscriptionAccount.ConnectionInfo.UseSSL)
{
client.SecurityOptions = Aspose.Email.SecurityOptions.SSLImplicit;
}
else
{
client.SecurityOptions = Aspose.Email.SecurityOptions.None;
}
return client;
}
protected override MailInfoCollection download()
{
MailInfoCollection emailList = new MailInfoCollection();
try
{
//this query is for returning only the unread
ImapQueryBuilder imapbuilder = new ImapQueryBuilder();
imapbuilder.HasNoFlags(ImapMessageFlags.IsRead);
Aspose.Email.MailQuery query = imapbuilder.GetQuery();
ImapMessageInfoCollection messageInfos = _client.ListMessages(query);
if (messageInfos.Count > 0)
{
//fetch in here but we never get here
}
}
catch(Exception e)
{
ProcessorErrorMonitor.AccountFailed(MailProcessorErrorMonitorType.DownloadMailboxInfo, e.Message);
OnMailEvent(MailEventArgs.CreateLog(SubscriptionAccount, SSLogEvent.MailProcessorMailboxInfoFailed, Strings.GetString(“STR_SS_MAILPROC_MAILBOXINFO_FAIL”, SubscriptionAccount.Name, e.Message), LogSeverity.Error));
return null;
}
return emailList;
}
Hi Cemeron,
Hi Kashif,
Hi Cameron,
Hi Kashif,
I understand wanting customers to run the latest release of code, we are a software company, but please understand our perspective. We have customers that purchased and installer our software with the Aspose 5.3.0 dll’s that are having problems and we do not have a product with the 17.x.0 Aspose dll’s to offer. We do have a later release of our product but it uses the Aspose 6.3.0 libraries but do I inconvenience our customers and ask them to upgrade when you, as a representative of your company, will not comment on this version other than to say “you can try 6.3.0”. Asking customers to upgrade is not something we do without knowing the upgrade will fix their issue. We have customers seeing errors every other day and I cannot duplicate it in any of our environments so asking our customers to QA 6.3.0 in not and answer.
You stated the issue was resolved in 4.4.0 but we are still seeing it in 5.3.0. No offense but what guarantee do we have that this sporadic and intermittent yet persisted problem has been resolved in any release.
You and Aspose have historically been excellent at helping us help our customers but in this case telling us to simply move to the latest release is not a satisfactory recommendation. I need to know when the issue was resolved exactly so I can either ask our customers to upgrade or set their expectation on when we will have a fix. We are set to release the next version of our software with Aspose 17.1.0.
Thanks,
Cameron
Cameron Roberts:We do have a later release of our product but it uses the Aspose 6.3.0 libraries but do I inconvenience our customers and ask them to upgrade when you, as a representative of your company, will not comment on this version other than to say "you can try 6.3.0". Asking customers to upgrade is not something we do without knowing the upgrade will fix their issue. We have customers seeing errors every other day and I cannot duplicate it in any of our environments so asking our customers to QA 6.3.0 is not an answer.
We believe the answer lies in your own post here where you have admitted that your customers running application with version 6.3.0 haven't reported any such problem. In light of your this statement, you can safely suggest your customers using 6.3.0 version.
Cameron Roberts:
You stated the issue was resolved in 4.4.0 but we are still seeing it in 5.3.0. No offense but what guarantee do we have that this sporadic and intermittent yet persisted problem has been resolved in any release.
I would again say that the answer lies in your above statement you have shared that customers using version 6.3.0 are not facing any such issue. As far as the status of the ticket is concerned, it has been marked fixed for version 4.4.0.
Cameron Roberts:
You and Aspose have historically been excellent at helping us help our customers but in this case telling us to simply move to the latest release is not a satisfactory recommendation. I need to know when the issue was resolved exactly so I can either ask our customers to upgrade or set their expectation on when we will have a fix. We are set to release the next version of our software with Aspose 17.1.0.
We always try our best to assist our customers to the best of our knowledge and available information. But you also need to understand that if the issue would not have been fixed, your customers using version 6.3.0 would have faced the same exception as well. Also, we would have been facing the same exception with the latest version of the API at our end in such case.
There could be a scenario where the issue arises with some specific host in which case you can share the host information with us and we can try the same server at our end for reproducing the issue. Or you can try the same with the version 6.3.0 or 7.1.0 at your end (the minimum version that you can adopt to) and share with us if you come across any such problem. Of course, you would thoroughly test the new version of your application for all such issues before handing over to your users.
PS: We still want to share with you that in order to raise any such issue with our Product team, we need to reproduce it with the latest version of the API.
Looking forward to assist you further.