A Note on Downloading Images to a Java Client via HTTP requests

I've been working on a little Java client to grab some internet data and process it into a nice little picture. In order to do this, I needed to be able to download pictures from an HTTP request into a BufferedImage.

When initially trying to find a way to do this, Google only gave me worthless pages about using the URLConnection.getContent() method, or saving to a file and loading that file, or a number of worthless suggestions. The simplest way to do it is to use the URLConnection as normal, but then to stick the InputStream into the IOImage.read() method, as follows:


URL url = new URL(urlstring);
URLConnection uc = url.openConnection();

InputStream content = (InputStream) uc.getInputStream();
BufferedImage image = ImageIO.read(content);


Be sure to wrap everything in the proper try/catch blocks and you are golden. Bonus points for starting a thread and running it in the background and notifying your canvas when it is ready. No sense in blocking your UI!

I also note that it has been 16 months since I used this blog, but this post serves an important internet service to those who don't program with Java as frequently as I --I mean they-- should.

Documentation Time

I'm struggling with making my first draft to be as high-quality as I would like it, especially with my time limitations before and during break. However, getting comments on what I have right now will be very good for future writing as well. I'm currently running performance tests on the system. My current test case is a long one. It is for 3 dimensions, and runs over 25 requests for each of average cached hits of 0%, 10%, ..., 90%, and 100%. Then, I'll compile this information into pretty little charts in Excel, where I have tables waiting to be filled.

An important note: I had to ditch Hibernate for persistence. When I got it working, I was getting terrible results for timing, and it was almost purely to the fault of the persistence mechanism. So, I rebuilt my R-Tree with flat files (during a frantic code session last Saturday) but have been getting very positive results since then. Here are a few charts I have compiled based on other tests. These charts are based on my timing method, that sleeps for a constant time at the start, and then iterates over the volume of the request, sleeping for a linear value. The constant simulates overhead of data requests, while the linear simulates the time of the calculation and other performance issues rising from the size of the request. A larger linear value should have better results for the cache, while a larger constant will have less (since the constant will be multiplied by the number of uncached regions). The first two have a constant of 50, linear of 3, while the second pair has linear of 20.

Success?

I had been having a hang up with my lazy writing to the cache, which was a major problem for me. By changing my CacheManagerBean to stateless instead of stateful, I was able to keep the bean around long enough to have a thread run through my queue of requested cache orders. This will most likely be a speed boost, since the stateful wasn't getting me much, anyway.

I've been running my performance checks, and after several cases, I still didn't have an error. However, I must keep in mind that it doesn't like my "Extended" type entity manager, and instead requires me to use transaction-level. This shouldn't cause too much of a problem, but I'll keep it in mind.

Tomorrow morning, I'll check the output and performance.

Annotations are the Problem

I've been trying to work out how I can insert large data sets into SQL through Hibernate without requiring my data sets to fit an interface that splits when too large (the overhead of exception handling would be too much, anyway). It would be best if I could just designate my value with extra parameters in the @Lob annotation. However, the annotation has no such properties, even though the XML version of defining the information would support such a customization. I guess that's what I get for trying to cut corners: they cut me back.

It's Been a While

I haven't posted in a while, but here's a good post of frustration!

I have been working on my thesis project, but have and issue with my Blobs... The default type of blob used by Hibernate is too small for my data. So, I need to find a way to make it create a column of type LONGBLOB, or at least MEDIUMBLOB, but it makes me sad. This one issue is (hopefully) all that stands between me and good perforance. However, not being able to save data sets larger than 1MB causes all sorts of issues.

Single Request Test Suite

Today, I created a new test program that I have programmed to make HTTP requests and time the important results. Now, I can list a few parameters and run several tests over all three types to see how long it takes to request a region with a certain volume, number of cache hits, and percentage hit. The framework is there to work, but for some reason I'm getting exceptions on the server. I'll work on fixing these bugs soon, so then I can create the framework for the load testing suite.

Creating Test Suites

My current task is creating a plan for the performance testing. One thing I know I'll need is a way to generate test cases. My plan is to make servlets that create certain types of test cases dependent on a certain set of parameters.

Right now, I'm making the test case for creating a set of regions (of a defined number) that intersect a region with a certain hit percentage. This will be used for tests that generate bar graphs comparing the three variations for Response Time vs. Hit Percentage over several volumes and numbers of intersecting regions.

To accomplish this, I'm making a quick class that attempts to evenly space some points around the region and then iterate their growth to make the total hit percentage as close to the request as possible. This should be finished today.

Then, the servlet will take the parameters, run it through this process, and save it to a file on the server, so the JMeter tests can repeatedly request the exact test case for the different types.

A similar approach will be taken for the performance over time and load testing cases. The test case will be randomly generated and saved, and then that exact test case will be repeated over each type of cache.

It will be interesting to see how many results I can gather, and then weed them down for a publication. I will probably use a lot of them in my thesis. The more data, the better, it seems from other theses I've seen.