Dear piler users,
I'm about to release 1.3.0. It has a few new features,
it's mostly a maintenance release with bugfixes, minor
improvements.
tl;dr #1: 1.3.0 will be released on this week
tl;dr #2: if you use piler on FreeBSD or other non-Linux platform,
please drop me a line. There will be changes affecting you, see
the end of the email.
A short list of changes:
------------------------
* removed the pdf download icon from gui
tcpdf seems to have some issues if the email has images. Until
I find a better alternative this feature is hidden from the
users.
* added HTMLpurifier to sanitize the html mime parts
* rewritten pilerpurge in python
The purge utility uses lots of SQL as well, and it's much
easier to do the job using a script language. Also, it's
half the size in lines of code.
* improved search feature
the entered text is searched in all fields (subject, body, from, ...)
unless you specify an exact keyword (eg. subject:) to narrow the search.
Thanks for Epicenter to sponsor the feature!
* improving the smtp daemon
You may or may not noticed that I've created a new branch called
'epoll'.
The current piler daemon uses the preforking model: it spawns 10 or so
child processes that actually wait for an incoming smtp connection, and
handle the received email.
The 'epoll' branch features a separate smtp daemon for piler called
piler-smtp. It's a single process daemon using the epoll() mechanism
to process multiple connections effectively. It stores the received
emails in its queue directory which is read by piler processes. The
number of piler processes should be your number of of cpu cores + 1,
ie. 2 for a single cpu system.
As you can see the current approach uses 10+1=11 processes, however,
with epoll model uses 1+2+1=4 processes, while it can serve up to
64 parallel connections (can be set in piler.conf).
One example when the latter might be handy is receiving emails from
o365.
Usually 10 child processes are enough, however it seems that o365 has
no flow control, ie. in case of a spike in the email volume it tries
to overwhelm piler, and if all 10 children are busy, then return an
error to the sender, which is bad news.
In such case you have two options: either to increase the number of
the piler processes (that particular user had to increase the instance
size of the virtual machine in amazon aws to run 32 piler processes).
The other option is the epoll model which is able to handle such a spike
effectively with low memory footprint.
The bottomline is that 1.3.0 will be the last release to support the
preforking model. After that I'll switch to the epoll model. One
drawback
however, it's Linux only. I'm aware of that some of you use piler on
FreeBSD. I'll contact you to figure out something for you as well.
Best regards,
Janos
