Async mails

[dereuromark]

First of all: Very nice documentation and everything. Awesome look and file on first glance!

Too small things though:
It would be good to not have those emails being actually "sent" synchronously.
This can further delay feedback to the user. Ideally those are put somewhere (like a queue), where another task can then collect those jobs and process the actual email sending part.

Another little thing: For a complete system failure this seems to trigger a lot of mails, like millions for a larger visitor count. I can only see an (optional) throttle for a certain blacklist etc, but not for a specific valid "admin mail" for example.
I would probably but a generic "throttle locking" in, that will based on a simple cache value or alike then completely stop sending those alert mails - as the admin sure already got enough of those?
Just some feedback here on the email sending issue.

[ebrigham1]

Thanks for the feedback @dereuromark

It would be good to not have those emails being actually "sent" synchronously.
This can further delay feedback to the user. Ideally those are put somewhere (like a queue), where another task can then collect those jobs and process the actual email sending part.

I agree and I like the idea of having an asynchronous option for emailing. However, I also like the idea of basic usage having as low a barrier of entry as possible by just using the default CakePHP email delivery profile so the developer doesn't need to install any queue libraries or worry about running any queue workers. What are your thoughts on something like this:

1. Add a key to composer.json to suggest dereuromark/cakephp-queue for email queuing capabilities.
2. Updated the "Advanced Usage" section of the documentation to add a "Queuing Email" subsection.
3. In "Queuing Email" subsection instruct developers to require dereuromark/cakephp-queue and link to that packages documentation. Follow that packages documentation to setup and configure the queue and worker. Then setup a a "Queue.Queue" email transport and a email delivery profile that uses it. Finally update the emailDeliveryProfile config value this plugin to use the email delivery profile you set up for the Queue.Queue email transport.

Another little thing: For a complete system failure this seems to trigger a lot of mails, like millions for a larger visitor count. I can only see an (optional) throttle for a certain blacklist etc, but not for a specific valid "admin mail" for example.
I would probably but a generic "throttle locking" in, that will based on a simple cache value or alike then completely stop sending those alert mails - as the admin sure already got enough of those?
Just some feedback here on the email sending issue.

I'm not sure I quite understand. Currently the way the system works is when throttle => true all errors/exceptions are throttled with skipThrottle => [] being an optional blacklist of exceptions/errors that should never be throttled or to put it another way they retain the behavior of throttle => false. This means if you receive an email about ExceptionX you will not receive another email about ExceptionX for 5 minutes (default cache config for plugin) even if its thrown again on your site in that time. Once 5 minutes has elapsed if ExceptionX is still being thrown on your site you will get 1 more email and then the 5 minute timer starts again. The cache key for the 5 minute wait timer is a composite of exception/error class, message, and code to determine uniqueness. In the event of a total system failure presumably you could have your multiple exceptions/errors being thrown simultaneously on different pages. This would result in you receiving 1 email every 5 minutes for every unique exception/error thrown as determined by the cache key described above.

If this still seems like it could result in too many emails I could potentially add some config values and functionality so the plugin can detect how many emails it sent in the past X minutes and halt emailing for Y minutes if it goes over Z threshold. With X, Y and Z being config values the developer can override.

Let me know if I've misunderstood the scenario you were presenting and feel free to add additional details to clear it up if I have. Thanks again for your feedback!

[dereuromark]

Well, maybe one doesn't have to go into details, just a small note about why this would be useful could suffice :)

OK, in most cases the errors you get are the same for all users (like DB not reachable), thus your current throttle could work.

I have build sth similar in my DatabaseLog - where it monitors and sends error reports (aggregrated) every x minutes etc as well as asynch. reporting tool.

I will then close this now. Feel free to add this to the awesome list: https://github.com/FriendsOfCake/awesome-cakephp