IEWSClient methods threadsafe?

Waiting on ticket NETWORKNET-34206, but I looked at the documentation and the static members of IEWSClient are threadsafe, but the instance members are not guaranteed to be threadsafe?


What does this mean?

I need to call Aspose.Email.Exchange.EWSClient.GetEWSClient, Send, GetMailboxInfo, ListSubFolders, ListMessages, and FetchMessage all from within one thread per user account I’m calling them from. Each user get’s their own thread and what I do is threadsafe on my side. Can you provide the shared static resource I can lock from within your API if I can’t make these calls in threads in the current release? I’m running Jan 1 2014 build.

This is urgent for a client as a single thread is taking too long to call for them and I need about 10 threads to keep it fast for the users.

Thanks for your prompt reply.
Hi Sagerion,

Thank you for your inquiry.

Aspose components are designed to be simultaneously used by hundreds and thousands of users, for example in web applications. Aspose.Email does support multi-threading; however, the only thing you need to make sure is that you always use separate instances per each thread i.e. one thread should use one client object.

In addition, we do not guarantee thread safety in terms of using the same object from different threads simultaneously and for this, user has to write his own locking wrapper. As far as different threads are concerned, the product must work correctly with different objects of each thread.

Thanks - the wording on “not guaranteed to be threadsafe” was misleading. I know to create one client per thread and only that thread will use that object for the calls for that user. I’ll turn on my threadpool again and get to it. Thanks for the clarification!


Can you change the static factory into a instance one like you had before so I know for sure I’m dealing in normal object land and not statics? I never use statics since a singleton can be implemented well without having any statics involved, and that means I never have bad code that reaches across an entire library for a static, creating a coupling of classes that should never know about each other.

Hi Sagerion,


Thank you for understanding.

We have already given it consideration and I’m afraid to share that such thread safety can not be made part of the API as it can easily be handled at client end all by himself as I have shared earlier. We appreciate your understanding in this regard. Please feel free to write to us for further assistance in case you have any other query/inquiry related to Aspose.Email.