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 > > >
