[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [smila-dev] AW: Current Logging Settings
|
If we choose the idea to separate the log in different files without a mainfile like EILF.log or otherwise, it´s necessary to >design the log clearly, so that information could be found better and messages are more helpfully.
As you already mentioned, the order of the runtime will be lost, so
system have to support complete log file.
Additional log files may be added but I'm not sure that it's info will
be enough.
bwt, for example, GREP may be used for investigating/filtering log file.
Allan Kaufmann wrote:
Hi folks
In my opinion we should keep EILF.log as one logfile that hold all logs of the different levels in order of the runtime, because while searching for information it´s difficult to look and sort with different logfiles. But maybe it could be helpful to received EILF.debug or EILF.error as additional file?
Sample: Our Logger is set to DEBUG, so EILF.log received all Logs until DEBUG-level. But if a developer just want information about errors, he could have a look to EILF.error.
Disadvantage: More performance because information could log more than one time.
If we choose the idea to separate the log in different files without a mainfile like EILF.log or otherwise, it´s necessary to design the log clearly, so that information could be found better and messages are more helpfully.
Allan
-----Ursprüngliche Nachricht-----
Von: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von Sofya Zhbankova
Gesendet: Montag, 29. September 2008 11:16
An: Smila project developer mailing list
Betreff: [smila-dev] RE: Current Logging Settings
Hi all,
and that if to separate a logging information in the different files: debugging messages to one file (EILF.debug) and other messages to another file (EILF.log). Most of all messages arrives from debug . It seems to me that it is possible few to "unload" debug. For example, whether it is necessary to deduce in the file a extracted content.
For example, at indexation of file EILF (for xml files ) EILF.log has 33 000 lines, the majority from which a extracted context. To search for the necessary information not so conveniently.
Sonya
-----Original Message-----
From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Allan Kaufmann
Sent: 19 сентября 2008 г. 12:58
To: Smila project developer mailing list
Subject: [smila-dev] AW: Current Logging Settings
Hi,
about the different log-levels and messages, I had seen an error like this:
- try to give the content tag of a filesystem indexorder the attribute HashAttribute="true"
- after starting the crawler with that indexorder I received a message that the crawler starts successfull, so it seems that there isn´t a problem
- but my crawler couldn´t crawl my files and the index hasn´t received entries
- I found following exception in my EILF.log:
2008-09-18 10:08:17,477 [Thread-14] INFO filesystem.FileSystemCrawler - Initializing FileSystemCrawler...
2008-09-18 10:08:17,520 [Thread-15] ERROR filesystem.FileSystemCrawler - Producer error
org.eclipse.eilf.datamodel.record.InvalidTypeException: Cannot use instance of class [B as literal value.
at org.eclipse.eilf.datamodel.record.impl.LiteralImpl.setValue(LiteralImpl.java:308)
at org.eclipse.eilf.connectivity.framework.utils.ConnectivityMObjectHelper.addSimpleLiteralAttribute(ConnectivityMObjectHelper.java:110)
at org.eclipse.eilf.connectivity.framework.crawler.filesystem.FileSystemCrawler$CrawlingProducerThread.createDIData(FileSystemCrawler.java:498)
at org.eclipse.eilf.connectivity.framework.crawler.filesystem.FileSystemCrawler$CrawlingProducerThread.treeWalk(FileSystemCrawler.java:454)
at org.eclipse.eilf.connectivity.framework.crawler.filesystem.FileSystemCrawler$CrawlingProducerThread.processFolder(FileSystemCrawler.java:424)
at org.eclipse.eilf.connectivity.framework.crawler.filesystem.FileSystemCrawler$CrawlingProducerThread.run(FileSystemCrawler.java:393)
So while jconsole tells that the crawler starts successful, no other message tells that the crawler couldn´t insert the information to index.
I think it could be helpful if users received errors like this and if log error gives important information like this but not too much. Currently the EILF.log shows much, so that exceptions and error like this could be overlooked.
Greetings
Allan
-----Ursprüngliche Nachricht-----
Von: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von Thomas Menzel
Gesendet: Donnerstag, 18. September 2008 17:04
An: smila-dev@xxxxxxxxxxx
Betreff: [smila-dev] RE: Current Logging Settings
hi,
my opinion on this:
1. loggin is there to help you, too much just doesn't.
2. have INFO level to show where the process/program is roughfly. if u have loops that are executed often or have many iterations than I think it is a good choice to just log every N iterations.
the overhead for this is minimal and the output a welcome indicator for anybody concerned about the progress and speed of a process/loop.
3. DEBUG: give verbose info that is needed for debugging purposes. that inlcudes most important the state of the process and involved objects
tom
-----Original Message-----
From: Sebastian Voigt
Sent: Donnerstag, 18. September 2008 16:44
To: smila-dev@xxxxxxxxxxx
Cc: Ralf Rausch; Allan Kaufmann; Thomas Menzel
Subject: Current Logging Settings
>From my point of view we have to much logging information in the EILF.log.
My Suggestion is to change the default logging settings to minimize logging information.
(Question is more, what do we have to see (ODE logging messages is an example).
We have to see errors messages thrown by the components, but we don't want to see every message from ode etc...
Kind regards
Sebastian
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev
------------------------------------------------------------------------
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev