I've lately run several tests aginst MercuryI, and what I can see your report generally match my findings.

Approx. the following is what I've last week reported to David for examination:

• It appears that in some cases newly created threads have to finish before allowing existing ones to continue. (this means the opposite of what you say above)
• CPU rushes, and disk activity is extremely intense. Especially cache-files are not bulk-read.
• MercuryI reads the headers of all UNSEEN messages, returns the headers and body, then adds a X header containing FLAGS. I'm under the impression that this is the reason why some some clients report message headers have been altered, who then stop fetching new messages.
• \RECENT flag always reports 0.

David has responded and is examining these issues. I'll keep you posted when I have something to report.

We have an intermittent problem with our Mercury32 server (IMAP and POP, NDS Mode): After the server runs for some time, the server sometimes gets very "sluggish", especially the login to imap or pop takes 10 or more seconds, in extreme cases several minutes! We can see this in the Mercury Screen, as new connections remain as "Not-Logged-In". It takes very long for the "Not-Logged-In" to be replaced with the actual user name. Those "Not-Logged-In" sessions pile up, sometimes there are dozens of those new connections waiting for authentication, and you can see maybe one every few seconds is converted in an authenticated session.

Needless to say, most e-mail clients run into timeouts during this long wait. If it gets really bad, it's almost impossible to connect to Mercury32 via imap or pop. Once logged in, you can work with your mails, though a bit sluggish. But since every other imap operation is done via a new connection (move, move into trash etc.), most e-mail clients cannot work anymore, since new connections take so long.

We also observe a high number of threads and context switches in the mercury process (viewable via Process Explorer by sysinternals): 100 threads are normal, 200 to 300 during busy times. 2000 to 8000 context switches in mercury also are quite common, may be more during buy times. The high number of threads and context switches seem to be related to the "sluggishness" of Mercury32 and the piling up of "Not-logged-In" connections. Though we don't which is cause and which is effect or what the cause is in the first place.

Any ideas?

Greetings

Markus