Tag Info

New answers tagged

0

This is what I'm doing in my latest project -- for the first time, so haven't totally tested in production. #9384752 --- Jan 4, 2014 4:58:16 >>> FAILED :: [Chart] render <<< chart.class.php @ 43 And it parses like: #9384752 Unique identifier in order to find/mark each separated line easier. --- A very visible and eye-friendly ...


4

Usually it is said that logging is for operators of your software. However, this is not entirely true, since DEBUG logs are usually turned on while developing, for the benefit of the developers. I tend to regard the different levels as interesting to different roles: DEBUG: developers only INFO: operators / developers WARNING: operators ERROR/CRITICAL: ...


7

The problem with logs is developers use logs to help them debug software rather than those using the software. They add messages that make only sense to them and remove the messages when they are not needed. This is poor practice. Log entries like "Wtfwtf" only help a developer that can search for that string in the code. A better solution is to log ...


0

I ended up implementing the solution discussed in my question. •When event is received, get a list of all Monitor IDs (GUID), order the list, and the first Monitor in the list gets to send the notification.


0

It isn't really clear what your other monitors are for if they aren't going to be sending notifications. Is there some reason why you can't add or have a single monitor instance that is responsible for passing on the notifications?


0

A write-lock can be acquired by the Monitor that has received the event over the log, do logging and set the logged flag to 'true' in the global logging context which all Monitors can look up and update has a reference of. Subsequent monitors may skip the logging step after reading the logged flag status. Lookup of in memory context flag is expected less ...


5

You have made your design overly complex by creating specific logger signatures for the various latency sensitive parts. A better design would have been to use the Logger interface from logback for all parts of the application. If performance measurements have shown that the logging causes a bottleneck for some low-latency parts, then you can offload the ...


0

One thing I would suggest would be that you have a means of having multiple logging contexts associated with any particular log file, and arrange so that anything written to any logging context will get logged unless code explicitly asks the logging context to discard its contents. Such a design will allow one to capture rather detailed logs during an ...


2

You can use a nested diagnostic context (NDC) to push the information in before you enter the ORM module (or at whatever level is appropriate). This idea is referred to in the log4net documentation as Context Stacks but most loggers have a similar concept.


0

Make the logger globally available, so you don't have to pass it around. If you have more than one logger (maybe one per session), you need to make it "globally within the session context". For example, you could provide a global "logger repository" which holds a reference to each active logger and lets you access them by the session id, or some other ...


1

Fundamentally you should do the same thing you did for sucess -- let the user know about it. Note that this is specific to the front end, because the front end session continues. The back end should return sucess, even if it doesn't have a valid session to close out. Only if it truly is, for some strange reason, going to maintain the session, should it ...


1

When an error occurs in a web application, this is what happens: Error Try/Catch (or any other comparison mechanism) window.error Browser error Your application should consider 2 kind of errors (minimum): FATAL Error NON-FATAL Error A fatal error is an error that does not allow the execution of the application, and does not consider the possibility ...


1

This is related to the age-old question, "How do I handle the error if I try to delete a resource that isn't found?" Practically speaking, the job is done. Usually, I'll just move on, at most logging a WARN if it matters. The risk here comes from a login session being a security artifact. So if the logout failed, you may have a lingering session that would ...



Top 50 recent answers are included