Thanks a lot Eric. That gives me more confidence on V2. I have built Postage from source and did a sanity run for a minute. I downloaded the source from http://svn.apache.org/repos/asf/james/postage/tags/james-2_20120613/ as opposed to the trunk mentioned in the wiki entry for Postage. Trunk doesn't have all the jars in lib. I will share the results once I do a load test with my expected load. And please expect more questions from me as I progress. Thanks again for the help/inputs so far.
Thanks Mahesh On Sun, Aug 10, 2014 at 4:40 PM, Eric Charles <e...@apache.org> wrote: > 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 > >
