That's exactly my setup! But I think what you meant was to put "loader" instead of "Mercury" in the startup folder. This way at least Mercury would re-launch after a crash. 

In a way I am glad that I am not the only one having this problem. I am running Mercury on a Win2k3 server and I am having problems with crashes and corrupted IMAP folders that I believe are due to:

1. concurrent IMAP connections from Android and Outlook.

2. large IMAP folder size (>1.5GB). The large folders are usually "Sent/Sent Messages/Sent Items" and "Trash/Deleted Items/Deleted Messages", which make matter worse because they are constantly in use.

Android and iOS devices do not terminate IMAP connections properly, which compounded the problem as more and more of these devices are now connecting to Mercury. Add this to the time it takes to handle large folder and it stresses Mercury. When Mercury is stressed, just about anything would push it over and crash it. And it seems that when it crashes too many times consecutively, it moves everything in the queue to a sub-folder, thinking that something in the queue could be causing the crashes, by then there would have been a lot of zero size files in the queue.

For me at least, toggling the "affinity" to get it to run on two CPUs did not improve performance, but unchecking the "Enable support for SSL/TLS secure connections" checkbox did help slightly.

Just a note though: the largest folder size for me is 4GB instead of 2GB, and mine have both IMAP and POP enabled. 

regards,

Philip 

We are a long time user of Mercury (and Pmail), currently running 4.74.  The last few months we have been experiencing a number of crashes of Mercury, sometimes more than 4 a day.  The crashes appear to be IMAP related as if I disable IMAP, it stays up.  I can't get away with doing that for very long.  If I run mbxmaint against remote IMAP users mailboxes after a crash, there will be several corrupt mailboxes, with either a Character before start of message is not Ctrl+Z or duplicate IDs problems.  While that kind of thing is expected from a crash, once these start to happen, it seems to compound the problem and make crashes more frequent until I go through and fix all the problem mailboxes.  After watching this happen for some time now, I am getting the feeling it is related to remote users who have very large mailboxes, some well over 1GB.  I am wondering if we are seeing this http://community.pmail.com/forums/thread/38707.aspx bug posted in the Mercury Beta Discussions thread?  The person posting this seems to have gotten around the problem by increasing the timeout.  That may work for some of the remote clients running whatever email client on a PC, but will most likely not be possible on all the various Phones and tablets that everyone seems to want to use these days.  I do notice that on days when the problem seem really bad that there will be many hours of 200kbyte / second or more network traffic out of the Mercury box to the Internet, almost all of that IMAP traffic.  We are in need of a solution to this problem soon as we can not continue with these problems for much longer.  What we are really hoping for is a new version of Mercury that makes life with IMAP a bit more tolerable, any hints as to how far that is out will help us decide were to go next.  Any suggestions that help keep things running more smoothly in the mean time are greatly appreciated.

Gus

Hi GUs,

Sounds like what was happening to us.  I noticed in task manager that Mercury was set to only run on CPU 1 and that CPU 1 was almost constantly saturated with a backlog of files building up in the QUEUE directory. 

 I found that I could set the processor affinity of Mercury to use other CPU or indeed all cpu cores but the setting is not sticky so you need to reselect it each time you restart Mercury which hopefully will be MUCH less often after making the change.  In our case none of the CPU cores is ever saturating now other than momentarily.

Please let me know if this is helpful. 

Just for a quick check I looked at the Mercury box this morning to see utilization, and just as I was watching one of the crashes happened.  Just before the crash utilization on one core went to 100%, and shortly after the loader recovered it it was again at 100% for a few seconds, that is probably normal.  When it running normally, we do not see high core utilization or everything happening on one core.  We currently have 2 cores assigned to this VM.  At one time we had 4, but it was never using them so took 2 away.  One thing I do notice is that after a crash a bunch of 0 byte files will get left behind in c:\mercury\scratch.  For what its worth, we are running it on WinXP.  I am hearing some complaints from some remote users that they can not delete messages from their inbox, one I looked at this morning has over 2500 messages stuck in the inbox.  That one is using Apple mail on a MAC.

You need to right click Mecury.exe in the task manager processes tab and then choose set affinity.  By default mercury.exe is set to ONLY run on CPU 1, choose to allow it to run on all available cores.  It appears that it is when mercury saturates the CPU 0 length files get left behind, a queue builds up and Mercury at least appears to have crashed and sometimes actually does terminate.

