Thirteen ­ or as I prefer it ­ 26 over 2. Yes, this is article number (26 over 2) in the series, and the more superstitious of you will know this isn't the luckiest of numbers. So with fingers crossed, let's delve into this month's rants and raves and see what pops out.

This article has been written all over the world. I have composed columns on the move in Sydney, San Francisco, London and even on a napkin in a Tokyo hotel. This month the column comes to you from both sides of the Atlantic. It was started in New York and finished back here in Scotland. I was up in Toronto giving a talk on Java Servlets at this year's WWW8 conference. This is where all the Internet boffins get together and generally discuss the emerging technologies that we are likely to see over the next 12 months.

As you can probably guess, XML featured quite heavily. I'm not too sure about this new technology at the moment; I'm sitting on the fence before making a move. If you're unaware of XML, it's basically a means of transferring data in a format that anyone can make use of, since the information on how the data is organized is contained within the same file. However, it suffers from a lack of global standards on how data is going to be moved about. Sure, the actual XML standard is rubber-stamped, but two Web sites offering catalog information would have to agree on the same data format to make it of real use. On a one-on-one basis, XML seems to be finding applications within large corporate environments where they only need to transfer data between locally controlled boxes. How XML will fare in the open network is anyone's guess.

At the moment I'm camping out in SYS-CON's Web Services Department for the week until I go home. This is much appreciated and very welcome as it allows me to be a fly on the wall in somebody else's office. It's quite strange sitting here watching Americans at work. You're definitely a funny breed, aren't you? I have never met a friendlier race of people in my life. It's quite spooky...and only goes to confirm what we Europeans believe, which is that everyone exhibits at least some of the behavior seen on "The Waltons." (As I pen this, it's just dawned on me that we even have a Mary Ann floating around. My God, this is Walton Mountain!)

JavaOne is only a matter of a couple of weeks away, and by the time you read this it will all be over. I'm sitting here arranging sessions for the SYS-CON radio broadcast, which we'll do from the floor. So, to those of you that have come up and said Hello, and really told me what you think of this column, I thank you ­ I think ­ in advance. I'll have a full update in the next column.

Thread.stop();
A couple of days before stepping on the plane to come here, I was wrestling with an absolutely evil problem. Fortunately, I got it fixed in a matter of hours before leaving; otherwise it would have bugged me the whole trip. Let me explain my wee problem and hopefully preempt your having a similar experience.

Speaking to you Java developers out there, we've all heard about the wonders of garbage collection and how we don't need to worry about such things as freeing objects and memory anymore. In fact, it's one of Java's main selling points. A wee word of caution though ­ don't believe everything you read.

One of our clients, Focus Digital, has just launched a new, exciting e-business­based Web site here in the UK, http://uk.shopsmart.com/. It seeks out the cheapest price for a particular item from a host of merchants. We developed the technology, using Java Servlets that essentially perform a number of concurrent searches, collating the results in a real-time environment to minimize the amount of waiting experienced from the user. The final system works like a dream and is very efficient under heavy load.

It wasn't always efficient, however. Let me explain why.

Since we had a number of concurrent problems to satisfy, we developed a whole system based on the java.lang.Thread class that would spawn off the necessary amount of threads and coordinate the results between them.

During development we had no problems. In fact, the system was running extremely fast and we were very pleased with our initial design. However, a queer problem raised its head after a period of time. Around the three thousandth database query the system would simply hang and not respond to any more client requests. Since it was consistent at the three thousand mark, we automatically looked toward the database as being the problem. It was a place to start, and at that moment it was all we had.

A number of belts and braces went round our database manager class. But no difference. We even took the bold step of rewriting the underlying class to incorporate a number of enhancements. We have a very stable database pool manager that has evolved over a number of years and forms the heart of most of our projects. So I was reluctant to accept that something was wrong with this piece of software. It was performing admirably well in all other clients' products so why should it start going pear-shape now?

Redeveloping it did speed things up a little, and with the new version all tested we inserted it into the main problem. No difference. Bugger! Oh well, at least we got a new improved version of the database manager, so we can't look at it as a complete waste of time.

Scratching our heads for a while didn't yield anything useful. Nothing left but to develop a watchdog thread that would periodically print out the status of various core parts of the system. We've used such devices in the past to great success, but in this instance nothing new was highlighted. One thing we did notice, however, was that even our watchdog thread stopped printing out information after the three thousandth query. The plot thickens.

