Re: Tentative Date for James 3.0 GA
Hi Mahesh, We'll release "when it's ready". It's a non-answer to your question, I apologize. ETAs are usually something harmful because people expect Quality, Features and fixed release date, the truth is you have to pick two. I started to talk about switching from Quality+Features to Quality+Date aka time-based release. Not sure the community will agree but I don't want the next version to wait for 10 years. About SMTP : we use it on a small scale deployment and we have load-testing to exercise it, so yes, it's pretty stable I think. Regards, -- Matthieu Baechler On 05/22/2017 06:47 AM, Mahesh Sivarama Pillai wrote: Hi, Can someone please let me know the tentative date for James 3.0 GA ? We have to upgrade our current 2.3.2 in production to 3.0 as 2.3.2 doesn't support STARTTLS. Team is not recommending to deploy non GA version to production. Btw, is the SMTP component of James 3.0 RC stable ? Because our use cases need only SMTP. Thanks Mahesh - To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
Re: OOM on Specific Emails
Hi, On 04/26/2017 07:58 PM, Jerry Malcolm wrote: I've decided to take this in steps. My first objective is to just kill the email the first time it causes an OOM and at least stop it from going into an infinite loop trying to re-process it. My plan is to modify SetMimeHeader.java and add to to catch block. But I need help on what I can do to kill the email. Is there anything I can set in the Mail object or the MimeMessage object that will cause JAMES to just kill it or at least get it into a suspended state so JAMES won't restart it? Just set its state to GHOST and it won't go further in the pipeline. Thx. BTW... my next step is to analyze the message in that same catch block before killing it and hopefully figure out the characteristic that is causing the OOM and simply kill it before the OOM can even occur. But that's phase 2 Just want to stop the infinite loop first. The easiest thing to do is to dump it in a file and log an error with the path of the file IMO. Cheers, -- Matthieu Baechler - To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org