Chaotic Java

The classic producer-consumer pattern makes a few assumptions in order to work. In this post I’ll discuss some of these assumptions, what happens when they break, and a cool solution to deal with it.
The two assumptions I’d like to discuss are:

1. All producers are equal – this means that all producers are limited by one, shared limit – the mediator queue between them and the consumers. This is a great assumption for most implementations: usually you are limited by the amount of work your consumers can handle and usually those are limited by the amount of processors you would physically have, therefore it doesn’t matter if the piece of work came from producer X or producer Y – either way you’d still have the same amount of processors.
2. Once sent to the queue, a producer doesn’t care about its products – this means that there is no link between the produced work and the producer once it has been sent to the mediation queue. And why should it? Its task was to create the work, afterwards its the consumer’s job to deal with the work, and then it would be the garbage collector’s task to reclaimed the memory space that work used. If the producer kept a link to the work, it couldn’t have been reclaimed without proper notifications between the producer and the consumer – and that would be completely against the decoupling nature of the producer-consumer pattern.

So far you might be thinking “these are good, based assumptions; why should they ever break?”. Well, keep on reading then. Continue reading »

It’s called garbage collection, not resource collection!

Java’s garbage collector has made life so easy for us developers that we sometimes confuse between deleting a reference, i.e. a task the GC does, and releasing a resource – a task the GC doesn’t do. That’s because the GC does something else for us called object finalization, where resources usually clean themselves up.

When I say resources, just think of input/output streams, readers/writers, channels, JDBC, JMS.. the list could go on and on. I almost expect to see code such as: Continue reading »

Imagining a method which receives as a parameter a type Object instance and needs to perform some action according to its type is not difficult. In fact, there are several design patterns that, when used in combination, help solve just that. However, this post is about adding a new switch..case construct to prevent some boiler-plate caused by these patterns.
Continue reading »