2015-01-13 14:50 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Jan 2015, at 18:27, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
2015-01-13 5:17 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Jan 2015, at 07:00, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
First of all, I am not the developer of Log4s, but I have been using it for a while and I see no significant gain switching to SystemLogger or ZnLogEvent. As Alain said, it is based in Log4j, which has his own Wikipedia page: http://en.wikipedia.org/wiki/Log4j
I don't think there is too much sense in having "Log Objects" around, where probably I want to tail a daily rolled log from a headless remote image. I read the documentation of SystemLogger hoping to find a mechansim which dynamically selects compression strategies based in what's logged, or some other advanced feature, but I didn't found any :(
Maybe we should do away with Events as objects, Methods as objects, Exceptions as objects, Announcements as objects, Ring, MC, Commands as objects, Windows, Menus, ... - well, this whole objects everywhere thing is silly, let's use strings instead ;-)
Sarcasm is never the answer. Let's focus on logging, and specifically the case with remote image where you don't have access to "local log objects". I suppose there are other (specially web) developers with the same requirement.
The analogy was to make a point, but you don't seem to see it, too bad. It is technically easy to export log objects out of an image.
Instead of analogies, I would love to read about how your Log system proposals works with headless images. Because to me it is really easy to write a grep command (I don't have to *explore* logs).
We'll keep on trying to explain and to explore the possibilities.
Log objects are much more powerful, less expensive than you think, and backwards compatible with textual output.
If I have to use a bayesian model with markov chains, which could take up to 1 million of samplings only to begin stabilization, and I want to log them... do you expect to have every entry as a Log object... right? That would be less expensive in terms of memory and speed than flushing to a text file?
That would only be true if you kept them all in memory. That is an orthogonal point.
So you didn't answered my questions. Do I have to create 1 million of log objects and that is less expensive than flushing them as they occur into a file? What's the point of creating objects if I don't need them?
<sorry-for-the-sarcasm>A String instance is an object too, composing/formatting a log message is a computation too, similar to serialising an object in some format.</sorry-for-the-sarcasm>
I see. In the end we (still) read Strings, whatever conceptualization is above them.
Logging is deceptively simple, managing megabytes of log files is a PITA. Structure, classification, intelligence, behaviour are the answers.
BTW, it is not that you are not allowed to log some simple things to the Transcript, it is that it does not really scale, conceptually.
In my system I am not logging to the Transcript (which obviously does not scale).
I was using the Transcript as an example of a text based logging facility. I meant that it doesn't scale conceptually, it becomes one big mess of dozens of log files that helps very little.
Look, you don't have to use any form of Object Logging if you fail to see the point, there is nothing wrong with logging to a file. I was just trying to explain.
The point is isn't just me. I haven't seen any intensive computation software which creates log objects for self-exploration. And if you find one, I could cite 100 of them which does "String logging", and they just work, and people using it is not stupid, they know they have limitations, it happens that they prioritize other requirements.
We have dozens of servers producing many, many log files, most of them produced by log4j, writing more than 1Gb a day. 90% of that is a waste, but it is never enough. And it is a big mess. Even our Java developers say so. And what are they looking at ? Right, storing JSON log objects in searchable databases. (LogStash, ElasticSearch, blabla, ..).
It is weird to read sometimes how Java developers have it so wrong, and sometimes they are visionary souls which drive us into the future. Hernán