You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Mahesh Sivarama Pillai <sr...@gmail.com> on 2014/08/10 07:00:16 UTC
File Repository James 2.3.2
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
Re: File Repository James 2.3.2
Posted by Eric Charles <er...@apache.org>.
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 <er...@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 <er...@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 <er...@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-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: File Repository James 2.3.2
Posted by Mahesh Sivarama Pillai <sr...@gmail.com>.
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 <er...@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 <er...@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 <er...@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-unsubscribe@james.apache.org
> >>>> For additional commands, e-mail: server-user-help@james.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> >> For additional commands, e-mail: server-user-help@james.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
Re: File Repository James 2.3.2
Posted by Eric Charles <er...@apache.org>.
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 <er...@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 <er...@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-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: File Repository James 2.3.2
Posted by Mahesh Sivarama Pillai <sr...@gmail.com>.
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 <er...@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 <er...@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-unsubscribe@james.apache.org
> >> For additional commands, e-mail: server-user-help@james.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
Re: File Repository James 2.3.2
Posted by Eric Charles <er...@apache.org>.
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 <er...@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-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: File Repository James 2.3.2
Posted by Mahesh Sivarama Pillai <sr...@gmail.com>.
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 <er...@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-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
Re: File Repository James 2.3.2
Posted by Eric Charles <er...@apache.org>.
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-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org