🚀 go-pugleaf

Oliver Young wrote:

> > just fowarding to an SMTP server?
> Yes, but first they are digitally signed and/or encrypted. It is
> SMIME.

Which may well benefit from some paralell processing....

> > In the
> > second case, everything's being pushed to a single socket anyway, so
> > network access (at least) will have to be single-threaded.
> I'm using Bouncy Castle libraries. I'm not dealing with network at
> all.

AFAICS, they just supply javax.mail providers for SMIME, so the network
access will be provided by Java Mail transport?

I think in this case the benefits of threading are dubious; each thread
will have the lengthy task of establishing a connection to the server,
and then sending the mail, whereas a single transport could pluck
processed messages from a queue and manage the connection
appropriately. Once they get to the SMTP server they'll (more than
likely) all be going in the same queue anyway.

> > There are no hard and fast numbers in concurrency requirements, even
> > for a given machine - it depends upon work load as well.
> Can I start high fixed number (i.e. 30) of threads on any machine?
> Will that (high number of threads) slow down slow machines?

Not significantly  - you need 100's or 1000's before the context
switching between threads starts to cause problems.

I see a number of possibilities: 

 - Thread per task: 
   Messages are submitted to the system and placed in a queue. A
seperate thread takes jobs from the queue and performs the S/MIME
encryption on the them, and then places them in another queue (or the
same one with some sort of status indicator). A final thread then pulls
encrypted messages from this queue and pushes them through the
transport.

 - Thread per job 
   Messages are submitted to the system, into a queue. A thread grabs
them from the queue and performs both the encryption and network access
on them.

 - Mixture 
   Many threads available for (say) encryption. Single thread
performing (say) network access.


Ideally you want an archtiecture than can support all three of these
modes and be changed at runtime either due to configuration changes or
to load managing policy. A decent thread pool implementation will help
with this, and other aspects of thread management. You will also
benefit from having a configurable queue that can change it's
prioritizing basis (Least Recently Submitted, Highest Priority etc.).