Hello Rainer, What's your plan on getting this to start moving. Do you plan to work on it or you need some help?
Thanks! On Thu, Apr 21, 2016 at 1:16 AM, David Lang <[email protected]> wrote: > On Thu, 21 Apr 2016, Rainer Gerhards wrote: > > 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. >> > > that's what I suspect as well based on these discussions. > > 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. >> > > we'll let Kane look at the code and see how it matches what we think it's > supposed to do (always a good double-check :-) > > 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. >> > > sounds good. > > David Lang > > > 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. >> >> _______________________________________________ > 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.
