The email deliveries will be so fast (from an ofbiz perspective) when queuing locally that it'll be a non-factor. You can queue 10 of thousands of emails per minute. You don't want to waste valuable java threads physically sending email.
On Fri, Feb 22, 2019 at 8:30 AM Amit Cahanovich <[email protected]> wrote: > Thanks for the advise, i suppose its refering point #2, and i will > definitely do so. but what about point#1, adding additional state, in order > to avoid next sendEmailDated job instance picking same communication event? > > בתאריך יום ו׳, 22 בפבר׳ 2019, 17:55, מאת Mike <[email protected]>: > > > If you're going to send that many emails in one operation, you should be > > queuing emails to a LOCAL email service (i.e. postfix on 127.0.0.1). > This > > is overall a good idea: > > > > 1) Fast queuing (ofbiz considers delivery a success). > > 2) You have the ability to 'adjust' the email headers, senders. > > 3) Background sending/delivery. > > > > Some recipients may have bad or non-existent MX records, slow delivery, > > etc. Let postfix worry about the physical delivery of the email, not > > ofbiz. Email setup is sort of a black art, but it's the proper way to do > > this. Seek expert advice if necessary. > > > > > > > > > > > > On Fri, Feb 22, 2019 at 2:45 AM Amit Cahanovich <[email protected]> > > wrote: > > > > > Hi, > > > sendEmailDated is scheduled by default to wake up every 15 minutes. > > > I got into situation, that the service woke up, and previous exceution > > did > > > not finish, hence the file was collected again, what ended out in > > infinite > > > email sending (i was sending mail to 5000 customers, and it took more > > than > > > 15 minutes, and each time it was recognized as event that need to be > > sent). > > > > > > i think the following mechanisms need to be implemented, in order to > > avoid > > > the communication events to be picked more than once, and in order to > > make > > > sure, that mail will not be sent twice. > > > > > > 1) adding another state to communicationEvnet, that symbolize that > > records > > > the message send is being picked up (as of now, the service is picking > up > > > In-Progress and change it to Complete when ending), i suggest to add > the > > > status "sending", so when the sendEmailDated wakes up, before it starts > > > sending, its taking ownership for it, and the next instance that wakes > > up, > > > will not pick the communication event. > > > > > > 2) i think that the suggestion i described in #1, is still not good > > enough, > > > and there should be record level mechanism to avoid multiple sending of > > > same message (e.g. in case the service crushes, and being reexcuted, > need > > > to still not send same email twice). > > > The current mechanism, uses same transaction for all the mail that need > > to > > > be sent. > > > i sugget the following mechanism instead: > > > > > > making new transaction for every individual mail send. the transaction > > will > > > call the following: > > > create unique constraint on CommunicationEvent for the combination of > > > parentCommEventId > > > and contactMechIdTo. > > > when sending individual message, > > > > > > - create the individual communication event (for each and every > > > recepient,): > > > if its already there, rollback the transaction (this means that the > mail > > > already been sent): this will avoid continue send mail in case it was > > > already sent > > > - send the email > > > if there is a problem with sending the mail, rollback the transaction, > > and > > > then the individual communication event will not be created > > > in this case, we can ensure that the mail will never be sent twice. > > > > > > Comments will be appreciated. > > > Thanks, > > > Amit > > > > > >
