This week I implemented a memcache client for Postfix in the hope
that it would be useful to share postscreen(8) or verify(8) caches
among multiple MTAs.
The implementation is based on libmemcache. This was not too much
work, given a few examples (libmemcache is under-documented).
However, robustness tests (with a single memcache server) proved
disappointing.
* After failure to connect to the memcache server, libmemcache
reports the error once. From then on it silently discards all
updates and silently skips all lookups (returning "not found"),
even when the memcache server comes back in the meantime. To avoid
this, I destroy the memcache client and create a new one each
time that libmemcache reports an error, so that it never gets
to silently discard requests.
* Even more problematic is that libmemcache will terminate the
process when the memcache server connection is lost (the libmemcache
error message is: "read(2) failed: Socket is already connected").
Unfortunately, telling libmemcache not to terminate the process
will result in an assertion failure followed by core dump.
Conclusion: if we want robust code, then Postfix should use its own
memcache protocol implementation, instead of libmemcache. But that
is a lot of work and I may not have that much time.
Considering the robustness problems with the memcache client I would
not bundle it with mainstream Postfix.
However, there are patches floating around that implement Postfix
memcache support without doing anything about the bugs that I
described, especially the one where libmemcache silently discards
all updates and silently skips all lookups (returning "not found")
even when the memcache server has come back in the mean time.
For the people who use those patches, what I have is a lot better
(or less worse). Perhaps I'll make it available as a patch that
sites can apply by hand.
Wietse
