----- "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; wrote: > I see 3 different issues here: > > 1) Code that does per-request logging at DEBUG level instead of TRACE. > > That's in violation of the logging standards and should be fixed. +1 and that is what we are seeing to some extent. We don't regularly need to known every time a class is loaded, or a persistence connection is closed. > 2) How much we log at DEBUG as part of service startup/shutdown. > IMHO, > this is not a huge problem. We should probably clean it up some, but > > the point of the logging is to make problem diagnosis easier, not to > produce small logs for infrequent events. Start up time in no little issue, but in general I agree. if there is extra logging during start up thats fine. The real issue is the reoccurring logs > 3) The default loggging level for server.log. If #1 is broken, then > having it be INFO makes sense, otherwise we punish users for our > problems. If #1 is fixed, then different people can have different > preferences, which I expect we're about to debate here. :-) My > personal > one is to leave it at DEBUG, unless we can make it configurable via > system property substitution. Otherwise all testsuite runs will log > at > INFO unless we introduce testsuite hacks to replace the logging conf. IMO - I would like to see it at info, and use an ant command to adjust the debug level for hudson builds. Why punish our users so that the continuous builds log enough.

> Jay Balunas wrote: >> I personally think that this give a poor first impression of AS. > Especially since it does not show in console, so users will not be > immediately aware of the cause until they investigate the logs. >> my $.02 >> >> Jay >> >> ----- "Galder Zamarreno" <galder.zamarreno(a)redhat.com&gt; wrote: >> >>> Hi, >>> >>> Jay Balunas wrote: >>>> I posted this up to the Design of POJO Server forum, but I'm not >>> sure if that was the correct place there was not a "Design of AS" > ;-) >>>> While doing some performance testing for Seam I noticed that the >>> default logging for AS 4.2.3 and AS 5.0 CR2 was set to debug, Note >>> that console logging is limited to info so this only shows in the >>> log. >>>> This causes huge performance issues and exposes the user to way > too >>> much information. I have discussed this on the EAP side in >>> JBPAPP-1187. They fixed it to some degree, but it still needs some >>> work. >>>> This is basically what I'm seeing >>>> >>>> Starting 4.2.3 - 1.2 mb - with app >>>> Starting 5.0 CR2 - 1.3 mb - with no app >>>> >>>> A few requests with one user and seam app creates MBs of logs. >>>> >>>> >From my testing performance hit was huge. The average went from > 14 >>> sec to 4 sec with 50 users and 25 requests each when I switched > the >>> threshold for the log file to info. The server.log file size (with > a >>> few requests) was only 97kb compared to the 1.2 above with just >>> starting the server. That test was with 4.2.3 not 5.0. >>>> Is there a reason that the logging is set this way? My opinion is >>> that we should give the user the best initial performance, and > concise >>> information. >>> >>> IMO, it depends on what you're using it for. For >>> production/staging/loadtesting yes, for development no. >>> >>> cc'ing jboss-dev >>> >>> >>>> Thoughts? >>>> >>>> Thanks, >>>> Jay Balunas >>>> >>> -- >>> Galder Zamarreño >>> Sr. Software Maintenance Engineer >>> JBoss, a division of Red Hat > > -- > Brian Stansberry > Lead, AS Clustering > JBoss, a division of Red Hat > brian.stansberry(a)redhat.com

