My pleasure. tag/james-2_20120613 uses ant against V2, while trunk uses maven against V3, that's why the jar are not in the lib folder.
On 08/10/2014 01:43 PM, Mahesh Sivarama Pillai wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