FYI:  In Win7 you can control affinity on app startup using the start /affinity command in the shortcut.

More info here:

http://www.techrepublic.com/blog/windows-and-office/change-the-processor-affinity-setting-in-windows-7-to-gain-a-performance-edge/

For what its worth, we have enough other problems with W7 that we will leave Mercury on XP at least for a while.  As to setting affinity, we are running Mercury with Loader.exe, and it appears that Mercury does not inherit the affinity of that process as I had thought it should.  Considering the crashes, I would be crazy to consider running it without loader.  For the moment, will try manually setting the affinity after it has started and see if that helps

Setting the affinity to more than one core does not help, still crashes, no difference noted.

Tried running mercury.exe directly without loader.  Ran for about 6 hours before the first crash.

At least this time the Windows crash reporter announced that it was the core process that had crashed.  Also, the whole thing stayed running until I clicked on 'Don't send', no point in telling Microsoft about this.  It appears that the core process is still delivering messages as there was still activity in the Mercury Core Process monitor window until 'don't send' closed the whole thing.

I will let it go for until the end of the day and see if it happens again, I am betting that it will.  There is nothing notable in the logs and again a bunch of orphan files in the SCRATCH folder.

My crashes are very rare but have never seen any files orphaned on the Scratch directory.  Only thought that comes to mind is to make sure the Scratch directory is on a local drive and not exposed to active antivirus scanning.

Well that did not take long, just happened again.  This time it appeared that almost everything stopped.  IMAP remote users were still trying to log in, but failing with lots of Connection from .... in the log but none of them succeeding until Mercury is restarted.  I am going to have to restart with Loader.exe as I can not afford to spent the time sitting and watching for a crash to recover.

One thing I do notice from the loader.log, the message Normal operation restored message usually occurs 15 to 30 minutes after the Restarting Mercury after apparent abnormal termination message.   An excerpt from the log is below:

13-09-25.1250: Restarting Mercury after apparent abnormal termination
13-09-25.1311: Normal operation restored - resetting counters.
13-09-25.2040: Restarting Mercury after apparent abnormal termination
13-09-25.2111: Normal operation restored - resetting counters.
13-09-26.0559: Restarting Mercury after apparent abnormal termination
13-09-26.0612: Normal operation restored - resetting counters.
13-09-27.0945: Restarting Mercury after apparent abnormal termination
13-09-27.1012: Normal operation restored - resetting counters.
13-09-30.0520: Restarting Mercury after apparent abnormal termination
13-09-30.0614: Normal operation restored - resetting counters.
13-09-30.1139: Restarting Mercury after apparent abnormal termination
13-09-30.1214: Normal operation restored - resetting counters.
13-09-30.1619: Restarting Mercury after apparent abnormal termination
13-09-30.1714: Normal operation restored - resetting counters.
13-10-01.0736: Restarting Mercury after apparent abnormal termination

Gus

There can be a problem with multiple simultaneous connections with POP3 to the same mailbox with users having 2, 3, 4 or 5 different devices to check their email with nowadays. Mercury 4.80, that is still in beta testing, will handle that in a different way.

FYI we do not have the POP module enabled, IMAP only.  Yes remote sales people seem to want to have every device they own connected, I am not sure why as I do not know anyone capable of reading messages from more than one at a time.  I believe a good part of the problem is due to many of them not knowing how to stop the email app on their phone or whatever. We stopped using POP some time ago due to the multiple device problems in the hope that IMAP would solve these problems.  It did for a while, however as the amount of stuff users demand to be able to save goes up, things have gone downhill.

We are desperately looking for some measure we can take to survive until the next version is available and hoping it will resolve the IMAP issues. A clue as to how far out that is going to be would help us decide how to proceed.

One issue we see that may or may not be related is that some of these users will keep adding to a folder, usually 'Trash' or 'Archives' until its file size exceeds 2 Gbytes.  Mercury will keep adding to the folder even though its size has gotten to the point that mboxmaint can no longer index or repair it, the familiar 32 bit file size limit we see in so many programs.  It would be nice if Mercury would return an error message to the remote user instead of adding to it and making it no longer useful.  I realize this is much easier said than done with IMAP.

