[rsyslog-notify] Forum Thread: Re: blocking ompipe - (Mode 'reply')

[noreply at adiscon.com]

User: dlang 
Forumlink: http://kb.monitorware.com/viewtopic.php?p=24912#p24912

Message: 
----------
It's best to post to the mailing list for development items.

The module will need to be updated to 8.x (there were changes to the module
interfaces for 8.x)

As for your ideas

I would be a bit worried about the performance impact of having rsyslog
wait on the app on the other end of the pipe, but I can see cases where it
would be wanted.

There has been talk a few times about a polling mode for rsyslog, but the
headaches of doing so well have prevented anyone who's looked into it from
getting far enough.

In theory, it shouldn't be too ugly to create a polling mode of the RELP
code where the receiver initiates the connection instead of the sender, the
problem is that in rsyslog, the output module is not a separate thread that
sits and is always running, instead think of it as a library module that
the main worker thread runs when it needs to send something out.

As a result, the polling 'sender' would need to deliver the message to some
message store, and there would need to be a thread always running,
listening for connections, to feed data from this queue out.

This would be a major change to rsyslog that would not fit well with
everything else. The question is if it is the right thing to put this in
rsyslog instead of having rsyslog deliver the messages to some other tool
that then handles the polling/authentication/queued messages, etc. Rsyslog
already has support for 0mq and RabbitMQ, I think both of them have modes
that can be used for this.