<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Ben,</div><div><br></div><div>Yeah that's true enough. Part of the difficulty, of course, is figuring out whether people are using it or not. I guess for now if we leave it outside the umbrella, at least we'll get some feedback from those who're interested in using it when they ask for it to be included. :)</div><div><br></div><div>Cheers,</div><div>Tim</div><br><div><div>On 1 May 2013, at 10:15, Ben Hood wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div>Hey Tim,
</div><div><br></div><div>I think the main thing is that if you can easily build the ez without having to set up another source tree and build process - the umbrella serves this purpose. I think if enough people actually start using it, you could then consider whether it is worth mainlining.</div><div><br></div><div>Cheers,</div><div><br></div><div>Ben</div>
<div></div><p style="color: #A0A0A8;">On Monday, 29 April 2013 at 11:23, Tim Watson wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>Folks - we have heard back from three of four people about this feature. Currently, that's not really what I'd call a 'critical mass' and certainly not enough for me to argue that we ought to provide lager support as part of the core broker ootb - Simon or Matthias may have a different opinion, but I wonder whether just providing this via a plugin is 'good enough' if it was included in the umbrella?</div><div><br></div><div>Thoughts on a postcard please - the more votes the more likely something will happen (one way or another).</div><div><br></div><div>Cheers,</div><div>Tim</div><div><br></div><div>On 26 Mar 2013, at 19:53, Tim Watson wrote:</div><div><br></div><blockquote type="cite"><div><div>I have set up an experimental repository at <a href="https://github.com/hyperthunk/rabbitmq-lager">https://github.com/hyperthunk/rabbitmq-lager</a> that supports logging to lager via its built in error_logger redirection. You enable via `rabbitmq-plugins enable lager` and configure it in the RabbitMQ config file just like any other plugin, under the key 'lager'. In the morning I'll chat with the guys about integrating this as experimental plugin for the time being, so people can play around and see if it offers the required functionality.</div><div><br></div><div>Cheers,</div><div>Tim</div><div><br></div><div>On 23 Mar 2013, at 23:06, Ben Hood wrote:</div><div><br></div><blockquote type="cite"><div><div>Hey Tim,</div><div>On Friday, 22 March 2013 at 07:55, Tim Watson wrote:</div><div><br></div><blockquote type="cite"><div><div>Yeah with the current implementation you'd need to install your own log handler to make that work. In terms of changing the output format though, allowe to play devil's advocate for a moment...</div><div><br></div><div>The info/progress/error reports have a lot of data in them, process stats, stack traces, etc. are you wanting to see all that plonked on one single long line? Because I can see how that'd make parsing/aggregating easier, but not reading them. Does the lager output fit exactly with what you want (I've not looks at it or a couple of years)?</div></div></blockquote><div>I don't think that everything needs to fit on one line. Longer traces which provide good context should probably remain as multiline entries. However, info items, for example,</div><div><br></div><div>Mar 22 22:33:01 a rabbit3: =INFO REPORT==== 22-Mar-2013::22:33:01 === </div><div>Mar 22 22:33:01 a rabbit3: Setting permissions for 'guest' in '/' to '.*', '.*', '.*' </div><div><br></div><div>need not get split up over two lines.</div><div><br></div><div>With regard to longer traces, it would be nice if they could be handled in such a way that the generic portion of the call stack were trimmed down to something nearer the actual call site, rather that the entire generic call trace. As inspiration, logback mitigates the default "root cause comes last" behavior in Java with the reverse depth layout modifier (rEx{depth}). Lot's of hand waving here though.</div><div><br></div><div>Finally, I do have to concur with Gavin on people's perception about Rabbit due to logging - I've have many conversations with people over the years who ask why Rabbit has such bizare logging - I've generally answered that this is an Erlang-ism, and though it is strange, the server kind of serves its primary function well (i.e. delivering messages), so just put up with it.</div><div><br></div><div>Cheers,</div><div><br></div><div>Ben</div><div>_______________________________________________</div><div>rabbitmq-discuss mailing list</div><div><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a></div><div><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a></div></div></blockquote></div></blockquote><div><br></div><div>_______________________________________________</div><div>rabbitmq-discuss mailing list</div><div><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a></div><div><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>
_______________________________________________<br>rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss<br></blockquote></div><br></body></html>