The pattern separates asynchronous I/O from the synchronous one. Main thread doesn't block on incoming client requests and long-running operations are offloaded to a dedicated synchronous layer. Processing results are delivered by the means of callbacks.
Sunday, 31 August 2014
Saturday, 30 August 2014
The pattern revolves around synchronization. In short, concurrent threads (clients) can only use the object via a set of synchronized methods. Only one method can run at a time. Typically a synchronized method watches for a certain condition. However, there is no polling involved. Instead, the methods are being notified. That's an important difference in comparison to the Active Object.
Active Object pattern decouples method execution from its invocation. Think asynchronous method invocation, callbacks etc. To avoid race conditions, incoming client requests are queued and handled by a scheduler. The scheduler picks a queued object and makes it run its logic. It is object's responsibility to know what to do when it gets invoked, hence the Active Object.
Here is how to terminate a stuck screen command using a script. As part of my job I deal with a legacy Linux setup comprising a range of screens. Every now and then some of them freeze due to memory issues and attaching a session doesn't work anymore. I was wrapping my head around how to avoid tedious manual resets of the dead screens. Turns out all can be easily automated.
Thursday, 3 April 2014
Up until Spring 4 generics played no major role when it came to resolving injected bean dependencies. Suppose there are multiple beans of the same type implementing a generic interface. In a pre-Spring 4 world, any attempt to resolve such a bean by type would inevitably lead to a NonUniqueBeanDefinition exception, unless additional hints were provided (such as @Qualifier). Spring 4 removes this limitation by making generics a distinguishing part of a bean definition. Here is a short example.
Sunday, 23 March 2014
I've got the aforementioned exception when I was trying to load a jsp page on Tomcat 6 running in a debug mode. Turns out the problem occurs when a jsp page grows big. It's a known JVM issue described by bugs 39089 and 6294277. Here is how to solve it without touching the jsp.
Monday, 3 March 2014
Less unit test code doesn't necessarily result into poor coverage. I've recently entered the paradigm of parameterized tests when refactoring a larger test suite. I ended up writing significantly less code without compromising on the extent. In fact, adding a few corner cases was almost a no-brainer. In this post I'd like to share my experience with JUnitParams and discuss advantages of parameterized unit tests.