Gus

The new mailstore that will be introduced in Mercury v5 will address this issue, but until then there is indeed a 2 GB limit. 

We are running on a very old server 2003 system.  We have multiple users connecting for multiple devices and until I set the affinity for Mercury to use all the CPU cores it was regularly being unresponsive.  As far as I know the only users who are still having issues are those who are using Lookout (Outlook) and Android devices at the same time and then it is only Lookout which misbehaves..  Having several Android devices connected to the same account at the same time does not seem to be a problem.  Users running Pegasus are of course having no problems at all.

if you are running on Windows 7 I would suggest that you check the directory permission for wherever your mailboxes are to make sure that the system account has full control, it is worth checking the Mercury directories too.  It is probably worth not putting Mercury in program files.  As Brian said it is also essential to make sure that no ones virus scanners are trying to scan the mailbox directory. 

We tried setting to run on more than one processor, made no difference whatsoever.  Based on David's reply to your post on the 'Mercury Beta Discussions" section of this forum, that appears to not be such a good idea anyway.  In any case except for a short time during startup and just before a crash if you are lucky enough to be watching one, we never see any significant cpu utilization. This system is serving about 100 users, probably half of them remote.

We are running Mercury on XP and plan to stay there for the time being.  Running in NDS mode, all user files are on a Netware server, Mercury has full rights to those, Mercury itself is running as a Windows Admin user.  There are no virus scanners other than Clamwall running with Mercury.  The only app running on this VM is Mercury, it is a dedicate system.

As for the 2 GB limit for folders, Lukas Gebauer has created a command-line tool to split a folder that has grown over the limit in two. It can be downloaded here:

Thanks for the hint.  I did try it on a folder that started at 1,967,647,399 bytes and it split it into one of 1,879,992,213 bytes and another of 87,655,314 bytes.  If I run it a second time to try to reduce the second big file, it appears to only rename that file to its original name + .old, completely loosing that folder.  I did try compacting the folder first and checking for errors, none found.  Was this utility only supposed to reduce the file to some value under 2G or split it?  If I had the file format of the folder files, I would take the time to produce a version that breaks the big ones up into more.

We are experiencing the very same problems. We have an average of about 1 crash per day; some days up to 4 or 5 crashes. Our installation is on a dedicated WinXP machine. Mercury is installed in C:\MERCURY, the mailboxes are in C:\MAILROOT. Both directories are on the exception list of the virus scanner. We have less than 10 IMAP accounts and less than 10 users. The largest data amount in a single mailbox folder is less than 1 GB.

Mercury is running for about 6 months now. I started using mbxmaint yesterday, and found some corrupted mailbox files, either with a duplicate ID problem or a missing Ctrl-Z. I repaired the files, and got another crash this morning, resulting in a new corrupted mailbox. There are also some lost files in the SCRATCH folder.

As we are running a licensed Mercury in the windows service mode, my question would be, we are not affected by loader.exe, right? I found no loader.exe process running, and no loader.log file. It would not make any sense to enable the "Exit and restart each day" option, right?

What mechanism is responsible for restarting Mercury, which indeed happens after each crash? Can I enable some kind of report that shows when and how often Mercury crashes? There is no restart notice in the Mercury core log file. All I see is the "report Microsoft" dialog when I log on to the XP machine.

If you are running on a dedicated box, consider running as interactive app and forget the service stuff.  Set up autoadmin login and put a shortcut to Mercury in the startup folder to have everything start automatically after a cold boot. This way you can monitor what is happening on screen nicely.  Running anything as a service is a real pain if you want to interact with it.  If Mercury is the only thing running on that host, this is probably your easiest way to deal with it.

I have found that after a crash, there will be a number of remote users who were connected at the time of the crash will have corrupted folders either for the duplicate ID or Ctrl-Z or maybe both.  This causes me to have to spend a bunch of time checking and rebuilding folders.   After watching this happen for some time now, my hunch is that it is related to users trying to move messages from one folder to another, in many cases, just deleting a message which most remote clients interpret as a move to the trash or whatever they choose to call the deleted messages folder.  As the folder gets bigger, the prospect of a problem start to get worse.