Jay Balunas wrote: > ----- "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; wrote: >> I see 3 different issues here: >> >> 1) Code that does per-request logging at DEBUG level instead of >> TRACE. >> >> That's in violation of the logging standards and should be fixed. > +1 and that is what we are seeing to some extent. We don't > regularly need to known every time a class is loaded, or a > persistence connection is closed. >> 2) How much we log at DEBUG as part of service startup/shutdown. >> IMHO, this is not a huge problem. We should probably clean it up >> some, but >> >> the point of the logging is to make problem diagnosis easier, not >> to produce small logs for infrequent events. > Start up time in no little issue, but in general I agree. if there > is extra logging during start up thats fine. The real issue is the > reoccurring logs >> 3) The default loggging level for server.log. If #1 is broken, >> then having it be INFO makes sense, otherwise we punish users for >> our problems. If #1 is fixed, then different people can have >> different preferences, which I expect we're about to debate >> here. :-) My >> personal one is to leave it at DEBUG, unless we can make it >> configurable via system property substitution. Otherwise all >> testsuite runs will log >> at INFO unless we introduce testsuite hacks to replace the logging >> conf. > IMO - I would like to see it at info, and use an ant command to > adjust the debug level for hudson builds. Why punish our users so > that the continuous builds log enough. Log4j supports a basic system property substitution, so the server.log logging level can be controlled that way. I'll selfishly add that -- since it will help Bela in some stuff he's doing this week that in turn helps me. ;) https://jira.jboss.org/jira/browse/JBAS-6205 Note that JBAS-6205 doesn't include changing the default to INFO. I think INFO's fine, but it's not my call and in any case it's a separate JIRA that involves some extra work (to get the testsuites to log at DEBUG). -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com

https://jira.jboss.org/jira/browse/JBAS-6205 is done. Shelly, if there is going to be a new server-manager release, how about we add a -Djboss.server.log.threshold=DEBUG to the args that get passed when an AS is started? That's a quick way to ensure testsuite configs launch with the correct level if we move the default to INFO. Otherwise we'd have to figure out all projects that use server-manager and edit their build file server:config elements. Jay Balunas wrote: > OK thanks for the update. This property should make it very easy to > adjust this for the test environment while still allowing us to ship AS5 > in a configuration that does not created MBs of logs. > > On Nov 17, 2008, at 3:13 PM, Brian Stansberry wrote: > >> Jay Balunas wrote: >>> ----- "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; wrote: >>>> I see 3 different issues here: >>>> >>>> 1) Code that does per-request logging at DEBUG level instead of TRACE. >>>> >>>> That's in violation of the logging standards and should be fixed. >>> +1 and that is what we are seeing to some extent. We don't regularly >>> need to known every time a class is loaded, or a persistence >>> connection is closed. >>>> 2) How much we log at DEBUG as part of service startup/shutdown. >>>> IMHO, this is not a huge problem. We should probably clean it up >>>> some, but >>>> >>>> the point of the logging is to make problem diagnosis easier, not to >>>> produce small logs for infrequent events. >>> Start up time in no little issue, but in general I agree. if there >>> is extra logging during start up thats fine. The real issue is the >>> reoccurring logs >>>> 3) The default loggging level for server.log. If #1 is broken, then >>>> having it be INFO makes sense, otherwise we punish users for our >>>> problems. If #1 is fixed, then different people can have different >>>> preferences, which I expect we're about to debate here. :-) My >>>> personal one is to leave it at DEBUG, unless we can make it >>>> configurable via system property substitution. Otherwise all >>>> testsuite runs will log >>>> at INFO unless we introduce testsuite hacks to replace the logging >>>> conf. >>> IMO - I would like to see it at info, and use an ant command to >>> adjust the debug level for hudson builds. Why punish our users so >>> that the continuous builds log enough. >> >> Log4j supports a basic system property substitution, so the server.log >> logging level can be controlled that way. I'll selfishly add that -- >> since it will help Bela in some stuff he's doing this week that in >> turn helps me. ;) >> >> https://jira.jboss.org/jira/browse/JBAS-6205 >> >> Note that JBAS-6205 doesn't include changing the default to INFO. I >> think INFO's fine, but it's not my call and in any case it's a >> separate JIRA that involves some extra work (to get the testsuites to >> log at DEBUG). >> >> >> -- >> Brian Stansberry >> Lead, AS Clustering >> JBoss, a division of Red Hat >> brian.stansberry(a)redhat.com >

Brian Stansberry wrote: > https://jira.jboss.org/jira/browse/JBAS-6205 is done. Nice! I've just tried it and it seem that setting jboss.server.log.threshold to INFO reduces boot times but a second or so, so not big deal. I guess the problem is really Seam deployments and it's extremely noisy logging.