Announcement Announcement Module
No announcement yet.
Why not send email (JavaMailSenderImpl) in separate thread? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why not send email (JavaMailSenderImpl) in separate thread?

    Looking through the source code for JavaMailSenderImpl, i noticed that the email is sent synchronously in the send(...) method by directly calling transport.sendMessage(). I have always seen recomendations for using a separate thread for sending email, since the operation may take a non-trivial amount of time. I'm just wondering why Dmitriy or Juergen decided not to implement it that way.

    What would be the arguments against performing the actual send() in a separate thread?

  • #2
    It would be nice to have an option to send in a separate thread, but in a web application where you need to feeback to the user whether the message was sent or not, the sync method is also useful.



    • #3
      I guess this is application-dependent. Sometimes it's useful to send messages synchronously (to acknowledge wheather the message was really sent or some error ocurred), sometimes you just want to send as fast as possible.

      Moreover, if your application mailing needs gets heavy, the gullible "spawn one thread per message" won't be a reasonable approach: you'll probably need a thread pool, a queue or something like that to avoid spawning hundreds of threads.

      In a few words, I don't think spring should care that much about threading issues: it's up to the application to decide when and how to manage concurrent processing.


      • #4
        As an aside, if you have big batches to send as a time, think carefully about your upstream mail relay architecture, as JavaMail isn't a good replacement for a fully RFC-compliant mail relay. In particular, our enterprise messaging guys are pretty emphatic about making me send through a local sendmail or IIS/mail service that can open a single connection to our core mail routers and send all the outbound stuff at once, instead of for each message.


        • #5
          Sending email using a seperate tread

          Could anyone post an example code of asynchronous email sending using JavaMailSenderImpl in a seperate thread from an implementation of afterReturning() method of AfterReturningAdvice which allows the target method to return values to the caller while the email is still sending?


          • #6
            You can make the send mail call asynchronous with the TaskExecutor that is part of Spring 2. You can also use the Executor of java 5 (there also is a backport for 1.4). Personally I don't care much for the TaskExecutor of Spring because it interface is broken and in a lot of cases you need more functionality than the TaskExecutor supports.

            Another important thing:
            don't make the choice between a synchronous and asynchronous call an implementation detail. This behaviour should be part of the interface design and asynchronous calls have other needs than synchronous calls. The implementation of an asynchronous call, can be an implementation detail.


            • #7
              Asynchronos emailing

              Thank you for the reply. I will try using a TaskExecutor implementation for asynchronous execution of email facility.


              • #8
                Personally I don't care much for the TaskExecutor of Spring because it interface is broken and in a lot of cases you need more functionality than the TaskExecutor supports.
                Why don't you raise an issue on JIRA with some enhancements or discuss this on the dev mailing list (if you already done this, what was the outcome)?