JavaWorld
addict
Reged: 06/20/03
Posts: 482
|
|
Capture the benefits of asynchronous logging
|
Java Guru
Unregistered
|
|
I think asynchronous logging is a good idea. Hibernate for this example is a little over-kill.
Good article.
Jay
http://JavaRSS.com
|
Anonymous
Unregistered
|
|
I'm new to such implementation of asynchronous logging. The article gave me a clear understanding of what is involved including the components and example. Good informative article.
-Narayan
|
S V
Unregistered
|
|
An article witten excellently (simple and understandable way, Thanks for that).
However, how do you handle
a) Security with JMS if my client is an applet?
b) The messages should be logged in exact order as they are being created - so that i know the order in which it occurs in the system, if my persistence medium is a file and not db?
c) Why not instantiate JMSLogger and create object message in a new thread to further save the time?
|
Anonymous
Unregistered
|
|
Couldn't Log4J be used for this ? I mean, create a JMSAppender and reference it in log4j.configuration
|
Madhusudhan
Unregistered
|
|
Yes, you could. The idea of this article is to promote the benefits of Asynchronous Logging. I feel there is a learning curve involved with Log4J.
|
Madhusudhan
Unregistered
|
|
Thanks!
You may have to mend the policy file. I'm not Applet guy, sorry.
Chronological order is not maintained in this framework. You could do by having a time stamp on each message.
You don't want many objects lying around with live resources. It may give the chance to acces the db directly which is not desirable.
|
Madhusudhan
Unregistered
|
|
Thanks! I didn't want to go towards Entities for persistence neither for direct access. Realised that DAOs and Hibernate are good candidates for this purpose. Hibernate is cool from developers point and I implemented with it. Due to the simplistic scenarios, the usage might not be justified, but if the same framework extends, lot of stuff need to be persisted.
|
Anonymous
Unregistered
|
|
Thanks!
|
Anonymous
Unregistered
|
|
The concept of Async logging has been around for a while. I was hoping that this article would explain the pros and cons of such an architecture, and even point out where this type of architecture isn't the way to go.
So lets recap. What I get from the article is this:
1. Existing frameworks are good, but because many came out before JMS they don't support JMS.
2. JMS and Async logging is good because you eliminate overhead in your logging statements.
3. DB logging is good because it is centralized.
These are all half truths. Be sure to take a look at your actual needs before ripping up your logging method and introducing JMS + Hibernate + DB into your mix.
So let me play Devil's Advocate for a minute.
1. As another reader pointed out logging framework evolve with the times and many include native support for JMS these days. Log4J included.
2. What overhead do you really save with JMS? Assuming you're using log4j and logging to the console or a file, what's your overhead in writing to disk? Now what's your overhead when making a network call to a remote JMS server? The article says that your calls to disk will block. This is true, but unfortunately until your message is acked by the JMS queue you'll also block. Since in guaranteed mode the JMS service will persist to disk or DB to ensure the message won't be lost in the event of a crash. All you've done is moved the disk write from your app to the JMS server and bought some network overhead time to boot. Your logging calls end up taking longer then they did before. And if your JMS service goes down, whoa baby. You either then fail back over to what you were doing originally or block your app waiting many seconds for things to time out, every time, until your JMS service comes back up.
You can save some heartache and make the JMS service local, but you'll still have that disk hit no matter what, so all you really again is centralized logging. Lets make sure you really want it, after all you're going through a lot to get it.
3. The example given makes all logging centralized in a single DB. However the table structure for the log message isn't sufficient to be useful in real life. All you get is a dump of all log messages from all your clients in a single location. There's nothing in this simple example that would even tell you which client a message was from. You're now burried in messages with no ability to figure out where problems are actually occuring (the intended use for the logs in the first place). So obviously this example is a little too simple. But with added support for clientID and maybe a concept of a message thread, it has it's place.
So assuming that you've made some mods to figure out where your errors are coming from, how do you access these logs? They're not in a file or on the console anymore, they're in the DB. I hope you have some good DB tools, cuz you can't use a text editor anymore. Do tools exist, sure they do, and funny enough the best tools for viewing log messages in a DB ship with the logging frameworks!
So lets take a look back at Asynchronous DB logging. It sure does have it's place. But you get the most bang for your buck when you have a well thought out DB schema and good management tools for digging through it. You also have to be willing to accept some additional overhead in processing time, maintenance bloat (JMS, DB, code), and training time for your DB front end tool.
In my experience most projects get by just fine without this level of complexity. The overhead of most logging frameworks these days is minimal, and centralized persistant logging is overkill for the most part (and is something that the logging frameworks will support if you need it).
If your project would benifit from such a framework, be my guest, but please don't rush out and jump on the latest thing because a JavaWorld article told you to (speaking from experience here).
|
distressed
Unregistered
|
|
The author does not have a clue what he/she is talking about. In no way does it *save* time/improve performance( or make logging truly asynchronous ) : most of it has been pointed out in an earlier post.
May be the author will care to provide benchmark results as to how much the performance improved ( or is it something that the author pulled out of his/her hat ? )
"Learning curve for Log4J ... " : i would pretend that I never read this ....
|
anonymous
Unregistered
|
|
Hi you sound slightly bitter. Because you read an article is never reason enough to make a design decision.
That said, your point that JMS would introduce further delays, only applies if you choose to make your queue persistent. For most scenarios a non persisitent queue is adequate, meaning that async with JMS IS faster than sync to DB.
When using a non persistent queue, you could loose messages if your system suffers a catastrophic problem (e.g. runs out of memory), but I would suggest that if you are logging "error" mesages at such a rate to cause this, you have more fundamental problems.
I found the article light and pleasant, gently introducing some "nice" technologies.
I just wanted to set people new to JMS straight on the "overhead" question.
|
Anonymous
Unregistered
|
|
Well, not so much bitter, but cautious. I think there is a place for this type of architecture, but unfortunately I think it's the exception rather than the rule. I also think you have to know what you are doing and why you are doing it.
To me this article was presented in such a way as to imply that this type of logging architecture would almost certainly improve your logging outlook and performance. Many novice developers look at JavaWorld articles for tested, proven insight. If they read an article about how log4j will improve their life, complete with examples, they may be tempted to try and work that into what they're currently doing. So what's the worst that happens to you by replacing all your System.err.printlns with Log.error() lines? Probably not much. On the other hand quite a bit can go wrong with asynchronous logging. The example is oversimplified to the point of being unworkable in production, and the performance claims are false. Yes you don't have to run JMS in persistant mode, however this article justifies using JMS because of it's guaranteed delivery. Something you only get with persistant messages. Also depending on your network, even that non-persistant JMS call may take longer than a local disk write.
Really what this article is advocating is centralized logging. JMS is just what the author knows best and Hibernate is hot right now. That aside this is an implementation choice. Logging by nature is synchronous. If you want to try and speed things up by delegating certain tasks to other subsystems in an async manner fine, but there are many ways to do that. And you should only look into them if you notice performance problems with your existing logging method.
Now if you want to change that existing method from local file based to centralized DB logging, then this article gives you some ideas where you might start. However, the benefits of centralized logging come at added costs, not reduced costs. Something that I think the author misrepresented in this article.
|
Anonymous
Unregistered
|
|
What learning curve does log4j have? Its so simple to use. Most developers shouldn't really be concerned with advanced configurations of log4j anyway. If someone is having problems understanding how to use log4j, they probably shouldn't be writing Java code professionally.
|
nkdude
Unregistered
|
|
Good article.
We could also use Log4j on the client side, create a new appender class and use it to direct the log events(write) to a Message Queue that may be running on a remote server.
Nothing different, I guess a lot of open-source driven applications seem to use Log4j for logging purposes.
|
SAA
Unregistered
|
|
Having read the article and many of the comments, here are a few points (and questions) to throw into the mix:
[1] Logging to a database. Gives you an easily centralized log store, especially in a cluster, but what happens if the database or database connectivity is the cause of your problems? Where do those all-important (for diagnosis) log messages go?
[2] It seems to me one has to use persistent, durable messaging, otherwise you risk your log messages disappearing. IMHO logging is all about having the clues you need to determine what is going wrong. It should be simple and reliable to use, and performant. I think the some of the comments I have seen about JMS being overkill may be founded.
[3] Restrictions on EJBs in J2EE such as use of java.io do make logging and tracing in a way that is spec-compliant a pain. It seems like a lot of use are delegating (reasonably so, IHMO) to a logging solution such as JDK 1.4 logging or LOG4J and if the logger is configured to write to a disk file, so be it.
These notes aside, I enjoyed reading the article and "logging" an alternative solution for a problem we all face.
--PO'd in LaLa Land
(Peace Out in Wash DC)
|
MMR
Unregistered
|
|
Probably a late reply. But never late than ever.
Man, what happened to the pragmatic way of coding, where's the orthogonality of the programming gone.
Stop building stuff which is already there untill and unless its way better than existing ones. Log4J is good.
Also, concerns like logging should be weaved into code rather than thinking about making them asynchronous. Whats the point we still end up putting the code in every method or so... There comes AOP.
Well this is just a view and could be criticised. Well, this is how I (learning to be pragmatic) would atleast prefer it.
|
Anonymous
Unregistered
|
|
This posting is coming very late.. I had implemented this design long before this article was posted. It was for a almost real time mission critical application.
Read who commented that Author does not know naything are it is too much for a looging either has know knowledge of distributed application or haven't worked on a large scale application. Tie the logging the way it is vs. async log and you would see the performance benefits. Again if you are a small coder/programer never try this because you will defintely do not understand the benefits....
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
