I turned on the verbose logging and session logging for MercuryE module, but when I ran the system again yesterday, the problem seems to have fixed itself.  We actually have two systems that are identical except for their static IPs, and domains, which I believe were acquired via My DNS, and they both work fine; the messages are are processed and delivered in under a minute every time. I'm not sure what the difference is (something to do with the receiving servers I would guess), but if I see the problem again, I'll be sure to post what I obverser here for other people to use.

Keep up the good work.

~Jo-Jo

First let me say to whomever developed this program: Great job!  I can't believe I got it up and running so quickly (especially since I have never set up an email server in my life).

Anyway, I have set up Mercury, and everything works fine, except the outgoing jobs seem to sit in the ready category for for several minutes before they are sent. I am using the MercuryE module (as I have a static IP) with the poll time set to 15.  Mercury processes incoming messages within seconds, but then the Mercury core process shows them as "ready" for four or five minutes before they get transfered to pending.  This wouldn't be a huge problem excpet that I have written an application that communicates with Mercury via SMTP to alert me via text message and email if something goes wrong, and continues sending messages to myself and a friend of mine every five minutes until soemone replies. But what is happening is that the messages are piling up in the outgoing jobs so that by the time I receive the first one and respond, there might already be four or five more piled up and ready to go, which I then receive over the course of the next several minutes.

Does anyone know how to shorten the time the messages sit in ready, or is this something to do with where the messages are being sent?

~Jo-Jo

Mercury will send out messages on the next poll cycle after they have been received, so the delay should be very small. Check the core log and see if there is any indications there of anything that might be wrong. Make sure the local domains section in core configuration is correct (see Mercury help for more information).

The creator of Mercury is David Harris.

/Rolf  

Could also be to do with where they are being sent.

Check the MercE log to see when the messages are being sent and any other clues. The receiving server may be greylisting them for some minutes.

Now that you mention it, I guess I knew it was David Harris.  I think his name is on the website, if memory serves. 

Anyway, here are some excerpts from the core log, and the MercuryE module respectively that were both generated yesterday.

O 20090408 1330 MG00000F local_email          destination_email_1        275
O 20090408 1331 MG000012 local_email          destination_email_2        274
O 20090408 1331 MG000011 local_email          destination_email_1        275

T 20090408 133054 49dcf1df Begin processing job MO000010 from local_email
T 20090408 133214 49dcf1e0 Begin processing job MO000014 from local_email
T 20090408 133214 49dcf1e1 Begin processing job MO000013 from local_email
T 20090408 133240 49dcf1df Established ESMTP connection to 64.18.5.10
T 20090408 133253 49dcf1df Connection closed normally.
T 20090408 133254 49dcf1df Job MO000010 processing complete.
T 20090408 133300 49dcf1e1 Established ESMTP connection to 12.104.77.224
T 20090408 133302 49dcf1e2 Begin processing job MO000018 from local_email
T 20090408 133302 49dcf1e3 Begin processing job MO000017 from local_email
T 20090408 133302 49dcf1e1 Connection closed normally.
T 20090408 133303 49dcf1e1 Job MO000013 processing complete.

The emails, are actually the correct emails, of course, but I'd rather not advertise them.  So it looks like to me, that the server doesn't connect until a few minutes after the message is received by the server.  So does this mean that it is attempting to connect to the remote IP, but not succeeding for a couple minutes, or does this mean that it isn't even trying?  The internet connection we have setup is via a multimodem which communicates with the internet via a cell network, so it isn't very fast, but I can't imagine that there is that much information to exchange, and the incoming messages are very speedy.  From the time they are sent from a remote computer to the time the application receives them is certainly less than one minute.  This leads me to believe it is either unable to connect to the remote server very fast, or is not even trying for a few minutes. Also, why is it not processing job MO000013 while it has the ESMTP connection established the first time?

~Benjamin

Also depends a lot on what you have the server doing.  The daemons, filtering, content control all delay the core process in writing the MO files to the queue.   The MG files are the inbound mail coming from MercuryS in your case.  Can't tell a lot here as to when core completed it's job since the log does not show core writing the MO files.

MercE begins processing each job in good time.

Turn on session logging in MercE for more detail of what is going on, really just guessing otherwise.

If we examine the first message the outgoing job was created by core at 13.30, and MercuryE started processing it at 13.30.54. Connection to the receiving server (s6a1.psmtp.com) was made 13.32.14 and the transfer was complete at 13.32.53. 

s6a1.psmtp.com is part of a Google service called Postini that scans messages for spam and viruses and provides archiving. My guess would be that the delay was at their end.

/Rolf