No limitation nor constraint at all to run your use case on V2, and even maybe recommended as V3 mailetcontainer certainly still needs more tuning, while V2 is stable and tested.
Benchmarking V2 vs V3 should give interesting figures, but we didn't do anything yet. You may also need support to use Postage which has no release so far. On 08/10/2014 12:37 PM, Mahesh Sivarama Pillai wrote: > I will definitely evaluate v3. But our use case doesn't need IMAP. Its not > a mail server which many users are going to access from their local mail > clients. What we are planning is an email application platform where when > an email is received over SMTP, call a web service and store the attachment > in another cloud storage.The JAMES server will not relay the emails to any > external mail servers. The mail flow ends when it arrives at JAMES. We have > an enterprise email server forwarding the emails to this proposed James > server. The earlier implementation was using a perl script which was > configured through an alias file in SendMail. So essentially the > sendmail+perl is going to be replaced with JAMES+Mailets. I have setup > Postage and I am going to test the performance with the scenarios. But > wanted an expert advice before I start testing them. Do you foresee any > issues implementing this using JAMES 2.3.2 ? I know that the performance of > the whole flow will depend on the implementation of Mailet. I wanted to > know if there are any limitations or constraints etc with the out of the > box features of JAMES 2.3.2 considering my use case ? > > Thanks > Mahesh > > > On Sun, Aug 10, 2014 at 3:41 PM, Eric Charles <e...@apache.org> wrote: > >> 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
