rolling daily logger
i'm using log4j2 for some of the filters (level and dynamic). I want my logs to roll based on size (this makes it easy to open in vim), but also by date (this helps organize them and I only need 1 week of logs). here's my current configuraiton. i'm un sure how to specify a rollover strategy that keeps 7 days worth of files with a size based triggering policy. any help would be most appreciated. thanks, -mark-
Re: logging level per thread
This is the filter i need. Is there a performance hit to using the filters?
On Feb 17, 2015 5:24 PM, "Ralph Goers" wrote:
> I apologize. I pointed you at the wrong filter. The one you want is the
> DynamicThresholdFilter -
> http://logging.apache.org/log4j/2.x/manual/filters.html#DynamicThresholdFilter
> <
> http://logging.apache.org/log4j/2.x/manual/filters.html#DynamicThresholdFilter
> >.
>
> Ralph
>
> > On Feb 17, 2015, at 12:04 PM, Mark Lybarger wrote:
> >
> > thanks for the reply. i'm looking into the ThreadContextMapFilter, and
> it
> > seems very interesting. I don't quite see how i apply a logging level to
> > the particular filter match?
> >
> >
> >
> >
> >
> >
> > from what i read, this looks into the thread context map, and if the
> > current thread had issued the command:
> > ThreadContext.put("debugUser","DEBUG"), then the log messages would pass
> > the filter. That's fantastic, however, I need to specify a level as
> well.
> > It looks like I want/need a combination of the ThreadContextMapFilter and
> > the ThresholdFilter. A ThreadContextMapThresholdFilter perhaps?
> >
> >
> >
> > On Fri, Feb 13, 2015 at 11:39 AM, Ralph Goers <
> ralph.go...@dslextreme.com>
> > wrote:
> >
> >> See http://logging.apache.org/log4j/2.x/manual/eventlogging.html <
> >> http://logging.apache.org/log4j/2.x/manual/eventlogging.html>. You
> would
> >> then use
> >>
> http://logging.apache.org/log4j/2.x/manual/filters.html#ThreadContextMapFilter
> >> <
> >>
> http://logging.apache.org/log4j/2.x/manual/filters.html#ThreadContextMapFilter
> >
> >> to set the desired log level for the user.
> >>
> >> Ralph
> >>
> >>> On Feb 13, 2015, at 8:33 AM, Mark Lybarger
> wrote:
> >>>
> >>> I have a j2ee application that i'd like to change the logging level on
> a
> >>> per thread or a per context basis. For intstance, I'd like to enable
> >> debug
> >>> level for user FOO. Has anyone encountered this ?
> >>>
> >>> Thanks,
> >>> -mark-
> >>
> >>
>
>
Re: logging level per thread
thanks for the reply. i'm looking into the ThreadContextMapFilter, and it
seems very interesting. I don't quite see how i apply a logging level to
the particular filter match?
from what i read, this looks into the thread context map, and if the
current thread had issued the command:
ThreadContext.put("debugUser","DEBUG"), then the log messages would pass
the filter. That's fantastic, however, I need to specify a level as well.
It looks like I want/need a combination of the ThreadContextMapFilter and
the ThresholdFilter. A ThreadContextMapThresholdFilter perhaps?
On Fri, Feb 13, 2015 at 11:39 AM, Ralph Goers
wrote:
> See http://logging.apache.org/log4j/2.x/manual/eventlogging.html <
> http://logging.apache.org/log4j/2.x/manual/eventlogging.html>. You would
> then use
> http://logging.apache.org/log4j/2.x/manual/filters.html#ThreadContextMapFilter
> <
> http://logging.apache.org/log4j/2.x/manual/filters.html#ThreadContextMapFilter>
> to set the desired log level for the user.
>
> Ralph
>
> > On Feb 13, 2015, at 8:33 AM, Mark Lybarger wrote:
> >
> > I have a j2ee application that i'd like to change the logging level on a
> > per thread or a per context basis. For intstance, I'd like to enable
> debug
> > level for user FOO. Has anyone encountered this ?
> >
> > Thanks,
> > -mark-
>
>
logging level per thread
I have a j2ee application that i'd like to change the logging level on a per thread or a per context basis. For intstance, I'd like to enable debug level for user FOO. Has anyone encountered this ? Thanks, -mark-
Re: Date corruption in logging
we experience the same thing on an ibm p520 machine (and a p570). seems reverting to a 32bit jvm helps, but that's not really a good solution. my understanding is that log4j is just using java.util.Date() for logging, so it would seem to be an issue with the JDK, but i can't say for certain. one annoying thing is that the daily rolling file appender for the jboss server.log never ends up rolling, and the file just grows to an unmanageable size after time. On 5/26/05, Simon Kelly <[EMAIL PROTECTED]> wrote: > Hi All, > > I am currently using log4j on an IBM AS400 pcc64 ( 64 bit architecture ) > within JBoss. The issue I am having is that the logging date displayed > is matching the system time for about 30 seconds then it switches to "31 > Dec 1969 16:00:00,000" and stays like this. > > Has anyone seen this before, and if so does anyone know a solution? > > Kind regards > > Simon > > Simon D Kelly > Support Analyst > > Talgentra Ltd. > 720 Waterside Drive, > Aztec West, > Bristol. > BS32 4UD. > > Tel: +44 (0) 1454 892000 (Main) > +44 (0) 1454 892032 (Direct) > Fax: +44 (0) 1454 892030 > Email : [EMAIL PROTECTED] > > Talgentra develops and markets Tallyman and Gentrack, industry-leading > solutions for customer billing and revenue collection. > > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, by > definition, not smart enough to debug it." > -Brian W. Kernighan > "no level of fitness - or, for that matter, drunkenness - justifies > wearing a tank top at home" > -Omelianuk & Allen > > > > ## > > This email from Talgentra is intended only for the personal use of the > recipient(s) named above. The email and any files transmitted with it are > confidential to the intended recipient(s) and may be legally privileged or > contain proprietary and private information. If you are not an intended > recipient, you may not review, copy or distribute this message. If received > in error, please notify the sender and delete the message from your system. > > Any views or opinions expressed in this email and any files transmitted with > it are those of the author only and may not necessarily reflect the views of > Talgentra and it does not create any legally binding rights or obligations > whatsoever. Unless otherwise pre-agreed by exchange of hard copy documents > signed by duly authorised representatives, contracts may not be concluded on > behalf of Talgentra by email. > > Please note that neither Talgentra nor the sender accepts any responsibility > for any viruses and it is your responsibility to scan the email and the > attachments (if any). All email received and sent by Talgentra may be > monitored to protect the business interests of Talgentra. > > > > ## > > > - > 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]
ppc64 - jboss - log4j - 1969
i'm using jboss on a P520 machine running suse linux with IBM's 64 bit SDK. after about 30 seconds of logging, all the log entries show a date of 1969-12-31 19:00:00,000. has anyone heard of such a thing? i believe we had also noticed this on a P570 machine, but noticed that switching to IBM's 32 bit SDK resolved the issue.I imagine switching the SDK on the 520 would resolve it as well.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jms appender
no, i haven't looked into the socket stuff. what advantages does this provide over jms/jdbc? On 8/8/05, Schuweiler, Joel J. <[EMAIL PROTECTED]> wrote: > > Have you looked at the socket stuff? That's what I currently use. > > -Original Message- > From: Mark Lybarger [mailto:[EMAIL PROTECTED] > Sent: Monday, August 08, 2005 10:37 AM > To: Log4J Users List > Subject: jms appender > > we're interested in creating a centraliszed logging solution. we'd also > like > to have logging have as little impact to the application (logging should > be > fast). our thought is to combine a jms logger on the "client" side, and > have > a jms listerner which logs the message using jdbc logger. > > are there any gotchas to watch out for something like this? will the > logging > maintain its consistancy over a local filesystem based logging (meaning > that > the logs are in the correct order)? will a jms logger on the client be > heavier or lighter than a filesystem based logger? would it be a good idea > to use a MDB to process the incoming logs, or just a jms listener? > > thanks! > ~mark > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
jms appender
we're interested in creating a centraliszed logging solution. we'd also like to have logging have as little impact to the application (logging should be fast). our thought is to combine a jms logger on the "client" side, and have a jms listerner which logs the message using jdbc logger. are there any gotchas to watch out for something like this? will the logging maintain its consistancy over a local filesystem based logging (meaning that the logs are in the correct order)? will a jms logger on the client be heavier or lighter than a filesystem based logger? would it be a good idea to use a MDB to process the incoming logs, or just a jms listener? thanks! ~mark
Re: logging http session identifying information
I'm currently tackling this challenge.
In using the CookieMDCFilter, the JSESSIONID that gets logged is very hard
to decipher. meaning, I'm not always getting a JSESSIONID logged, and
sometimes, i seem to have stale JSESSIONID logged. I'm not quite up to par
on the JSESSIONID lifecycle, but will get it soon.
For instance, i get a logging message:
11:01:43,147 ERROR 86985045A03DC9301A6B05C9B0E5AA7C NextLogger : NextLogger
- logging
i close the browser window (IE) and reopen a new window, and execute the
servlet, i see:
11:02:17,178 ERROR 86985045A03DC9301A6B05C9B0E5AA7C NextLogger : NextLogger
- logging
the session id I see has not changed, though i would think the browser uses
a different session id per session... Using mozilla, I even close out all
instances of mozilla, start a new mozilla instance, when i hit the servlet i
still see:
11:06:19,987 ERROR 86985045A03DC9301A6B05C9B0E5AA7C NextLogger : NextLogger
- logging
very strange.. this is the id from IE. maybe this has something to do with
the fact that it isn't cleaning out the MDC (at all) and doesn't clear its
own map until the destroy method. Next, I modified the CookieMDCLogger to do
a little cleanup like so:
// pass control to the next filter
try {
chain.doFilter(request, response);
} finally {
// clean up the MDC.
if (cookieMap != null)
{
for (Iterator iter = cookieMap.entrySet().iterator();iter.hasNext();)
{
Map.Entry element = (Map.Entry) iter.next();
String key = (String) element.getKey();
MDC.remove( key );
if (LOG.isDebugEnabled()) { LOG.debug( "remove from MDC with name " + key
);}
}
}
}
Please let me know if you see any issues with the clean up, but it seems to
tidy things up a bit. There's still problems with this in that I don't
always get a JSESSIONID logged.
Some general questions. Should the server side session (HttpSession.getId())
match the cookie session id? Which would be more reliable, the server side,
or the client side, or both? Any comments on this would be most appreciated.
I'll have to continue testing this out...
On 5/18/05, Mark Womack <[EMAIL PROTECTED]> wrote:
>
> There is an example of putting stored cookie information into the MDC. You
> could easily modify it to use information from the session instead.
>
>
> http://cvs.apache.org/viewcvs.cgi/logging-log4j-sandbox/src/java/org/apache/
> log4j/servlet/CookieMDCFilter.java?view=markup
>
> It doesn't do anything to remove the MDC information after the next filter
> in the filter chain completes, so it might be a good idea to do that. That
> way you don't have wayward MDC info sticking around in the thread local
> getting reported later in some unrelated request context. I would do that
> in a final block if possible to guarantee it gets removed.
>
> hth,
> -Mark
>
> > -Original Message-
> > From: Mark Lybarger [mailto: [EMAIL PROTECTED]
> > Sent: Wednesday, May 18, 2005 6:19 PM
> > To: Log4J Users List
> > Subject: Re: logging http session identifying information
> >
> > i want to log the session id, and any other info from the session that i
>
> > choose so that i can sort my logs per session.
> >
> > i'll check out the sandbox.
> >
> > On 5/18/05, Mark Womack <[EMAIL PROTECTED]> wrote:
> > >
> > > If I understand correctly, you want to set session/user specific
> > > information
> > > per request? Since the MDC is stored in ThreadLocal, I think you will
> > need
> > > to use a servlet filter to set and unset the MDC for each request. And
>
> > > yes,
> > > how threads are assigned to handle requests, etc is very container
> > > specific.
> > > So, setting and unsetting the MDC with each request is a good thing. I
> > > cannot remember offhand if there is already an MDC related servlet
> > filter
> > > in
> > > the log4j-sandbox. You might want to take a quick look and use it as
> an
> > > example.
> > >
> > > -Mark
> > >
> > > - Original Message -
> > > From: "Mark Lybarger" <[EMAIL PROTECTED]>
> > > To:
> > > Sent: Wednesday, May 18, 2005 5:47 AM
> > > Subject: logging http session identifying information
> > >
> > >
> > > I'm looking for a method to log http session information in our log4j
> > > logging. we want to be able to trace logging to a particular session.
> > For
> > > instance, when a user reports having trouble, we would like to see
> what
> > > they
> > > did on the web site.
> > >
> > > We have a thread id being logged with each log, but there's no way to
>
Re: logging http session identifying information
i want to log the session id, and any other info from the session that i choose so that i can sort my logs per session. i'll check out the sandbox. On 5/18/05, Mark Womack <[EMAIL PROTECTED]> wrote: > > If I understand correctly, you want to set session/user specific > information > per request? Since the MDC is stored in ThreadLocal, I think you will need > to use a servlet filter to set and unset the MDC for each request. And > yes, > how threads are assigned to handle requests, etc is very container > specific. > So, setting and unsetting the MDC with each request is a good thing. I > cannot remember offhand if there is already an MDC related servlet filter > in > the log4j-sandbox. You might want to take a quick look and use it as an > example. > > -Mark > > - Original Message - > From: "Mark Lybarger" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, May 18, 2005 5:47 AM > Subject: logging http session identifying information > > > I'm looking for a method to log http session information in our log4j > logging. we want to be able to trace logging to a particular session. For > instance, when a user reports having trouble, we would like to see what > they > did on the web site. > > We have a thread id being logged with each log, but there's no way to tie > the threads together into a session of activity. I've also read that it's > very container specific as to weather or not the same thread is used for > an > entire servlet execution. > > I came across this note on using MDC for logging session information. > > > http://ulc-community.canoo.com/snipsnap/space/Contributions/Integration+Snippets/Log4J+MDC+Integration > > It seems rather easy to extend to support any http session attributes that > i > might want to log (user id, etc). > > Are there other methods to easily log a session id or other information in > our log4j logs? Are there drawbacks to the solution of using the MDC > integration? > > One thing that wasn't very clear with the MDC integration was where to put > the setup code in an servlet container environment. We're using a startup > servlet in all our web apps. Would we need this in each web app's startup > servlet? > > Thanks! > ~mark > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
logging http session identifying information
I'm looking for a method to log http session information in our log4j logging. we want to be able to trace logging to a particular session. For instance, when a user reports having trouble, we would like to see what they did on the web site. We have a thread id being logged with each log, but there's no way to tie the threads together into a session of activity. I've also read that it's very container specific as to weather or not the same thread is used for an entire servlet execution. I came across this note on using MDC for logging session information. http://ulc-community.canoo.com/snipsnap/space/Contributions/Integration+Snippets/Log4J+MDC+Integration It seems rather easy to extend to support any http session attributes that i might want to log (user id, etc). Are there other methods to easily log a session id or other information in our log4j logs? Are there drawbacks to the solution of using the MDC integration? One thing that wasn't very clear with the MDC integration was where to put the setup code in an servlet container environment. We're using a startup servlet in all our web apps. Would we need this in each web app's startup servlet? Thanks! ~mark
