Re: [logback-user] Limiting events to one thread in email
Thanks Ceki, I had a look at this and I'm not too sure if it is the best approach or actually feasible... Allow me to give a few more details. 1) We're using the AsyncAppender as per http://jira.qos.ch/browse/LBCORE-92 (by the way, it would be great to include this in an official release!) 2) The processing can happen from a JMS Message or an RMI call, or a GUI event... there is no real single entry point where I would be able to put a value in MDC... Would a Cyclic Buffer per thread name in each event be a more appropriate approach? What do you think? I'm not sure we could use Thread.currentThread().getName() to distinguish each caller as the AsyncAppender would be using their own thread and not the one that actually originated the event... In which case, the interface get() on the CyclicBuffer is not suitable since I would have no way to give it the name of the thread that called the Error... Your opinion/suggestion/solution are appreciated, Thanks Benoit ----- Have a look at http://logback.qos.ch/recipes/emailPerTransaction.html HTH, -- Ceki On 17.02.2011 15:49, Benoit Xhenseval wrote:
Hi *,
We're running an application on large multi-threaded servers. When an exception/error occurs, we send an email with the last 50 DEBUG entries or so.
How could we ensure that these 50 entries are limited to the Thread that is actually sending the error email?
If there is no such implementation, what would be the recommended way?
We can probably contribute it back to the community
Many thanks
Benoit
-- IMPORTANT NOTICE This communication contains information that is considered confidential and may also be privileged . It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender and delete the original.
Hello Benoit, If AsyncAppender is programmaed correctly it should preserve the original thread name. This is usually accomplished by calling the prepareForDeferredProcessing method of ILoggingEvent. Once you have the thread name all you need to do is to write the disciminator. Here is an example implementaiton for ThreadBasedDiscriminator: public class ThreadBasedDiscriminator extends ContextAwareBase implements Discriminator<ILoggingEvent> { String key = "threadName"; private boolean started = false; // this is where the "action" is public String getDiscriminatingValue(ILoggingEvent event) { return event.getThreadName(); } public String getKey() { return key; } public void setKey(String k) { key = k; } public boolean isStarted() { return started; } public void start() { started = true; } public void stop() { started = false; } } HTH, -- Ceki On 28.02.2011 23:35, Benoit Xhenseval wrote:
Thanks Ceki,
I had a look at this and I'm not too sure if it is the best approach or actually feasible... Allow me to give a few more details.
1) We're using the AsyncAppender as per http://jira.qos.ch/browse/LBCORE-92
(by the way, it would be great to include this in an official release!)
2) The processing can happen from a JMS Message or an RMI call, or a GUI event... there is no real single entry point where I would be able to put a value in MDC...
Would a Cyclic Buffer per thread name in each event be a more appropriate approach? What do you think? I'm not sure we could use Thread.currentThread().getName() to distinguish each caller as the AsyncAppender would be using their own thread and not the one that actually originated the event... In which case, the interface get() on the CyclicBuffer is not suitable since I would have no way to give it the name of the thread that called the Error...
Your opinion/suggestion/solution are appreciated,
Thanks
Benoit
-----
Have a look at http://logback.qos.ch/recipes/emailPerTransaction.html HTH, -- Ceki On 17.02.2011 15:49, Benoit Xhenseval wrote:
/ Hi *, />/ />/ We're running an application on large multi-threaded servers. When an />/ exception/error occurs, we send an email with the last 50 DEBUG entries />/ or so. />/ />/ How could we ensure that these 50 entries are limited to the Thread that />/ is actually sending the error email? />/ />/ If there is no such implementation, what would be the recommended way? />/ />/ We can probably contribute it back to the community />/ />/ Many thanks />/ />/ Benoit />
-- IMPORTANT NOTICE This communication contains information that is considered confidential and may also be privileged . It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender and delete the original.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Definitely pushing us in the right direction, thanks. Question remain however is that, unless I am mistaken, the cyclic buffer would only contain X entries in total and not for each thread. So if a thread was very verbose and the other one, the one causing the error and email, it would not see any entries for that thread in the buffer. How would you keep a cyclic buffer per thread? The idea is to get X events for the thread causing the error Thanks B ----- Important Notice This communication contains information that is considered confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender and delete the original On 1 Mar 2011, at 07:13, Ceki Gulcu <ceki@qos.ch> wrote:
Hello Benoit,
If AsyncAppender is programmaed correctly it should preserve the original thread name. This is usually accomplished by calling the prepareForDeferredProcessing method of ILoggingEvent.
Once you have the thread name all you need to do is to write the disciminator. Here is an example implementaiton for ThreadBasedDiscriminator:
public class ThreadBasedDiscriminator extends ContextAwareBase implements Discriminator<ILoggingEvent> {
String key = "threadName"; private boolean started = false;
// this is where the "action" is public String getDiscriminatingValue(ILoggingEvent event) { return event.getThreadName(); }
public String getKey() { return key; }
public void setKey(String k) { key = k; }
public boolean isStarted() { return started; } public void start() { started = true; } public void stop() { started = false; } }
HTH, -- Ceki
On 28.02.2011 23:35, Benoit Xhenseval wrote:
Thanks Ceki,
I had a look at this and I'm not too sure if it is the best approach or actually feasible... Allow me to give a few more details.
1) We're using the AsyncAppender as per http://jira.qos.ch/browse/LBCORE-92
(by the way, it would be great to include this in an official release!)
2) The processing can happen from a JMS Message or an RMI call, or a GUI event... there is no real single entry point where I would be able to put a value in MDC...
Would a Cyclic Buffer per thread name in each event be a more appropriate approach? What do you think? I'm not sure we could use Thread.currentThread().getName() to distinguish each caller as the AsyncAppender would be using their own thread and not the one that actually originated the event... In which case, the interface get() on the CyclicBuffer is not suitable since I would have no way to give it the name of the thread that called the Error...
Your opinion/suggestion/solution are appreciated,
Thanks
Benoit
-----
Have a look at http://logback.qos.ch/recipes/emailPerTransaction.html HTH, -- Ceki On 17.02.2011 15:49, Benoit Xhenseval wrote:
/ Hi *, />/ />/ We're running an application on large multi-threaded servers. When an />/ exception/error occurs, we send an email with the last 50 DEBUG entries />/ or so. />/ />/ How could we ensure that these 50 entries are limited to the Thread that />/ is actually sending the error email? />/ />/ If there is no such implementation, what would be the recommended way? />/ />/ We can probably contribute it back to the community />/ />/ Many thanks />/ />/ Benoit />
-- IMPORTANT NOTICE This communication contains information that is considered confidential and may also be privileged . It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender and delete the original.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
SMTPAppender maintains a distinct cyclic buffer for each distinct value returned by the discriminator. Buffers unused for 30 minutes are automatically discarded. So contrary to your assumption, there would be one buffer per thread. HTH, -- Ceki On 01.03.2011 10:10, Benoit Xhenseval wrote:
Definitely pushing us in the right direction, thanks.
Question remain however is that, unless I am mistaken, the cyclic buffer would only contain X entries in total and not for each thread. So if a thread was very verbose and the other one, the one causing the error and email, it would not see any entries for that thread in the buffer.
How would you keep a cyclic buffer per thread?
The idea is to get X events for the thread causing the error
Thanks
B
participants (2)
-
Benoit Xhenseval -
Ceki Gulcu