[Building Sakai] James configuration

[SOO KIM]

I think... I have to specify our problem and our remedy for others.

Several sites in our sakai has hundreds of participants. (max: about 500).
There was long long delays(Max: 4 hours or so)  when faculty or TAs tries to
send announcements to the members (Specially using Mailtool). We have a
special mail server configuration for bulk mailing. Replacing with the mail
server for bulk mailing did not solve the problem. We figured out that
number fo main-sending threads and connections in James or Sendmail could
not accomodate the volumn of mail to be sent out. So we insert another
Sendmail to work like buffer which is configured to accept as many as 500
connections and about 500 threads to process. After the introduction of this
new configuration, we don't have any delay issue or lost-mail issue.

SOO IL KIM


On Wed, Mar 25, 2009 at 5:06 AM, David Horwitz <david.horwitz at uct.ac.za>wrote:

> Hi Michael,
>
> I'm not sure the exact cause of the james issue but with this
> configuration we avoid another problem that can occur with outbound
> email. This happens in cases where Sakai generates a large volume of
> outbound email, if you rely on javax.mail to deliver it to a third party
> server you may loose mail if it refuses connection. This way the mail
> will always be queued locally and delivered in the next queue run ...
>
> D
>
> Michael Wenk wrote:
> > David Horwitz wrote:
> >> Hi
> >>
> >> +1 you should set up you local MTA to accept slightly more
> >> connections than you have tomcat threads. Also you probably want to
> >> still keep low the threshold that the MTA will accept mail but not
> >> send it on to you institutional mail server. We have ours set to:
> >>
> >> #queue resources
> >> smtp_accept_max=250
> >> smtp_accept_queue=25
> >>
> >> This is exim but other MTA's like postfix and sendmail should have
> >> options that do the same.
> >>
> >> David
> >>
> >
> >
> > Any idea why this works?
> >
> > I enabled debugging on James, and during normal operation for
> > production, it uses at most 2 threads on our normal mail server.
> >
> > What really seemed to make our problem go away is to use a non load
> > balanced instance for mail.
> >
> > Mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090325/dfc65f31/attachment-0001.html