Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [smila-dev] RE: Current Logging Settings

I agree with Daniel that "..everybody is free to change log4j settings..". For me to search in separate files it is much easier.  

Today it is easy to get lost and not to find the necessary records in a pack of messages. The surplus information litters the log.

Can be all the technical information to write down in debug and in info - only final and short messages: 

- Initializing Crawler...  

- some documents are processed and stored into the index 

(like as in AnyFinder)

2008-09-21 19:17:33,367                                 INFO  [rocessor23] - record modified  ... Vorwort.pdf]
2008-09-21 19:17:33,840                                 INFO  [rocessor23] - record modified [... WebAppTutorial.pdf]

Sonya


-----Original Message-----
From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Ivan Churkin
Sent: 29 сентября 2008 г. 12:52
To: Smila project developer mailing list
Subject: Re: [smila-dev] RE: Current Logging Settings


 >So while jconsole tells that the crawler starts successful, no other 
message tells that the crawler couldn´t insert the information to index.

Guess JMX events mechanism may be used to bring notifications back to 
jconsole...

--
Regards, Ivan Churkin

> The problem that caused error is related to other discussion
> http://wiki.eclipse.org/SMILA/Specifications/CrawlerAPIDiscussion09
> It's so called "CONTENT based HASH evaluation" API problem.
>
> 1. HASH calculated on CrawlerController side by DIData
> 2. CONTENT is a byte[]
> 3. DIData contains only literals
>
> I committed workaround that allows to avoid error.
>
> -- 
> Regards, Ivan
>
>
> Sofya Zhbankova wrote:
>> 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
>>   
>
> _______________________________________________
> 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

Back to the top