Arjan's World: April 2005
You are now being redirected to the new housing of Arjan's World. Click here in case nothing happens

Thursday, April 28, 2005

Analyzing Webserver Logfiles With Analog

For those of you wishing to process logfiles with the wonderful log analyzer Analog, you might encounter a problem similar to mine. Analog.exe runs a config file by default, and starts looking up DNS entries by itself. However, it does this on a one-by-one basis, which is terribly slow.

For just this purpose, the utility QDns.exe was made. The reccomendation in the readme.txt was to run it in a batch file, just before running Analog.exe. However, the first time I ran it, after pointing analog.cfg to my logfiles and put everything in order, it just did not start to look up entries. This seemed strange, because I really followed all instructions. However, when running QDns.exe /G analog.cfg nothing interesting happend. QDns.exe /L logile.log /D dnscache is supposed to analyze one logfile while updating the DNS file. Also, no result. But, an interesting error occured "unable to listen to port 53 on main socket 'No Error'" which I Googled, leading me to this message on the Analog mail list:

Of course... I forgot to specify a DNS server with the option /Y x.x.x.x (IP-address DNS Server). Adding this to the commands made it look like QDns finally started processing my DNS entries. It took only one or two minutes, and 3500 entries were resolved!

Case closed

You are now being redirected to the new housing of Arjan's World. Click here in case nothing happens

Monday, April 11, 2005

Quick Tip: Debugging with Trace.axd utility in ASP.NET

Found this at Sonu Kapoor's WebLog. Trace.axd helps you in a debugging quest by logging the errors for you. It's actually quite simple, just put <trace enabled="true"/> somewhere in <configuration><system.web>, and you'll be up and running on 10 seonds. The nice thing is, you don't have to log errors yourself of worse... rembember what went wrong because there's no trail. No, this utility takes care of this need on it's own.

PS: Don't be a fool and just paste <trace enabled="true"/> at the start of your web.config. Chances are after you press [F5] you will spend ten minutes - i.s.o. seconds, like me :) - handling the following error: "Unable to start debugging on the webserver. Server side-error occured on sending debug HTTP request". You will find tips like repairing your VB.NET installation (don't do that, as it will take you an hour of your time), re-registering dll's and end up in places like this blog post on some other error, only to remember to check web.config and find out there's already a <trace enabled="false"/> somewhere below which you overlooked... d'oh

You are now being redirected to the new housing of Arjan's World. Click here in case nothing happens

Friday, April 01, 2005

Debugging XML Code

Lately I've been putting up a small XMLHTTPRequest - or should I say Ajax - application on our intranet. This gave me the opportunity to dive a bit into the features of behind-the-scenes JavaScript generated XML-based server roundtrips. While it looks very complicated on the outside, the code to make the magic happen is quite straightforward, and not even bleeding-edge: it's just an old trick with a new name. The difference is, that now you see libraries popping up here and there that make using this technique more straightforward.

I had some trouble in getting my XML document to work, but in the end using ISO-8859-1 as XML-encoding turned out to do the trick. The encoding I was using before, and to which I really didn't give a second thought, turned out not to be able to recognize the special non-ASCII chars like รถ that are in my returned string. Implementing a
<?xml version="1.0" encoding="ISO-8859-1" ?>
was seemed all that was neccessary. However, after getting the behind-the-scenes processing to work, I started a little testing. Suddenly, for one of the categories, I did not see a response in my HTML page. That was odd, since there definetely was output. I fired up the XML page supposed to harvest the result from the database, and it worked for all categories, except this one:
Whitespace is not allowed at this location.
Error processing resource file

Well, the decision was quickly made to look for odd characters in the response. The only really strange one I found was '&', and indeed the response was shown in my little browserwindow the minute the & was removed from the stream. But that of course was only the problem, not the solution to the problem, as this character definetely needs to be used in the output. Then again, I could Replace the character out and think I'm done. But in the back of my head there was this nagging voice telling me it's just waiting for another character to show up and stir things up. Firing up Google was the way to go: This Usenet posting has the definite answer. The & character is used as an escape character and therefore breaks the XML stream when it is used literally. Fixing this by replacing & with it's HTML equivalent &amp; was trivial. It's always good to see a little problem solved, even if it takes almost an hour to fix ...