There's nothing preventing Heka from growing the ability to dynamically add output plugins to the router. I'm not sure that's the right approach, though. Doing what you want means that you'd have one output plugin listening for connections, which would then be responsible for adding and removing additional output plugins to the router and managing their lifecycles, etc. It's possible, it's similar to what the SandboxManagerFilter does, but I think it introduces more complexity than is necessary.
Instead, I'd recommend doing everything you need inside the code for a single output plugin. If you set that output plugin up with `message_matcher = "TRUE"`, then every message will be delivered to the output. Inside the output code you can basically implement your own mini-router, which would instantiate message matchers and deliver matches out over the connections that registered them. -r On 06/23/2015 04:53 PM, David Birdsong wrote:
I keep running into a use-case where an inverted output plugin would be super-useful. Something like a websocket where as part of the request, the caller can specify a message matcher that gets registered w/ the router but deregistered when the connection goes away. Raw TCP would be fine too if there was a sensible way to specify the match syntax. This is really more of a pub/sub system, but one that can tap the streams of data going through heka while filtering out using the rich matching. If a dynamic filter can do add a new message_matcher, is there anything in the way of making that available to output plugins? _______________________________________________ Heka mailing list [email protected] https://mail.mozilla.org/listinfo/heka
_______________________________________________ Heka mailing list [email protected] https://mail.mozilla.org/listinfo/heka
