RE: SMTP Appender Problem
> I have a Problem with my SMTP Appender. > My program didn't found the triggering class, this is the ERROR message: Right, so it can't find the TriggerAfterXLogEvents class. Without further information about this class and how you've got log4j set up, we can't possibly help you any further. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SMTP Appender Problem
Hi I have a Problem with my SMTP Appender. My program didn't found the triggering class, this is the ERROR message: log4j: Parsing for [root] with value=[ERROR, amxsmtpapp]. log4j: Priority token is [ERROR]. log4j: Category root set to ERROR log4j: Parsing appender named "amxsmtpapp". log4j: Parsing layout options for "amxsmtpapp". log4j: Setting property [conversionPattern] to [%-4r [%t] %-5p %c %x - %m%n]. log4j: End of parsing for "amxsmtpapp". log4j: Setting property [subject] to [Severe Hardware Problem]. log4j: Setting property [bufferSize] to [5]. log4j: Setting property [threshold] to [ERROR]. log4j: Setting property [to] to [[EMAIL PROTECTED]]. log4j: Setting property [evaluatorClass] to [TriggerAfterXLogEvents]. log4j:ERROR Could not instantiate class [TriggerAfterXLogEvents]. java.lang.ClassNotFoundException: TriggerAfterXLogEvents at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:301) at org.apache.log4j.net.SMTPAppender.setEvaluatorClass(SMTPAppender.java:485) at java.lang.reflect.Method.invoke(Native Method) at org.apache.log4j.config.PropertySetter.setProperty(PropertySetter.java:196) at org.apache.log4j.config.PropertySetter.setProperty(PropertySetter.java:155) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:120) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:87) at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:637) at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:595) at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:502) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:410) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:309)log4j: Setting property [from] to [[EMAIL PROTECTED]]. log4j: Setting property [SMTPHost] to [192.168.103.5]. log4j: Parsed "amxsmtpapp" options. log4j: Finished configuring. at org.apache.log4j.PropertyConfigurator.configure(PropertyConfigurator.java:317) at amxsmtpapp.client.main(client.java:23)
Re: Custom Error Object into JDBCAppender
Joe, You could try the JDBCAppender I contributed (/contribs/KevinSteppe/JDBCAppender), which allows the SQL to be generated using a PatternLayout to extract the different portions of an error object into different database table columns (or even different tables if you write some complicated SQL). If your event object has fields that the standard PatternLayout doesn't have you'll need to extend PatternLayout to handle them. I'd be happy to help you if that doesn't solve the problem. Kevin Joe Sackett wrote: > Although the JDBCAppender is still an add-on to the > current version, I thought that maybe someone knew > how to handle this requirement of ours... > We need to pass an error context object containing > fields "keying" the location of and information about > the problem. The key and it's error description are > then written to both a log file and the database. > The difference being that while the whole error is > flattened to a string for placement in the log file, > the key and the information goes into separate fields > of the database. How can the fields of an error object > be passed from the category i.e.: > cat.error( new DeliveryError ( route, date, error_desc ) ); > and wind-up in: > JDBCSqlHandler.getStatement ( LoggingEvent event ) > > Any help would be greatly appreciated. > - Joe > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class A fault in rolling-file algorithm(s)
Thomas et. al, Thanks for the good news about finding the bug. I also believe that LogLog stuff is unclean (since it more or less duplicates the errorHandler functionality) and should be removed as soon as someone gets around to resolving any remaining difficulties in moving those statements to the errorHandler. About the xMB or xGB settings in CompositeRollingAppender -- When I test CompositeRollingAppender with a non-XML config file it works just fine. I did create the BeanInfo class used by RollingAppender to handle this overload, and the XML config stuff may require that for some reason. I don't understand why the plain text config works and your XML config does not. lastly sorry it's taken so long for me to get back to you Thomas. Kevin Thomas Tuft Muller wrote: > -all > > I can reassure all that the fault is *not* in the roll-strategy/algorithms. > It was not a concurrency bug in my own code either, but rather a combination > of rolling and the class > LOG4J_HOME/contribs/JimMoore/LoggingOutputStream.java. I'm probably not the > first one to fall into this trap. > > I haven't investigated the error, but it probably has to do with LogLog > logging to stdout/stderr and falls into infinite recursion (or something > like that). > > By pure accident I introduced file-rolling and the crucial class mentioned > above at the same time, withoug thinking about (or reading it in the > mailing-list-entries strategically located in the same folder as the class) > the implications for log4j itself that the standard streams are redirected. > > Must admit that the whole case is quite embarrassing for yours truly, but I > guess this is one the painful lessons one sometimes need to learn on the > path to omniscience ;) > > Thanks for everybodys concern and valuable feedback. > > Regards, > > -- > > Thomas > > | -Original Message- > | From: Thomas Tuft Muller [mailto:[EMAIL PROTECTED]] > | Sent: 27 September 2001 15:22 > | To: LOG4J Users Mailing List > | Subject: RE: Class A fault in rolling-file algorithm(s) > | > | > | Ceki, > | > | Please find my comments interspersed > | > | | On numerous occasions users have complained about deadlocks after > | | introducing log4j into their code. However, without exception the bug > | | was always in the application code not in log4j. Log4j may well > | | contain concurrency-related bugs but we need proof not vague > | | suspicions. Since you indicate that your code has a lot of concurrent > | | threads I suspect that the bug is in your code and not in log4j. > | > | You're probably right, but it may be worthwhile to attack the problem from > | both ends. > | > | | Which version of log4j is this? > | > | 1.1.3 (compiled with org.apache.log4j.CompositeRollingAppender, and an > | edited version of DOMConfigurator that reports errors with line-numbers > | included) > | > | | Which OS? > | > | Win 2000, 5.00.2195, Service Pack 2 > | > | | Which JDK? > | > | java version "1.3.0" > | Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) > | Java HotSpot(TM) Server VM (build 2.0fcs-E, mixed mode) > | > | | > | | >I've now tried endless combinations of parameters to the different > | | >rollingfile appenders (CompositeRollingAppender, > | | DailyRollingFileAppender, > | | >RollingFileAppender) in log4j and they all make the application > | | hang after a > | | >rollover-attempt. > | | > | | How do you know if the hang occurs within a rollover attempt? > | > | Well, I've set up the logs to roll at 00:00:00 and all logging stops at > | 23:59:50 (ish). After this point the application is completely dead, > | probably due to a deadlock. The files that were supposed to be created are > | not. > | > | | I suggest that you perform your tests using a RollingFileAppender > | | using a small MaxFileSize, say 100 bytes. > | > | OK, thanks. > | > | | I am looking forward for your test case. Regards, Ceki > | > | Will report back here as soon as I have something. > | > | BTW: CompositeRollingAppender reports and error if MaxFileSize is not > | defined as a long (it does not tolerate xMB or yGB). Guess this has > | something to do with the fact that the setMaxFileSize is overloaded with > | long and string, and the reflection mechanism picks the wrong method(?). > | > | -- > | > | Thomas > | > | > | | > | | > | | At 13:58 27.09.2001 +0100, Thomas Tuft Muller wrote: > | | >Stephen, > | | > > | | >Ceki pointed out that I was imprecise (and probably rude), and he was > | | >totally right. I went out of my way (my apologies to the log4j > | | development > | | >team). I didn't mean that other people should refrain from > | using log4j, I > | | >just pointed out that I personally will consider it in > | future/concurrent > | | >projects. > | | > > | | >This is by no means a proof that there is a flaw in Log4j, it > | | could turn out > | | >that it is in our application (even though it seems very > | unlikely at the > | | >time). This problem has my complete attent
Re: SNMP appender?
I am also interested in this appender as we have a requirement to generate these messages. "Mark Masterson" <[EMAIL PROTECTED]>@compuserve.com on 28/09/2001 04:47:56 Please respond to "LOG4J Users Mailing List" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]> cc: Subject: SNMP appender? Anybody have an appender that emits SNMP messages? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] NOTICE - This message is intended only for the use of the addressee named above and may contain privileged and confidential information. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action based upon it. If you received this message in error please notify HIC immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of HIC. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help Needed!
Hi Mark,
I am using the FileWatchdog and PropertyConfigurator as suggested by u. But I am not able to fix the puzzle. What I have now is individual parts and need your advice on placing things together.
I want to use RollingFileAppender with run-time configuration of the debug, errors and info messages (each type having a file). Now how to invoke the PropertyConfigurator class as well as the classes extended from FileWatchdog and PropertyConfigurator ? Also how to load the log4j config file?
We are using WeblogicServer6.0sp1 running 2 webapps. We need to log messages of this webapps to seperatelly and in three seperate files debug, errors and info respectively .
Can u give me soem pointers and if possible sample code ?
Thanx in advance
CIAOAjay
From: Mark Masterson
Subject: RE: modifying log levels through a management console
Date: Tue, 05 Jun 2001 08:16:39 -0700
You don't need to jump through this many hoops to get this behavior - there
is an easier way to achieve dynamic, run-time re-configuration using
standard config files. Specifically, you don't need to roll your own file
listener - Log4J already has one. To do this, you subclass FileWatchdog and
the appropriate PropertyConfigurator. For example, in our apps, we subclass
FileWatchdog and DOMConfigurator. Then, you override doOnChange() and
configureAndWatch(), in your FileWatchdog sub-class and your
PropertyConfigurator sub-class, respectively. In the PropertyConfigurator
sub-class's configureAndWatch() method, you set things up to use your
FileWatchdog sub-class (instead of a standard one), and in the doOnChange()
method of your FileWatchdog class, you call
BasicConfigurator.resetConfiguration(). In your application, you then need
to initialize Log4J by using your PropertyConfigurator class instead of the
standard one, i.e.;
"M2TraceDomConfigurator.configureAndWatch(configFile,configReloadDelay);"
and not "DOMConfigurator.configureAndWatch(configFile,configReloadDelay);".
Below are code snippets for the relevant spots from the implementation we're
using here - works fine. This question has already been answered at least
once on this list, primarily by Ceki and Jim Moore - you should check the
list archives for more details.
Cheers,
Mark
public class M2TracePropertyWatchdog extends FileWatchdog{
public void doOnChange() {
BasicConfigurator.resetConfiguration();
new DOMConfigurator().doConfigure(filename,
Category.getDefaultHierarchy());
}
}
public class M2TraceDomConfigurator extends DOMConfigurator {
public static void configureAndWatch(String configFilename, long delay) {
M2TracePropertyWatchdog pDog = new
M2TracePropertyWatchdog(configFilename);
pDog.setDelay(delay);
pDog.start();
}
}
Keep the Faith! Good Happens!!
>From: "Mark Masterson" <[EMAIL PROTECTED]>
>Reply-To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
>To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
>Subject: SNMP appender?
>Date: Thu, 27 Sep 2001 20:47:56 +0200
>
>Anybody have an appender that emits SNMP messages?
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
Get your FREE download of MSN Explorer at http://explorer.msn.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
basic socket server questions
Hi, all. I am confused on SocketServer. On SocketServer's main, it calls configureHierarchy() to find the hierarchy for the IP address. If ip address's LCF is not found, then it would generate a default hierarchy. I am not quite sure about hierarchy, that all I know is it sets the priority by the categories. In what case do I want to create a file file? I have 2 configuration files so far. One is for the SocketServer, another is for the Client which contains what appender I want to use and priorities on some categories. Now, I am not sure what kind of information suppose to be there in file. Could anyone help me out? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SNMP appender?
Anybody have an appender that emits SNMP messages? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class A fault in rolling-file algorithm(s)
-all I can reassure all that the fault is *not* in the roll-strategy/algorithms. It was not a concurrency bug in my own code either, but rather a combination of rolling and the class LOG4J_HOME/contribs/JimMoore/LoggingOutputStream.java. I'm probably not the first one to fall into this trap. I haven't investigated the error, but it probably has to do with LogLog logging to stdout/stderr and falls into infinite recursion (or something like that). By pure accident I introduced file-rolling and the crucial class mentioned above at the same time, withoug thinking about (or reading it in the mailing-list-entries strategically located in the same folder as the class) the implications for log4j itself that the standard streams are redirected. Must admit that the whole case is quite embarrassing for yours truly, but I guess this is one the painful lessons one sometimes need to learn on the path to omniscience ;) Thanks for everybodys concern and valuable feedback. Regards, -- Thomas | -Original Message- | From: Thomas Tuft Muller [mailto:[EMAIL PROTECTED]] | Sent: 27 September 2001 15:22 | To: LOG4J Users Mailing List | Subject: RE: Class A fault in rolling-file algorithm(s) | | | Ceki, | | Please find my comments interspersed | | | On numerous occasions users have complained about deadlocks after | | introducing log4j into their code. However, without exception the bug | | was always in the application code not in log4j. Log4j may well | | contain concurrency-related bugs but we need proof not vague | | suspicions. Since you indicate that your code has a lot of concurrent | | threads I suspect that the bug is in your code and not in log4j. | | You're probably right, but it may be worthwhile to attack the problem from | both ends. | | | Which version of log4j is this? | | 1.1.3 (compiled with org.apache.log4j.CompositeRollingAppender, and an | edited version of DOMConfigurator that reports errors with line-numbers | included) | | | Which OS? | | Win 2000, 5.00.2195, Service Pack 2 | | | Which JDK? | | java version "1.3.0" | Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) | Java HotSpot(TM) Server VM (build 2.0fcs-E, mixed mode) | | | | | >I've now tried endless combinations of parameters to the different | | >rollingfile appenders (CompositeRollingAppender, | | DailyRollingFileAppender, | | >RollingFileAppender) in log4j and they all make the application | | hang after a | | >rollover-attempt. | | | | How do you know if the hang occurs within a rollover attempt? | | Well, I've set up the logs to roll at 00:00:00 and all logging stops at | 23:59:50 (ish). After this point the application is completely dead, | probably due to a deadlock. The files that were supposed to be created are | not. | | | I suggest that you perform your tests using a RollingFileAppender | | using a small MaxFileSize, say 100 bytes. | | OK, thanks. | | | I am looking forward for your test case. Regards, Ceki | | Will report back here as soon as I have something. | | BTW: CompositeRollingAppender reports and error if MaxFileSize is not | defined as a long (it does not tolerate xMB or yGB). Guess this has | something to do with the fact that the setMaxFileSize is overloaded with | long and string, and the reflection mechanism picks the wrong method(?). | | -- | | Thomas | | | | | | | | At 13:58 27.09.2001 +0100, Thomas Tuft Muller wrote: | | >Stephen, | | > | | >Ceki pointed out that I was imprecise (and probably rude), and he was | | >totally right. I went out of my way (my apologies to the log4j | | development | | >team). I didn't mean that other people should refrain from | using log4j, I | | >just pointed out that I personally will consider it in | future/concurrent | | >projects. | | > | | >This is by no means a proof that there is a flaw in Log4j, it | | could turn out | | >that it is in our application (even though it seems very | unlikely at the | | >time). This problem has my complete attention now, and I'm in | | the process of | | >writing a test-program that hopefully can isolate the situations | | in which it | | >occures and hopefully give a hint of where the fault is. | | > | | >Will send the results to Jon Skeet who most kindly promised to | | look into it. | | > | | >Regards, | | > | | >-- | | > | | >Thomas | | > | | > | | > | | >| -Original Message- | | >| From: Stephen Levinson [mailto:[EMAIL PROTECTED]] | | >| Sent: 27 September 2001 13:34 | | >| To: 'LOG4J Users Mailing List' | | >| Subject: RE: Class A fault in rolling-file algorithm(s) | | >| | | >| | | >| Dear Ceki... | | >| | | >| I get the gist of the original message here... but what is your | | >| reply? | | >| | | >| We are gearing up to use log4j and this seems like an important | | >| issue | | >| | | >| ... Please explain.. | | >| | | >| Thanks alot, Stephen | | >| | | >| | | >| | | >| -Original Message- | | >| From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] | | >| Sent: Thursday, September
Re: Restarting logging after Disabling logging from a Configuration F ile
My recommendation is: 1. Only use info(), warn(), or error() method at the code 2. Use log4j.disable=DEBUG or log4j.disable=FATAL to turn on or off logging Java - Original Message - From: "Stephen Levinson" <[EMAIL PROTECTED]> To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]> Sent: Thursday, September 27, 2001 10:51 AM Subject: RE: Restarting logging after Disabling logging from a Configuration F ile So is there a way to toggle tracing completely ON and then Completely OFF and then completely ON , etc... at will? Thanks, Stephen -Original Message- From: Apache Java [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 10:44 AM To: LOG4J Users Mailing List Subject: Re: Restarting logging after Disabling logging from a Configuration F ile Stephen, After you add log4j.disableOverride=true, you can't use log4j.disable=FATAL to turn off logging Java - Original Message - From: "Stephen Levinson" <[EMAIL PROTECTED]> To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]> Sent: Friday, September 21, 2001 8:39 AM Subject: RE: Restarting logging after Disabling logging from a Configuration F ile I found my own answer: log4j.disableOverride=true restarts all logging... Cheers, Stephen -Original Message- From: Stephen Levinson [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 8:36 AM To: 'LOG4J Users Mailing List' Subject: Restarting logging after Disabling logging from a Configuration F ile I have found that with configureAndWatch(...) if I set log4j.disable=FATAL it turns OFF all logging... I can then change this to log4j.disable=DEBUG (or INFO, etc) and everything above debug turns on... But I can't get ALL logging to restart once I've set disable=FATAL ... Is there any way to do this? --Thanks, Stephen -Original Message- From: Stephen Levinson [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 8:17 AM To: 'LOG4J Users Mailing List' Subject: RE: Disabling logging from a Configuration File Can this be done via configureAndWatch(...) ??? If not, how to do this in real-time runtime...??? Thanks. --Stephen -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 5:30 PM To: LOG4J Users Mailing List Subject: Re: Disabling logging from a Configuration File Please, try log4j.disable=FATAL this will become log4j.enable=OFF in log4j version 1.2. Hope this helps, Ceki At 11:30 20.09.2001 -0600, you wrote: >As far as i know, it must be done through Hierarchy.disableAll() and >Hierarchy.disableAll(Priority) >Hierarchy.enableAll() can be called afterwards when required. > > >- Original Message - >From: "Stephen Levinson" <[EMAIL PROTECTED]> >To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]> >Sent: Thursday, September 20, 2001 9:32 AM >Subject: Disabling logging from a Configuration File > > >> Hi... >> I'm running with configureAndWatch(,,,) reading a configuration file >> for logging changes and control. >> >> Is there a way to totally DISABLE all logging ( like calling >> disableAll() ) ... by means of a setting in my configuration file? >> >> >> Thanks, Stephen > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü - http://qos.ch The world owes Israel a great debt for destroying Saddam's French built nuclear reactor in 1981 and thus preventing nuclear blackmail in the region and perhaps beyond. -- Garry Kasparov (yes, the chess player) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For addition
Re: Beginner Questions
On 21 Sep, 2001 Gunter Sammet wrote: "Try following code for the error logging: // make sure everything sent to System.err is logged System.setErr(new PrintStream(new LoggingOutputStream(Category.getRoot(), Priority.WARN), true)); Hope this helps!? Gunter" Where can I find the LoggingOutputStream class? I don't see it anywhere in the javadocs or jarfile... TIA for any info, kind regards, Ton van Bart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Restarting logging after Disabling logging from a Configuration F ile
So is there a way to toggle tracing completely ON and then Completely OFF and then completely ON , etc... at will? Thanks, Stephen -Original Message- From: Apache Java [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 10:44 AM To: LOG4J Users Mailing List Subject: Re: Restarting logging after Disabling logging from a Configuration F ile Stephen, After you add log4j.disableOverride=true, you can't use log4j.disable=FATAL to turn off logging Java - Original Message - From: "Stephen Levinson" <[EMAIL PROTECTED]> To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]> Sent: Friday, September 21, 2001 8:39 AM Subject: RE: Restarting logging after Disabling logging from a Configuration F ile I found my own answer: log4j.disableOverride=true restarts all logging... Cheers, Stephen -Original Message- From: Stephen Levinson [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 8:36 AM To: 'LOG4J Users Mailing List' Subject: Restarting logging after Disabling logging from a Configuration F ile I have found that with configureAndWatch(...) if I set log4j.disable=FATAL it turns OFF all logging... I can then change this to log4j.disable=DEBUG (or INFO, etc) and everything above debug turns on... But I can't get ALL logging to restart once I've set disable=FATAL ... Is there any way to do this? --Thanks, Stephen -Original Message- From: Stephen Levinson [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 8:17 AM To: 'LOG4J Users Mailing List' Subject: RE: Disabling logging from a Configuration File Can this be done via configureAndWatch(...) ??? If not, how to do this in real-time runtime...??? Thanks. --Stephen -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 5:30 PM To: LOG4J Users Mailing List Subject: Re: Disabling logging from a Configuration File Please, try log4j.disable=FATAL this will become log4j.enable=OFF in log4j version 1.2. Hope this helps, Ceki At 11:30 20.09.2001 -0600, you wrote: >As far as i know, it must be done through Hierarchy.disableAll() and >Hierarchy.disableAll(Priority) >Hierarchy.enableAll() can be called afterwards when required. > > >- Original Message - >From: "Stephen Levinson" <[EMAIL PROTECTED]> >To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]> >Sent: Thursday, September 20, 2001 9:32 AM >Subject: Disabling logging from a Configuration File > > >> Hi... >> I'm running with configureAndWatch(,,,) reading a configuration file >> for logging changes and control. >> >> Is there a way to totally DISABLE all logging ( like calling >> disableAll() ) ... by means of a setting in my configuration file? >> >> >> Thanks, Stephen > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü - http://qos.ch The world owes Israel a great debt for destroying Saddam's French built nuclear reactor in 1981 and thus preventing nuclear blackmail in the region and perhaps beyond. -- Garry Kasparov (yes, the chess player) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class A fault in rolling-file algorithm(s)
Where does " org.apache.log4j.CompositeRollingAppender " come from? It's not in my package... Thanks, Stephen -Original Message- From: Thomas Tuft Muller [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 10:22 AM To: LOG4J Users Mailing List Subject: RE: Class A fault in rolling-file algorithm(s) Ceki, Please find my comments interspersed | On numerous occasions users have complained about deadlocks after | introducing log4j into their code. However, without exception the bug | was always in the application code not in log4j. Log4j may well | contain concurrency-related bugs but we need proof not vague | suspicions. Since you indicate that your code has a lot of concurrent | threads I suspect that the bug is in your code and not in log4j. You're probably right, but it may be worthwhile to attack the problem from both ends. | Which version of log4j is this? 1.1.3 (compiled with org.apache.log4j.CompositeRollingAppender, and an edited version of DOMConfigurator that reports errors with line-numbers included) | Which OS? Win 2000, 5.00.2195, Service Pack 2 | Which JDK? java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) Java HotSpot(TM) Server VM (build 2.0fcs-E, mixed mode) | | >I've now tried endless combinations of parameters to the different | >rollingfile appenders (CompositeRollingAppender, | DailyRollingFileAppender, | >RollingFileAppender) in log4j and they all make the application | hang after a | >rollover-attempt. | | How do you know if the hang occurs within a rollover attempt? Well, I've set up the logs to roll at 00:00:00 and all logging stops at 23:59:50 (ish). After this point the application is completely dead, probably due to a deadlock. The files that were supposed to be created are not. | I suggest that you perform your tests using a RollingFileAppender | using a small MaxFileSize, say 100 bytes. OK, thanks. | I am looking forward for your test case. Regards, Ceki Will report back here as soon as I have something. BTW: CompositeRollingAppender reports and error if MaxFileSize is not defined as a long (it does not tolerate xMB or yGB). Guess this has something to do with the fact that the setMaxFileSize is overloaded with long and string, and the reflection mechanism picks the wrong method(?). -- Thomas | | | At 13:58 27.09.2001 +0100, Thomas Tuft Muller wrote: | >Stephen, | > | >Ceki pointed out that I was imprecise (and probably rude), and he was | >totally right. I went out of my way (my apologies to the log4j | development | >team). I didn't mean that other people should refrain from using log4j, I | >just pointed out that I personally will consider it in future/concurrent | >projects. | > | >This is by no means a proof that there is a flaw in Log4j, it | could turn out | >that it is in our application (even though it seems very unlikely at the | >time). This problem has my complete attention now, and I'm in | the process of | >writing a test-program that hopefully can isolate the situations | in which it | >occures and hopefully give a hint of where the fault is. | > | >Will send the results to Jon Skeet who most kindly promised to | look into it. | > | >Regards, | > | >-- | > | >Thomas | > | > | > | >| -Original Message- | >| From: Stephen Levinson [mailto:[EMAIL PROTECTED]] | >| Sent: 27 September 2001 13:34 | >| To: 'LOG4J Users Mailing List' | >| Subject: RE: Class A fault in rolling-file algorithm(s) | >| | >| | >| Dear Ceki... | >| | >| I get the gist of the original message here... but what is your | >| reply? | >| | >| We are gearing up to use log4j and this seems like an important | >| issue | >| | >| ... Please explain.. | >| | >| Thanks alot, Stephen | >| | >| | >| | >| -Original Message- | >| From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] | >| Sent: Thursday, September 27, 2001 7:35 AM | >| To: LOG4J Users Mailing List | >| Subject: Re: Class A fault in rolling-file algorithm(s) | >| | >| | >| | >| http://www.tuxedo.org/~esr/faqs/smart-questions.html | >| | >| At 10:57 27.09.2001 +0100, you wrote: | >| >Log4j users/developers | >| > | >| >I've now tried endless combinations of parameters to the different | >| >rollingfile appenders (CompositeRollingAppender, | >| DailyRollingFileAppender, | >| >RollingFileAppender) in log4j and they all make the application | >| hang after | >| a | >| >rollover-attempt. | >| > | >| >The application has a lot of threads and uses multiple appenders | >| for a lot | >| >of categories, some of them being async-appenders. | >| > | >| >This (unfortunately) shows that multithreading issues are NOT solved | >| >satisfactory in Log4j. Does anyone have any knowledge whether this is | >| >addressed by the development team, if there exists | fixes/updates etc? I | >| >could of course fix the problem myself, unfortunately my | >| schedule is pretty | >| >tight for the time being. | >| | >| >I'm seriously considering applying another loggi
Re: Restarting logging after Disabling logging from a Configuration F ile
Stephen, After you add log4j.disableOverride=true, you can't use log4j.disable=FATAL to turn off logging Java - Original Message - From: "Stephen Levinson" <[EMAIL PROTECTED]> To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]> Sent: Friday, September 21, 2001 8:39 AM Subject: RE: Restarting logging after Disabling logging from a Configuration F ile I found my own answer: log4j.disableOverride=true restarts all logging... Cheers, Stephen -Original Message- From: Stephen Levinson [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 8:36 AM To: 'LOG4J Users Mailing List' Subject: Restarting logging after Disabling logging from a Configuration F ile I have found that with configureAndWatch(...) if I set log4j.disable=FATAL it turns OFF all logging... I can then change this to log4j.disable=DEBUG (or INFO, etc) and everything above debug turns on... But I can't get ALL logging to restart once I've set disable=FATAL ... Is there any way to do this? --Thanks, Stephen -Original Message- From: Stephen Levinson [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 8:17 AM To: 'LOG4J Users Mailing List' Subject: RE: Disabling logging from a Configuration File Can this be done via configureAndWatch(...) ??? If not, how to do this in real-time runtime...??? Thanks. --Stephen -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 5:30 PM To: LOG4J Users Mailing List Subject: Re: Disabling logging from a Configuration File Please, try log4j.disable=FATAL this will become log4j.enable=OFF in log4j version 1.2. Hope this helps, Ceki At 11:30 20.09.2001 -0600, you wrote: >As far as i know, it must be done through Hierarchy.disableAll() and >Hierarchy.disableAll(Priority) >Hierarchy.enableAll() can be called afterwards when required. > > >- Original Message - >From: "Stephen Levinson" <[EMAIL PROTECTED]> >To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]> >Sent: Thursday, September 20, 2001 9:32 AM >Subject: Disabling logging from a Configuration File > > >> Hi... >> I'm running with configureAndWatch(,,,) reading a configuration file >> for logging changes and control. >> >> Is there a way to totally DISABLE all logging ( like calling >> disableAll() ) ... by means of a setting in my configuration file? >> >> >> Thanks, Stephen > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü - http://qos.ch The world owes Israel a great debt for destroying Saddam's French built nuclear reactor in 1981 and thus preventing nuclear blackmail in the region and perhaps beyond. -- Garry Kasparov (yes, the chess player) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class A fault in rolling-file algorithm(s)
Ceki, Please find my comments interspersed | On numerous occasions users have complained about deadlocks after | introducing log4j into their code. However, without exception the bug | was always in the application code not in log4j. Log4j may well | contain concurrency-related bugs but we need proof not vague | suspicions. Since you indicate that your code has a lot of concurrent | threads I suspect that the bug is in your code and not in log4j. You're probably right, but it may be worthwhile to attack the problem from both ends. | Which version of log4j is this? 1.1.3 (compiled with org.apache.log4j.CompositeRollingAppender, and an edited version of DOMConfigurator that reports errors with line-numbers included) | Which OS? Win 2000, 5.00.2195, Service Pack 2 | Which JDK? java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) Java HotSpot(TM) Server VM (build 2.0fcs-E, mixed mode) | | >I've now tried endless combinations of parameters to the different | >rollingfile appenders (CompositeRollingAppender, | DailyRollingFileAppender, | >RollingFileAppender) in log4j and they all make the application | hang after a | >rollover-attempt. | | How do you know if the hang occurs within a rollover attempt? Well, I've set up the logs to roll at 00:00:00 and all logging stops at 23:59:50 (ish). After this point the application is completely dead, probably due to a deadlock. The files that were supposed to be created are not. | I suggest that you perform your tests using a RollingFileAppender | using a small MaxFileSize, say 100 bytes. OK, thanks. | I am looking forward for your test case. Regards, Ceki Will report back here as soon as I have something. BTW: CompositeRollingAppender reports and error if MaxFileSize is not defined as a long (it does not tolerate xMB or yGB). Guess this has something to do with the fact that the setMaxFileSize is overloaded with long and string, and the reflection mechanism picks the wrong method(?). -- Thomas | | | At 13:58 27.09.2001 +0100, Thomas Tuft Muller wrote: | >Stephen, | > | >Ceki pointed out that I was imprecise (and probably rude), and he was | >totally right. I went out of my way (my apologies to the log4j | development | >team). I didn't mean that other people should refrain from using log4j, I | >just pointed out that I personally will consider it in future/concurrent | >projects. | > | >This is by no means a proof that there is a flaw in Log4j, it | could turn out | >that it is in our application (even though it seems very unlikely at the | >time). This problem has my complete attention now, and I'm in | the process of | >writing a test-program that hopefully can isolate the situations | in which it | >occures and hopefully give a hint of where the fault is. | > | >Will send the results to Jon Skeet who most kindly promised to | look into it. | > | >Regards, | > | >-- | > | >Thomas | > | > | > | >| -Original Message- | >| From: Stephen Levinson [mailto:[EMAIL PROTECTED]] | >| Sent: 27 September 2001 13:34 | >| To: 'LOG4J Users Mailing List' | >| Subject: RE: Class A fault in rolling-file algorithm(s) | >| | >| | >| Dear Ceki... | >| | >| I get the gist of the original message here... but what is your | >| reply? | >| | >| We are gearing up to use log4j and this seems like an important | >| issue | >| | >| ... Please explain.. | >| | >| Thanks alot, Stephen | >| | >| | >| | >| -Original Message- | >| From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] | >| Sent: Thursday, September 27, 2001 7:35 AM | >| To: LOG4J Users Mailing List | >| Subject: Re: Class A fault in rolling-file algorithm(s) | >| | >| | >| | >| http://www.tuxedo.org/~esr/faqs/smart-questions.html | >| | >| At 10:57 27.09.2001 +0100, you wrote: | >| >Log4j users/developers | >| > | >| >I've now tried endless combinations of parameters to the different | >| >rollingfile appenders (CompositeRollingAppender, | >| DailyRollingFileAppender, | >| >RollingFileAppender) in log4j and they all make the application | >| hang after | >| a | >| >rollover-attempt. | >| > | >| >The application has a lot of threads and uses multiple appenders | >| for a lot | >| >of categories, some of them being async-appenders. | >| > | >| >This (unfortunately) shows that multithreading issues are NOT solved | >| >satisfactory in Log4j. Does anyone have any knowledge whether this is | >| >addressed by the development team, if there exists | fixes/updates etc? I | >| >could of course fix the problem myself, unfortunately my | >| schedule is pretty | >| >tight for the time being. | >| | >| >I'm seriously considering applying another logging package, and I will | >| >discourage use of log4j for other projects until this is solved. | >| Dont' get | >| >me wrong, I think log4j is an excellent logging package despite a few | >| design | >| >deficiencies, but no telco production system can tolerate to risk | >| >application hangs as likely as the system today pr
RE: Class A fault in rolling-file algorithm(s)
On numerous occasions users have complained about deadlocks after introducing log4j into their code. However, without exception the bug was always in the application code not in log4j. Log4j may well contain concurrency-related bugs but we need proof not vague suspicions. Since you indicate that your code has a lot of concurrent threads I suspect that the bug is in your code and not in log4j. Which version of log4j is this? Which OS? Which JDK? >I've now tried endless combinations of parameters to the different >rollingfile appenders (CompositeRollingAppender, DailyRollingFileAppender, >RollingFileAppender) in log4j and they all make the application hang after a >rollover-attempt. How do you know if the hang occurs within a rollover attempt? I suggest that you perform your tests using a RollingFileAppender using a small MaxFileSize, say 100 bytes. I am looking forward for your test case. Regards, Ceki At 13:58 27.09.2001 +0100, Thomas Tuft Muller wrote: >Stephen, > >Ceki pointed out that I was imprecise (and probably rude), and he was >totally right. I went out of my way (my apologies to the log4j development >team). I didn't mean that other people should refrain from using log4j, I >just pointed out that I personally will consider it in future/concurrent >projects. > >This is by no means a proof that there is a flaw in Log4j, it could turn out >that it is in our application (even though it seems very unlikely at the >time). This problem has my complete attention now, and I'm in the process of >writing a test-program that hopefully can isolate the situations in which it >occures and hopefully give a hint of where the fault is. > >Will send the results to Jon Skeet who most kindly promised to look into it. > >Regards, > >-- > >Thomas > > > >| -Original Message- >| From: Stephen Levinson [mailto:[EMAIL PROTECTED]] >| Sent: 27 September 2001 13:34 >| To: 'LOG4J Users Mailing List' >| Subject: RE: Class A fault in rolling-file algorithm(s) >| >| >| Dear Ceki... >| >| I get the gist of the original message here... but what is your >| reply? >| >| We are gearing up to use log4j and this seems like an important >| issue >| >| ... Please explain.. >| >| Thanks alot, Stephen >| >| >| >| -Original Message- >| From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] >| Sent: Thursday, September 27, 2001 7:35 AM >| To: LOG4J Users Mailing List >| Subject: Re: Class A fault in rolling-file algorithm(s) >| >| >| >| http://www.tuxedo.org/~esr/faqs/smart-questions.html >| >| At 10:57 27.09.2001 +0100, you wrote: >| >Log4j users/developers >| > >| >I've now tried endless combinations of parameters to the different >| >rollingfile appenders (CompositeRollingAppender, >| DailyRollingFileAppender, >| >RollingFileAppender) in log4j and they all make the application >| hang after >| a >| >rollover-attempt. >| > >| >The application has a lot of threads and uses multiple appenders >| for a lot >| >of categories, some of them being async-appenders. >| > >| >This (unfortunately) shows that multithreading issues are NOT solved >| >satisfactory in Log4j. Does anyone have any knowledge whether this is >| >addressed by the development team, if there exists fixes/updates etc? I >| >could of course fix the problem myself, unfortunately my >| schedule is pretty >| >tight for the time being. >| >| >I'm seriously considering applying another logging package, and I will >| >discourage use of log4j for other projects until this is solved. >| Dont' get >| >me wrong, I think log4j is an excellent logging package despite a few >| design >| >deficiencies, but no telco production system can tolerate to risk >| >application hangs as likely as the system today proves. >| > >| >Regards, >| > >| >-- >| > >| >Thomas >| > >| > >| > >| > >| > >| > >| > >| > >| > >| > >| > >| > >| >* >| >Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights >| reserved. >| >Confidential. No liability whatsoever is accepted for any loss or damage >| >suffered as a result of accessing this message or any attachments. >| > >| >- >| >To unsubscribe, e-mail: [EMAIL PROTECTED] >| >For additional commands, e-mail: [EMAIL PROTECTED] >| >| -- >| Ceki Gülcü - http://qos.ch >| >| The world owes Israel a great debt for destroying Saddam's >| French built nuclear reactor in 1981 and thus preventing >| nuclear blackmail in the region and perhaps beyond. >|-- Garry Kasparov (yes, the chess player) >| >| >| - >| To unsubscribe, e-mail: [EMAIL PROTECTED] >| For additional commands, e-mail: [EMAIL PROTECTED] >| >| - >| To unsubscribe, e-mail: [EMAIL PROTECTED] >| For additional commands, e-mail: [EMAIL PROTECTED] >| >| > > > >**
Contrib: a reliable SocketAppender
Hi I have made a few mod's to the SocketAppender. You can now specify an additional optional parameter called 'dumpFilename' which gets written to when a connection cannot be established to the SocketServer. For example: (See attached file: SocketAppender.java) I apologise for the fact that the package is a non-apache one. Thanks Nigel -- Nigel Ramsay [EMAIL PROTECTED] Enterprise Java Consultant +44 20 7545 1590 Global Markets Research Deutsche Bank London, UK -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. SocketAppender.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class A fault in rolling-file algorithm(s)
> Will send the results to Jon Skeet who most kindly promised > to look into it. Like Stephen, I'd like to say thanks for the open post :) One thing though: I'll certainly look into any code you send me, but would you mind if others did too? I'm far from an expert on Log4j and the more eyes that look at this problem, the faster it's likely to be resolved :) If you'd like me to put the code up on my website somewhere temporarily, I'm happy to do that. Of course, if this is a matter of confidentiality instead, I'll happily respect that and look at it on my own. Cheers, Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class A fault in rolling-file algorithm(s)
Thanks for your *open* response ... and I, for one, will be looking forward to the resolution of this issue... regards, Stephen -Original Message- From: Thomas Tuft Muller [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 8:58 AM To: LOG4J Users Mailing List Subject: RE: Class A fault in rolling-file algorithm(s) Stephen, Ceki pointed out that I was imprecise (and probably rude), and he was totally right. I went out of my way (my apologies to the log4j development team). I didn't mean that other people should refrain from using log4j, I just pointed out that I personally will consider it in future/concurrent projects. This is by no means a proof that there is a flaw in Log4j, it could turn out that it is in our application (even though it seems very unlikely at the time). This problem has my complete attention now, and I'm in the process of writing a test-program that hopefully can isolate the situations in which it occures and hopefully give a hint of where the fault is. Will send the results to Jon Skeet who most kindly promised to look into it. Regards, -- Thomas | -Original Message- | From: Stephen Levinson [mailto:[EMAIL PROTECTED]] | Sent: 27 September 2001 13:34 | To: 'LOG4J Users Mailing List' | Subject: RE: Class A fault in rolling-file algorithm(s) | | | Dear Ceki... | | I get the gist of the original message here... but what is your | reply? | | We are gearing up to use log4j and this seems like an important | issue | | ... Please explain.. | | Thanks alot, Stephen | | | | -Original Message- | From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] | Sent: Thursday, September 27, 2001 7:35 AM | To: LOG4J Users Mailing List | Subject: Re: Class A fault in rolling-file algorithm(s) | | | | http://www.tuxedo.org/~esr/faqs/smart-questions.html | | At 10:57 27.09.2001 +0100, you wrote: | >Log4j users/developers | > | >I've now tried endless combinations of parameters to the different | >rollingfile appenders (CompositeRollingAppender, | DailyRollingFileAppender, | >RollingFileAppender) in log4j and they all make the application | hang after | a | >rollover-attempt. | > | >The application has a lot of threads and uses multiple appenders | for a lot | >of categories, some of them being async-appenders. | > | >This (unfortunately) shows that multithreading issues are NOT solved | >satisfactory in Log4j. Does anyone have any knowledge whether this is | >addressed by the development team, if there exists fixes/updates etc? I | >could of course fix the problem myself, unfortunately my | schedule is pretty | >tight for the time being. | | >I'm seriously considering applying another logging package, and I will | >discourage use of log4j for other projects until this is solved. | Dont' get | >me wrong, I think log4j is an excellent logging package despite a few | design | >deficiencies, but no telco production system can tolerate to risk | >application hangs as likely as the system today proves. | > | >Regards, | > | >-- | > | >Thomas | > | > | > | > | > | > | > | > | > | > | > | > | >* | >Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights | reserved. | >Confidential. No liability whatsoever is accepted for any loss or damage | >suffered as a result of accessing this message or any attachments. | > | >- | >To unsubscribe, e-mail: [EMAIL PROTECTED] | >For additional commands, e-mail: [EMAIL PROTECTED] | | -- | Ceki Gülcü - http://qos.ch | | The world owes Israel a great debt for destroying Saddam's | French built nuclear reactor in 1981 and thus preventing | nuclear blackmail in the region and perhaps beyond. |-- Garry Kasparov (yes, the chess player) | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | * Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved. Confidential. No liability whatsoever is accepted for any loss or damage suffered as a result of accessing this message or any attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class A fault in rolling-file algorithm(s)
Stephen, Ceki pointed out that I was imprecise (and probably rude), and he was totally right. I went out of my way (my apologies to the log4j development team). I didn't mean that other people should refrain from using log4j, I just pointed out that I personally will consider it in future/concurrent projects. This is by no means a proof that there is a flaw in Log4j, it could turn out that it is in our application (even though it seems very unlikely at the time). This problem has my complete attention now, and I'm in the process of writing a test-program that hopefully can isolate the situations in which it occures and hopefully give a hint of where the fault is. Will send the results to Jon Skeet who most kindly promised to look into it. Regards, -- Thomas | -Original Message- | From: Stephen Levinson [mailto:[EMAIL PROTECTED]] | Sent: 27 September 2001 13:34 | To: 'LOG4J Users Mailing List' | Subject: RE: Class A fault in rolling-file algorithm(s) | | | Dear Ceki... | | I get the gist of the original message here... but what is your | reply? | | We are gearing up to use log4j and this seems like an important | issue | | ... Please explain.. | | Thanks alot, Stephen | | | | -Original Message- | From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] | Sent: Thursday, September 27, 2001 7:35 AM | To: LOG4J Users Mailing List | Subject: Re: Class A fault in rolling-file algorithm(s) | | | | http://www.tuxedo.org/~esr/faqs/smart-questions.html | | At 10:57 27.09.2001 +0100, you wrote: | >Log4j users/developers | > | >I've now tried endless combinations of parameters to the different | >rollingfile appenders (CompositeRollingAppender, | DailyRollingFileAppender, | >RollingFileAppender) in log4j and they all make the application | hang after | a | >rollover-attempt. | > | >The application has a lot of threads and uses multiple appenders | for a lot | >of categories, some of them being async-appenders. | > | >This (unfortunately) shows that multithreading issues are NOT solved | >satisfactory in Log4j. Does anyone have any knowledge whether this is | >addressed by the development team, if there exists fixes/updates etc? I | >could of course fix the problem myself, unfortunately my | schedule is pretty | >tight for the time being. | | >I'm seriously considering applying another logging package, and I will | >discourage use of log4j for other projects until this is solved. | Dont' get | >me wrong, I think log4j is an excellent logging package despite a few | design | >deficiencies, but no telco production system can tolerate to risk | >application hangs as likely as the system today proves. | > | >Regards, | > | >-- | > | >Thomas | > | > | > | > | > | > | > | > | > | > | > | > | >* | >Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights | reserved. | >Confidential. No liability whatsoever is accepted for any loss or damage | >suffered as a result of accessing this message or any attachments. | > | >- | >To unsubscribe, e-mail: [EMAIL PROTECTED] | >For additional commands, e-mail: [EMAIL PROTECTED] | | -- | Ceki Gülcü - http://qos.ch | | The world owes Israel a great debt for destroying Saddam's | French built nuclear reactor in 1981 and thus preventing | nuclear blackmail in the region and perhaps beyond. |-- Garry Kasparov (yes, the chess player) | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | * Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved. Confidential. No liability whatsoever is accepted for any loss or damage suffered as a result of accessing this message or any attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class A fault in rolling-file algorithm(s)
> I get the gist of the original message here... but what is your > reply? As I read it, Ceki's reply is basically saying, "Please follow the guidelines in this document - in other words, give us some more data to work with, etc." It's important that this gets fixed, but without more information it'll be impossible to fix it. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class A fault in rolling-file algorithm(s)
Dear Ceki... I get the gist of the original message here... but what is your reply? We are gearing up to use log4j and this seems like an important issue ... Please explain.. Thanks alot, Stephen -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 7:35 AM To: LOG4J Users Mailing List Subject: Re: Class A fault in rolling-file algorithm(s) http://www.tuxedo.org/~esr/faqs/smart-questions.html At 10:57 27.09.2001 +0100, you wrote: >Log4j users/developers > >I've now tried endless combinations of parameters to the different >rollingfile appenders (CompositeRollingAppender, DailyRollingFileAppender, >RollingFileAppender) in log4j and they all make the application hang after a >rollover-attempt. > >The application has a lot of threads and uses multiple appenders for a lot >of categories, some of them being async-appenders. > >This (unfortunately) shows that multithreading issues are NOT solved >satisfactory in Log4j. Does anyone have any knowledge whether this is >addressed by the development team, if there exists fixes/updates etc? I >could of course fix the problem myself, unfortunately my schedule is pretty >tight for the time being. >I'm seriously considering applying another logging package, and I will >discourage use of log4j for other projects until this is solved. Dont' get >me wrong, I think log4j is an excellent logging package despite a few design >deficiencies, but no telco production system can tolerate to risk >application hangs as likely as the system today proves. > >Regards, > >-- > >Thomas > > > > > > > > > > > > >* >Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved. >Confidential. No liability whatsoever is accepted for any loss or damage >suffered as a result of accessing this message or any attachments. > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü - http://qos.ch The world owes Israel a great debt for destroying Saddam's French built nuclear reactor in 1981 and thus preventing nuclear blackmail in the region and perhaps beyond. -- Garry Kasparov (yes, the chess player) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class A fault in rolling-file algorithm(s)
http://www.tuxedo.org/~esr/faqs/smart-questions.html At 10:57 27.09.2001 +0100, you wrote: >Log4j users/developers > >I've now tried endless combinations of parameters to the different >rollingfile appenders (CompositeRollingAppender, DailyRollingFileAppender, >RollingFileAppender) in log4j and they all make the application hang after a >rollover-attempt. > >The application has a lot of threads and uses multiple appenders for a lot >of categories, some of them being async-appenders. > >This (unfortunately) shows that multithreading issues are NOT solved >satisfactory in Log4j. Does anyone have any knowledge whether this is >addressed by the development team, if there exists fixes/updates etc? I >could of course fix the problem myself, unfortunately my schedule is pretty >tight for the time being. >I'm seriously considering applying another logging package, and I will >discourage use of log4j for other projects until this is solved. Dont' get >me wrong, I think log4j is an excellent logging package despite a few design >deficiencies, but no telco production system can tolerate to risk >application hangs as likely as the system today proves. > >Regards, > >-- > >Thomas > > > > > > > > > > > > >* >Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved. >Confidential. No liability whatsoever is accepted for any loss or damage >suffered as a result of accessing this message or any attachments. > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü - http://qos.ch The world owes Israel a great debt for destroying Saddam's French built nuclear reactor in 1981 and thus preventing nuclear blackmail in the region and perhaps beyond. -- Garry Kasparov (yes, the chess player) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Class A fault in rolling-file algorithm(s)
> Log4j users/developers > > I've now tried endless combinations of parameters to the different > rollingfile appenders (CompositeRollingAppender, > DailyRollingFileAppender, > RollingFileAppender) in log4j and they all make the > application hang after a > rollover-attempt. > > The application has a lot of threads and uses multiple > appenders for a lot > of categories, some of them being async-appenders. > > This (unfortunately) shows that multithreading issues are NOT solved > satisfactory in Log4j. Does anyone have any knowledge whether this is > addressed by the development team, if there exists > fixes/updates etc? I > could of course fix the problem myself, unfortunately my > schedule is pretty > tight for the time being. > > I'm seriously considering applying another logging package, and I will > discourage use of log4j for other projects until this is > solved. Dont' get > me wrong, I think log4j is an excellent logging package > despite a few design > deficiencies, but no telco production system can tolerate to risk > application hangs as likely as the system today proves. Can you provide a log configuration file and a test program which will demonstrate the problem? It shouldn't be terribly hard to do if you just set up lots of threads hammering everything they possibly can. If you can come up with a complete test program I'll have a look and see what I can do. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Class A fault in rolling-file algorithm(s)
Log4j users/developers I've now tried endless combinations of parameters to the different rollingfile appenders (CompositeRollingAppender, DailyRollingFileAppender, RollingFileAppender) in log4j and they all make the application hang after a rollover-attempt. The application has a lot of threads and uses multiple appenders for a lot of categories, some of them being async-appenders. This (unfortunately) shows that multithreading issues are NOT solved satisfactory in Log4j. Does anyone have any knowledge whether this is addressed by the development team, if there exists fixes/updates etc? I could of course fix the problem myself, unfortunately my schedule is pretty tight for the time being. I'm seriously considering applying another logging package, and I will discourage use of log4j for other projects until this is solved. Dont' get me wrong, I think log4j is an excellent logging package despite a few design deficiencies, but no telco production system can tolerate to risk application hangs as likely as the system today proves. Regards, -- Thomas * Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved. Confidential. No liability whatsoever is accepted for any loss or damage suffered as a result of accessing this message or any attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
