Dear Tech List, We continue to experience problems with the way our dspace application writes logs which in turn was causing our statistics pages to display incomplete data.
We posted this issue back in March and received the below reply from Mark Diggory in which he suggested that we apply this fix. We attempted the fix and it did not work. During that endeavor we discovered that there were multiple processes trying to write to the main dspace log. It seems that these processes were competing for a file output stream to the log. With this in mind, we have been attempting the approach of having only the main process write to the main dspace log with all other processes writing to a new auxiliary log. On our production server, we are now running a new version of dspace-oai that writes to the new aux log. Our plan is to test this for the next few days to see if it would be appropriate for us to promote to our production server. In the meantime, we would appreciate any more insight the dspace community might have for us. Thank you. Kyle Kaliebe Systems Developer/Engineer Knowledge Bank University Libraries Ohio State University [EMAIL PROTECTED] -----Original Message----- From: Mark Diggory [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 18:51 To: Kyle Kaliebe Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [Dspace-tech] inconsistent log output Hello, I think this occurred when there were changes to support log4j xml configuration files... the behavior became very hardcoded... And I undid it in the codebase for 1.5.x as one of my first commits as a dspace developer. I was very frustrated with how DSpace was controlling log4j configuration as it should really be handled by the containing application and not the way it is hardcoded into DSpace. In dspace 1.5.x you are able to start your Handle service with the following configuration, you will find that all logging configuration will be left up to that configured by the container.. > -Ddspace.log.init.disable=true So now the handle server starts up with > nohup $BINDIR/dsrun -Ddspace.log.init.disable=true - > Dlog4j.configuration=log4j-handle-plugin.properties > net.handle.server.Main $handledir </dev/null >> $logdir/handle- > server.log 2>&1 & Stopping DSpace from controlling logging. I think its horrible that we use log4j and the dspace.log to generate administrative/usage statistics, its a messy cesspool and will always be brittle like this. It needs changing and this is something that the GSoC Statistics project addressed somewhat last year. ---- I've attached a jar that contains my changes to ConfigurationManager if you place into your [dspace.dir]/lib directory, then it should allow you to set your log4j settings for the start-handle-server script above. Please be aware this is at your own risk, but I've used this approach in the past. You need to do the following. 1.) add one of the following line to your dspace.cfg log.init.config = ${dspace.dir}/config/log4j.properties log.init.config = ${dspace.dir}/config/log4j.xml 2.) place the jar in your lib directory 3.) change any startup scripts to use "-Ddspace.log.init.disable=true -Dlog4j.configuration=<your file in ${dspace.dir}/config>" likewise you can also designate it as an absolute url "file:///some/ path/to/log4j.properties" Cheers, Mark -----Original Message----- Dear Dspace tech list, We are having issues with the way our dspace.log file is being written. We believe this behavior began with our upgrade to version 1.4.2. The main issue is that our handle server is writing its logs to dspace.log in lieu of handle-plugin.log. This is causing issues with functionalities that are dependent on dspace.log (things like administrator statistics). We have ensured that our handle server is configured to write to handle-plugin.log. Whenever we restart our handle server, it writes logs to handle-plugin.log for a few seconds, then switches to dspace.log. In addition, the expected input to dspace.log is sometimes blocked altogether. We have made sure that all relevant files and processes are being run as the installing linux account. Kyle Kaliebe Systems Developer/Engineer Knowledge Bank University Libraries Ohio State University [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
