smtpd / qpsmtpd

qpsmtpd is a flexible smtpd daemon written in Perl
http://smtpd.github.io/qpsmtpd/
MIT License
138 stars 75 forks source link

How to load data once #282

Closed davidfavor closed 7 years ago

davidfavor commented 7 years ago

There seems to be a large difference between qpsmtpd-async + qpsmtpd-forkserver.

In qpsmtpd-async plugins instantiate once, so class variables persist across connections.

In qpsmtpd-forkserver plugins seem to instantiate for each connection.

This presents a problem if a plugin has to do some resource intensive work in the init() hook, which with async was called once + with forkserver is called every connection.

I've also tried switching between package main + plugin package to attempt creating persistent variables.

Let me know if there's some standard way to accomplish this.

Thanks.

msimerson commented 7 years ago

The async support for QP was a fine idea but like perl + async, it has never managed to make it out of the oven. Consequently, the half-baked QP async code has been removed entirely. The developers who wrote most of the QP async code went on to write QPs heir haraka, which is entirely async and written in a language where, for better and worse, async is a first class citizen.

msimerson commented 7 years ago

I'm remembering that with QP, if you need to do something expensive in a QP plugin (like a DB connection) then you're really going to feel the impact. Which is why plugins either used DBM or DB management started creeping into QP itself. It was just too expensive to set up and tear down those connections to resources on every single connection and still be able to reasonably scale QP.

davidfavor commented 7 years ago

I understand async is gone, which is why I'm asking this question.

I'll rephrase...

Let me know if there's an example plugin I can refer to which illustrates how to do expensive operations + have residue of said operations persist across all connections... like a database open, to do user authentication... where open occurs once when forkserver starts up.

Thanks.

shadowcat-mst commented 7 years ago

For reference: If you build your program from the ground up with IO::Async and Future you get a fairly similar (and IMO more polished in some respects) experience to node.js - but the learning curve isn't amazingly gentle, as usual for async.