Feature/stomp #3
Conversation
|
Looks great! Should we break out StompHandler into it's own file so we only have to define it once? It looks like mostly duplicated code between the input & output module. |
|
Yes, sure, I can do that. |
|
OK, I refactored the code to share most of the handler. Let me know if that's better. |
|
I don't see to get any kind of error message (at the normal logging level) if the stomp server is unreachable. I think we should at least @logger.warn() in that case. |
|
It looks like we can define an "unbind" function that gets called and we can warn about stomp connectivity problems, but AFAICT there's not a way to log a better reason. |
|
I'll look to this tonight. I think I need to override some callbacks from EM. |
Signed-off-by: Brice Figureau <[email protected]>
|
I pushed a new version with an unbind implementation. |
|
Commited, thanks! |
Change logic from using "chroot --userspec" (which doesn't work with RHEL5) to using "sudo". Side effects: 1. It's no longer possible to explictely set the group that LS will use (LS_GROUP variable removed). 2. Related to #1, supplemental groups for logstash will now work. 3. Due to the way that sudo behaves, I had to shift logfile creation to the non-privileged part, so on upgrades, if one doesn't explicitely chown existing logfiles, it will break. Regarding elastic#3: We could probably chown the logfiles to $LS_USER from within the init script...
ghost
mentioned this pull request
3 participants
Hi Jordan,
I implemented the Stomp input and output plugins for logstash.
It would be great if you could merge this upstream.
Let me know if you need more information or code change.
Thank you!
Brice