Tomasz Nurkiewicz around Java and concurrency

Few days ago I had a pleasure to attend Coderetreat summer 2012 in Oslo, carried out by Johannes Brodwall. It was a great experience, I had an opportunity to do some pair programming with six different people and learnt quite a lot about both programming and productivity. You can find some more thoughts about the event on Anders Nordby's article (+ C# implementation of the problem we were solving throughout the day).

So what was the problem? Suspiciously simple: develop a function taking an arbitrary character and printing a diamond-shape like this:

test("should generate A diamond") { diamond('A') should equal (List( "A" )) } test("should generate D diamond") { diamond('D') should equal (List( " A ", " B B ", " C C ", "D D", " C C ", " B B ", " A " )) } The first approach all of us tried was a terrible mixt…

Sometimes we just need CAPTCHA, that's a sad fact. Today we will learn how to integrate with reCAPTCHA. Because the topic itself isn't particularly interesting and advanced, we will overengineer a bit (?) by using Spring Integration to handle low-level details. The decision to use reCAPTCHA by Google was dictated by two factors: (1) it is a moderately good CAPTCHA implementation with decent images with built-in support for visually impaired people and (2) outsourcing CAPTCHA allows us to remain stateless on the server side. Not to mention we help in digitalizing books.

The second reason is actually quite important. Typically you have to generate CAPTCHA on the server side and store the expected result e.g. in user session. When the response comes back you compare expected and entered CAPTCHA solution. Sometimes we don't want to store any state on the server side, not to mention implementing CAPTCHA isn't particularly rewarding task. So it is nice to have something read…

Some time ago I came across What's the purpose of AsyncContext.start(...) in Servlet 3.0? question. Quoting the Javadoc of aforementioned method:

Causes the container to dispatch a thread, possibly from a managed thread pool, to run the specified Runnable.


To remind all of you, AsyncContext is a standard way defined in Servlet 3.0 specification to handle HTTP requests asynchronously. Basically HTTP request is no longer tied to an HTTP thread, allowing us to handle it later, possibly using fewer threads. It turned out that the specification provides an API to handle asynchronous threads in a different thread pool out of the box. First we will see how this feature is completely broken and useless in Tomcat and Jetty - and then we will discuss why the usefulness of it is questionable in general.

Our test servlet will simply sleep for given amount of time. This is a scalability killer in normal circumstances because even though sleeping servlet is not consuming CPU, but sleeping HTTP t…