We had an issue with an IMAP migration utility (University of Washington "mailutil") and some people on the net have reported an issue with Thunderbird -- any client that tries to perform an operation on a large number of messages at once would generate an error:
parse error: maximum request size exceeded
References are:
http://www.zimbra.com/forums/administrators/36134-thunderbird-3-maximum-request-size-exceeded.html
http://bugzilla.zimbra.com/show_bug.cgi?id=43615
http://bugzilla.zimbra.com/show_bug.cgi?id=42489
I searched the forums and couldn't find an answer so we opened a support case. The solution was that I was referred to bug #42489. Apparently
, there is a new setting out there "imap_max_request_size" that defaults to too small of a value (maybe 100 * 1024 * 1024). We increased it to 1024^3.
Not much documentation out there on this new setting, but it did close an RFE I entered a year earlier (#34340). I like this new feature because under 5.x, when we would migrate a large IMAP mailbox using the uWash imap "mailutil" utility, it would bomb on any folder that was larger than "zimbraMtaMaxMessageSize" (as if that made sense). Under 6.x, "zimbraMtaMaxMessageSize" no longer affects that utility, but "imap_max_request_size" does.
--
Fred Seaton
Research & Instructional Consultant, Senior UNIX Specialist
University Technology - Infrastructure
Western Illinois University
107 Morgan Hall
Macomb, IL 61455
309-298-2870
----- Original Message -----
From: "Sam Khavari" <sam@zimbra.com>
To: "Steve Hillman" <hillman@sfu.ca>
Cc: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
Sent: Thursday, March 4, 2010 1:14:14 PM
Subject: Re: IMAP and Zimbra 6
Hi Steve,
You are referring to the IMAP NIO server. You're correct that with IMAP NIO, we no longer need to dedicate one thread per connection, and thus able to support more users. We don't have any numbers to publish yet and mileage will vary based on workload, IMAP client, DB IO and RAM. As you may know, NIO has been in the product for a while and can be enabled using the local config key nio_imap_enabled. However, we haven't made it a GA feature because of some known issues (most of which have now been resolved in 6.0.). You can keep track of the progress with bug 9470, which is currently targeted for 7.0. We'll document more about the feature once it's GA.
Of course, with Zimbra Desktop you can reduce the number of IMAP users :-) ZD 2.0 Beta 2 will be released in a few weeks.
Cheers,
Sam
----- Original Message -----
From: "Steve Hillman" <hillman@sfu.ca>
To: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
Sent: Tuesday, March 2, 2010 5:29:32 PM
Subject: IMAP and Zimbra 6
Hi folks,
Last fall, I paid a visit to Zimbra's head office and had a chat with some of their developers. One thing that came to light is that in Zimbra 6, the IMAP engine has been redesigned: rather than requiring one IMAP thread per connection, there's now apparently a pool of threads to handle all of the connections, so theoretically at least, there's no limit on the number of IMAP connections a server can handle (or at least, it's sufficiently high). Unfortunately, I've been unable to track down the Zimbra Bugzilla ID that tracked this architecture change, so I can't read up on how it works, whether there are any tunables, etc
For those sites running Zimbra 6, have you noticed any change in IMAP behaviour? How many IMAP threads do you run with now? Anyone from Zimbra on this list care to share details - specifically, anything large sites should be aware of re:IMAP when upgrading to 6? What is now an optimal number of IMAP threads? We'd been continually bumping ours upwards to deal with all of our IMAP connections - we were up to 1000 per server (it by far dominated the list of threads in a Zimbra thread dump)
--
Steve Hillman IT Architect
hillman@sfu.ca IT Infrastructure
778-782-3960 Simon Fraser University