Bug: CREATE succeeds even if mailbox with same name already exists #360
Assignees
Milestone
Comments
|
Another observation although I only had the chance to see this once: even after exiting my test application my test folder was being re-created in Greenmail. So it went like this:
The folder got re-created twice after deleting it manually. Could it be that the request do create the folder somehow got queued although the requesting client already disconnected/went away? Im not sure if my client disconnected or I just terminated it. Might be the latter or some strange coincidence of things but I thought I'd mention this just in case it's relevant. |
|
I tried to run a simple create-and-recreate, which on protocol level seems to work as expected ( You could try to run in verbose mode (-Dgreenmail.verbose)? When creating a folder which already exist, some APIs are quite tolerant. |
marcelmay
added a commit
that referenced
this issue
Jan 7, 2021
…#360) - Extend test - Log mailbox name
|
I'm a dummy. After looking at the verbose log and seeing it correctly showing 9 server-side errors while my client only "received" 5 I saw that I increased the error counter in a non-thread-safe fashion. I forgot the lock. Sorry for the hassle and thanks for looking into this. For sake of completeness here is the verbose log: I also tested with Dovecot. Dovecot doesn't raise errors at all. If there is a folder name collision the CREATE returns successful, as if the folder was a new one. Don't know what's better. Side note: Since I'm using the Greenmail Docker container I looked up how to configure the verbose parameter here. It does not work as documented on Windows, Windows needs double-quotes like so: Again, thanks for your time and help in solving this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Scenario
I'm creating folders/mailboxes in a highly parallel fashion. While doing this I discovered that when several threads try to create a folder/mailbox with the same name at the same time several of them succeed. This is unexpected. According to the spec it is an error to create a mailbox with a duplicate name. So only one thread should succeed.
How am I testing?
Using MailKit and a .NET Core C# console application I spin up 100 threads which all try to create a folder with the same name at nearly the same time.
Expected behavior
I expect one of the threads to succeed and 99 to fail with an error.
Observed behavior
At times 10 threads are "successful", or 11 threads, or 4 threads. Sometimes it works and 99 report an error while only one succeeds. The behavior is the same with or without restarting Greenmail between tests.
Repro
I suspect you can use any library or tool to create folders/mailboxes with the same name at the same time via >10 parallel threads. Note that I am using a separate connection per thread.
Conclusion
I suspect there is an error in Greenmail with handling highly concurrent requests to create a new mailbox.
Notes
I discovered this while unit testing. My application does not really need 100 threads creating the same folder in parallel. But an edge case test behaved unexpected which is how I came to investigate this further.
(And if it's not Greenmail it must be MailKit, but for now I'm assuming MailKit works as advertised.)
The text was updated successfully, but these errors were encountered: