2016-04-21 9:57 GMT+02:00 David Lang <[email protected]>: > On Thu, 21 Apr 2016, Rainer Gerhards wrote: > >> 2016-04-21 9:35 GMT+02:00 Kane Kim <[email protected]>: >>> >>> Thanks for great explanation, David, that really helped me to understand >>> this part. What I'm suggesting is essentially this (and please correct me >>> if I'm telling obviously stupid things): >>> 1. Server tries to tell action1 to deliver messages (calling >>> EndTransaction) and has a loop here until it succeeds. >>> 2. Server tries to tell action2 to deliver messages (calling >>> EndTransaction) and has a loop here until it succeeds. >>> 3. Queue is locked/marked delivered/unlocked. >> >> >> one final for today: you need to read and understand all the >> queue/wtp/wti/ruleset methods. > > > Yes, what I am saying is the conceptual framework that we planned back in > 2006, the exact way that things have been broken up in the code with the > different API calls will hopefully map to the concepts I described (assuming > they do, I'll write up a more formal conceptual document with diagrams so > that we can have this all documented for the next time we have to look at it > in the future :-)
from my memory, your description should be pretty close. I *think* when commitTransaction is hit we may already have removed messages from the queue, because we may otherwise potentialy submit them too *all other* actions as well, which can cause great confusion. At some point, we need to accept that we simply cannot undo everything and at some point it possibly doesn't make sense to force each and everything to be retried a myriad of times. Maybe a config option. But again, my memory is probably not 100% accurate, and this is why it is so important (and time consuming!) to adress this very precisely and (IMHO) in a step-by-step manner. In regard to the writeup, I'd either develop it side-by side (inside the project as text file) with this effort or wait until all details are re-verified. Rainer PS: yes, I couldn't stand to read and reply ;) > > David Lang > > >> That's also one of the main things for >> me to take time (memory doesn't server well if you need to be very >> specific). I guess this does not work, and much of the engine already >> does that for you. You can probably avoid much of that work if you >> follow my guideline and do it in the steps I proposed, because as you >> implement it that way, you'll naturally see how this works out with >> the rest of the engine. Note that the comment suggest this was meant >> to do at that place. So I personally would safe me that day or two of >> deep code reading and just take the three-step approach. But your >> YMMV. The plugin API doesn't need to change for that, there is >> sufficient provisioning inside it for extension (at least I think so). >> But again, it's already later over here and I have not yet done doing >> any real work on the things I really need to get done today... >> --Rainer >>> >>> >>> As Rainer mentioned above that would lock only current queue where those >>> actions executed. >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com/professional-services/ >>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T >>> LIKE THAT. >> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com/professional-services/ >> What's up with rsyslog? Follow https://twitter.com/rgerhards >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T >> LIKE THAT. >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
