292: Email should be asynchronous.

jason*****@gmai***** (Google Code) (Is this you? Claim this profile.)
Jan. 20, 2014
1068 
What's the URL of the page containing the problem?
N/A

What steps will reproduce the problem?
1. Have a slow mail server.
2. Create/modify a review such that an email is sent.
3. Notice that reviewboard is slow or AJAX calls seem to be unresponsive.

What is the expected output? What do you see instead?
Submitting/modifying a review should not be slow because it is waiting for
emails to be sent.

What operating system are you using? What browser?
N/A

Please provide any additional information below.
If email sending was asynchronous, submission/modification could be
committed and then email sent (at whatever speed necessary) without
affecting the responsiveness of the UI.
chipx86
#1 chipx86
  • -Type-Defect
    +Type-Enhancement
    +Component-EMail
chipx86
#2 chipx86 
It might be best to move our e-mail support into a hook script that's run out of
process. This would be a 2.0 thing.
  • +Milestone-Release2.0
david
#3 david
  • +Confirmed
#4 sebastie*********@gmai***** (Google Code) (Is this you? Claim this profile.) 
When SMTP is unavailable, the request to publish a draft / comment / review is looping. 
The changes are save in database but the AJAX call timeout after a very long time 
(frustrating for UX).
#5 assaf*****@gmai***** (Google Code) (Is this you? Claim this profile.) 
I'm adding a vote to fix this: the fact that Publish takes a long time (5-7 seconds) 
means people press the button twice and get multiple posts. It's also a major annoyance 
and it's hindering the adoption of this fantastic tool in the organization. I hope it 
gets fixed sooner than 2.0...
chipx86
#6 chipx86 
The problem is, we're relying upon Django's e-mail functionality, and we have no
control over the method in which that is sent. Fixing this in Review Board involves a
lot of reimplementation.

It definitely shouldn't be that slow, though, unless the connection with the server
is really slow or maybe if there are hundreds of users it's trying to send to (at
which point this depends on the server).

The problem is, we either have to call out to some external process to talk to the
server (in order to prevent blocking) or talk to the server ourselves. It's not
unreasonable to talk to it ourselves, so long as the conversation with the server is
quick. Which it should be.

Are you using mailing lists for the groups? If not, it's sending to each member
individually.

What e-mail software are you using?
#7 assaf*****@gmai***** (Google Code) (Is this you? Claim this profile.) 
I'm using Exchange. There are about 5 people in the default reviewer list; but AFAICS 
the email is sent just once (I see everyone in the To: list).

There aren't a lot of concurrent users at all in our RB (just starting to use it), so 
I can't imagine it's due to load. I'm running it on Ubuntu in VMWare with about 500MB 
of RAM.

I would try using a distribution list for the default reviews group, but I can't 
imagine that would change much since the email seems to be sent to all of them 
together.
chipx86
#8 chipx86 
That's awfully slow for that few users. It might be worth putting some logging in
place to see where the slow part is (both analyzing the traffic to/from Exchange and
just logging around the mail sending code using log_timed).

We use Review Board with thousands of developers on a very busy Exchange server and
haven't hit slowdowns like this, so I'm really curious as to what's going on.
#9 assaf*****@gmai***** (Google Code) (Is this you? Claim this profile.) 
Well I'm pretty sure it's not Exchange that's taking up the time. It's generally very 
fast here and Publish is consistently very slow.

I'm not entirely sure where/how to put the logging code. I haven't really familiarized 
myself with RB code yet, just installed it. I'll try to figure it out.
#10 scott.q********@gmai***** (Google Code) (Is this you? Claim this profile.) 
One thing that helped my email performance for ReviewBoard greatly was to use Postfix on the local box as a mail relay. ReviewBoard has the local postfix daemon as its smtp server and then postfix relays the email along later. This covers both the main smtp being down and also if it is slow to respond. The only downside has been that it takes about a minute or two longer for the mail to actually arrive in people's mailboxes, but its not really a time critical send.
david
#11 david 
I'm going to merge this with bug 1068, since I think using an MTA is by far the best way to "make it asynchronous"