For pure smtp relay, v2 is better tested and is known to work in various production deployments.
It supports pop3 but not imap, so if you don't need imap and focus on smtp, v2 is the best choice. Simply be aware that if you face an issue and want a patch committed, and released, you will get that less easily than in v3. If I was you, I would take a bit more time to test both and see how they behave, assuming you have enough timeslots to put a test infrastructure in place. On 08/10/2014 09:18 AM, Mahesh Sivarama Pillai wrote: > Hi Eric, > > Thanks. I see that issue is fixed. I am going to use 2.3.2 which is the > stable version. I cannot use v3 at this moment as its not stable and I > cannot convince the people around here to go ahead with v3. Do you still > see I would encounter these kind of issues with 2.3.2 ? What other options > that I can explore in 2.3.2 ? I have read in the mailing lists about > people using James 2.3.2 with huge load. Are you saying James is not a > candidate for the specific use case that I mentioned earlier ? > > Thanks > Mahesh > > > On Sun, Aug 10, 2014 at 12:37 PM, Eric Charles <e...@apache.org> wrote: > >> Probably because you risks errors like JAMES-612 - All mails are 2 >> serialized files. >> >> Off the record, I guess a unreleased version is not the best for your >> project, but you will get more functionalities and support going to v3. >> >> >> On 08/10/2014 07:00 AM, Mahesh Sivarama Pillai wrote: >>> Hi All, >>> >>> In the James v2 documentation it is mentioned as >>> "File repositories are not recommended for large or performance-critical >>> configurations." >>> >>> I am planning to use James 2.3.2 for a large and performance critical use >>> case. I am expecting around 100K emails a day with a maximum attachment >>> size of 20 MB (not all attachments will have 20 MB size). I have to strip >>> off the attachments from the email and store in a File storage cloud. The >>> above line about File repository really worries me. If not File >> repository, >>> which other repository gives high performance and reliability. I don't >>> think storing emails with large attachments in DB is a good idea. Please >>> provide your inputs and guidance. >>> >>> Thanks >>> Mahesh >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >> For additional commands, e-mail: server-user-h...@james.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