Eliminating the database from the problem, Ceri started to look at the process usage under Linux to see if anything obvious was going on. Ceri noticed that memory was being used up at a tremendous rate, but was never released. This was not a major concern to me, knowing that most JVM implementations rarely give memory back to the system when allocated. The memory internally may not be all used, but as far as the operating system is concerned the JVM has it all. Time to move on.

We did some more testing, but this time, instead of hitting the server with just one process, we flooded it with over 20 requests per second to see when it would break. It still broke at the three thousand mark, but it got there a hell of a lot quicker. Oh well, if anything, it would speed up the debugging procedure.

Still thinking about the information Ceri had thrown up, I decided to modify our watchdog timer to print out the virtual memory usage from the point of view of the JVM. In addition to this ­ on a whim, it has to be said ­ I decided to print out the number of active threads in the JVM. We ran the tests again, not expecting a great deal. But an interesting picture started to emerge.

The memory was indeed being used up, as was the number of threads. However, the memory did go down, but the number of active threads? Never. They never once moved down the way. Aha! Caught the bugger! I mustn't be catching an exception in a thread and it's obviously crashing. How remiss of me! Not like me to miss such things. But after inspection of all our thread-based classes, all the proper try­catches were being dealt with. So what was going on? I looked carefully at each of my thread classes, but nothing untoward was shining through. I then took the drastic step of placing println(...) at the end of each run() method just to confirm that the threads were running to their logical end and weren't caught in an infinite loop somewhere.

Ran the tests again, and all threads were completing, but the active thread count still continued to grow. I looked back at the documentation on threads and, as I expected, the garbage collector cleared up threads after they finished and went out of scope. No need to call the stop() method, and since Java 2.0 has deprecated this method I looked elsewhere.

Calling the garbage collector manually didn't help one single bit. What the hell, I thought, let's call the stop() method after each one. With a little reworking of some logic, all created threads were having their stop() method called. Ran the tests again and lo and behold, the thread count went up and down. Hooray. Problem solved.

Couldn't believe it. We thought, "Maybe it's the JVM on Linux," but after setting up with the official Sun JVM under NT, we found the exact same behavior. Now we can conclude one of two things: either the JVMs are not handling threads properly ­ they seem to escape the attention of the garbage collector ­ or the documentation is incorrect, leading developers to believe threads are just classes. I'm not sure which side of the fence I'm going to come down on, but I'd be interested if any of you have found the same thing or seen similar behavior.

Mailing List
Which leads us nicely into my monthly plug of our mailing list. It's good to see the list growing, and some of the topics that are debated are very interesting. I'd be very keen on hearing your views on this threading issue, so please join and let's discuss it. Send an e-mail to listserv@listserv.n-ary.com with subscribe straight_talking-l in the body of the e-mail. From there you'll get instructions on how to participate on the list.

Salute of the Month
Last month I started a new feature that takes a person and gives them the "Salute of the Month" for work above and beyond the call of duty. This month I have to give a group salute to the whole team at the SYS-CON offices for making my time there extremely enjoyable. I'd like to single out the main man, Fuat Kircaali, for taking care of me the whole week and for a "Fuyacht" boat trip I'll never forget. When I look at postcards of New York, I still can't believe I had the honor. This more than makes up for leaving a kilted Scotsman stranded late at night in Newark Airport, and having a brush with the law later that night in Pearl River. 'Nuff said!

Book Review
This month I'm in the middle of the Oracle book that profiles the ups and downs of Oracle and Mr. Ellison. Not being a great fan of the way Oracle works, I'll leave the review till I finish the book. But I have to admit to not being able to put it down. What a read! I've read many of these types of books, and like many of you entrepreneurs I get a lot of inspiration from seeing how the big companies became big companies. But the one thing I've never read is how they broke into their first million. We hear the stories only after they have multimillion sales, and as interesting as this is, I'm sure there are equally as many tales and advice to be told at the start of the journey as opposed to halfway through. So, to any big CEOs out there that read this column, we want to know the details of the basic steps.

Maybe Ellison, Grove, Gates and Kaplin can do a George Lucas and release a prequel to their books so we can see how the story started. The only book I've read that really goes through the early steps is from Richard Branson regarding the Virgin empire, but, sadly, this isn't computing-related. So come on, you big CEOs: tell it to us from the start.

I'd better finish up as I'm running out of paper, and now that I'm back in Scotland it has a wee bit longer distance to travel to get back to New York. So in the time-honored tradition, as I look back at Walton Mountain, I shall bid you farewell....Goodnight, Mary Ann....Goodnight, Jim-Babb....Goodnight, M'lou!