Am 30.05.2014 um 14:57 schrieb Esteban A. Maringolo <emaring...@gmail.com>:
> 2014-05-30 6:41 GMT-03:00 Norbert Hartl <norb...@hartl.name>: > >>> * It's pretty much free (though this is not a relevant factor ) >> Well, it is 12000 emails free per month. > > We will send arount 3000 per month, and the $1.5 per 10000 of Postmark > wasn't expensive either. > >>> Assuming you flag the transactions as "mailSent" or similar. >> Mariano is referring to a piece of code I’ve sent him. This one > >> ((mailResponse first at: 'status') = 'sent') >> ifTrue: [ self persistence changeStateOf: participant to: #emailSent ] >> ifFalse: [ self persistence changeStateOf: participant to: #emailFailed ]. >> self emptyOkResponse > > I was taking about a general pattern, of having a flag in the object, > a log or both. I just need a flag (actually two). > > >> There are a lot of ways you can do that. From your description I assume you >> have quite some incoming requests that should return quickly. Furthermore >> you want to keep exact track of the sent email and react to unexpected >> cases, right? > > Not really that much, but the email is not as important as the > transaction being submitted (through a REST url), so I try to separate > concerns as much as I can. > >> In my case I don’t have these requirements. The request rate is pretty low >> and there is no effect to the user if a request to my handler takes longer. >> So I decided to use the synchronous API from Mandrill. So I get back the >> status immediately and can flag the action as OK or failed. I don’t need >> more because if a message is not delivered from time to time it is no >> problem. So I guess I’m in case #1 > > Here the volume isn't high, I'm simply worried about what a failure in > the sending of the mails could affect the "stability" of the whole > server (which is going to be a single image). > I don’t think this is an issue. After my last fight with max external semaphores I have some use cases that use outgoing requests on incoming requests. Resource wise it is not a problem and if you put an exception handler around the mail sending it won’t affect the rest at all. Using a SharedQueue and detach the sending completely might be a good idea if you have doubts. Norbert >> If your requirements are different I’d probably wouldn’t take the effort to >> do #2. It gets complicated really quick. If we have another view on the >> Mandrill API webhooks come to the rescue [1]. In your request handler you >> send the message asynchronously. The status in the message is „queued“ then. >> If you have the webhooks registered you get called from mandrill whenever >> the status of a mail send changes. That is probably the best option because >> no need to poll anything.There is no support for that in the Mandrill API at >> the moment. But I’m interested in this as well and could collaborate on >> that. > > Webhooks seems to be way to go if I want to defer the sending. > >> I think #3 would be really heavy weight for the task. My advize is not to do >> these kind of things until you really know that you need it. Complexity >> kills! > > I know... I won't do such thing unless there is another requirement > that justifies it. > However, I'm always tempted to use MQs an similars, it is the message > sending paradigm taken to a different level :D But a poor one :P Sometimes I tend to look at these things to. But then I see instead of the message sending I know you have (again) put some format as least common denominator in order to have your request take action. Context and all the important bits are lost that way. So even for a queue I would like to use something more close to our message sending. Norbert
