Not following the instructions cost me 2 hours of heartache

One of the things I like about blogging is that it lets me record the occasional good idea I have. Then again, when I forget those good ideas and make mistakes anyway, I feel like an idiot. I hate making the same mistake multiple times, but I suppose I’m less likely to make it subsequent times when I remember I actually wrote about it before.

Such is the case with my series on Troubleshooting Techniques as I realized recently that I forgot to follow my own Step 1 in that process: I didn’t follow the instructions.

In preparation for a 3 day face to face meeting in Palo Alto, I was frantically putting together a prototype that I hoped would help demonstrate an architectural point I knew I’d be making. It’s been far too long since I’ve written any decent amount of code and was reusing some that I’d written about 18 months ago.

The old code was pretty simple. When passed a URL, it would make an HTTP connection and return the text that came back from that URL. In it’s previous incarnation, I used this code to pull HTML from another website into one I was writing, but this time I was going to use it to connect to a web service and do something programmatically with the XML that came back.

What I found was that if I called the web service once, it worked fine. If I called it twice in a row or more, only the first call worked, the others returned the extremely rare 505 HTTP error code, so I knew something weird was going on with my code.

It took me two hours to realize my mistake when it occurred to me to actually read the instructions. I was using the standard Java class HttpURLConnection, whose documentation warns:

“Each HttpURLConnection instance is used to make a single request but the underlying network connection to the HTTP server may be transparently shared by other instances. Calling the close() methods on the InputStream or OutputStream of an HttpURLConnection after a request may free network resources associated with this instance but has no effect on any shared persistent connection.”

That may read like Greek to all my non-programming friends out there, but I failed to call the close() method on the InputStream I was using to read the data from the HTTP server. When I added the close() call, I stopped seeing the 505’s.

Had I followed my own advice, I could have saved myself 2 hours of frustration. I incorrectly assumed that some advanced problem was going on and neglected to check the basics. When I did and rechecked the instructions, I found the culprit. Next time, I’ll know better.

Advertisements

Tags: ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: