life happens, miscommunication happens, that's why we follow up :-)

I could summarize things, but I think it's probably better for you to do so, since you will probably be making the code changes.

If I get a chance to do some coding, I've got two projects I need to do

1. string module for json output.

2. sanitize mm module so that I can stick data into ES.

David Lang

On Wed, 11 May 2016, Kane Kim wrote:

Sorry guys, I was busy as well for a couple of weeks, let's reiterate what
we will have to do here. I guess as Rainer said first step should be to
write a test-bench script to automate this check. Please let me know where
it would be best to start and how we can help.

Thanks!

On Wed, May 11, 2016 at 1:35 PM, Rainer Gerhards <[email protected]>
wrote:

Sorry, I was under the impression that you wanted to look at this and
consequently put it off my to-do list. Looks like I need to re-schedule it,
probably for 8.20. Please let me know if you want to have a stab at it.

Rainer

Sent from phone, thus brief.
Am 11.05.2016 19:47 schrieb "Kane Kim" <[email protected]>:

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

Reply via email to