Akka Actors

I really like the notion of using akka actors in Java. Basically it is trying to solve the problem of easily writing thread safe code. It does this by passing immutable messages to actors which process them. The idea is that the actor should be stateless and only act upon the immutable object it's given. They also appear to have Software Transactional Memory (STM) for when you do need mutable object and locking.


I have doubts novice programmers which couldn't write a correct singleton or proper thread safe class would be able to use akka to write thread safe code. I could see them creating all kind of actors which are not thread safe.


I did find it was really easy to get a lot of concurrency almost to a fault where my laptop was maxed out and overheating. Of course that may have been my fault as I gave it an infinite computation to work on.


I don't understand why packages don't have remoting support built for the Servlet API. Akka has a remoting support but I always work in a full J2EE container so getting ports opened and bypassing it would not be an option. I would like to know who needs stand alone remoting and is not working with at least Tomcat.

I'll definitely check akka out in more depth.

Thread Safe Code and Stress Testing

It just amazes me how much code makes it past code reviews that is not thread safe but should be.
Developers often know that certain code has troubles if it is not thread safe and what thread safe means. However they are not able to effective discern what needs to be thread safe and what does not. I had an individual that was very aware of these issues help mentor me as to how to detect these types of problems. I had seen problems and fix them prior to his mentoring but he really helped me to be proactive and see threading issues when authoring code.

The biggest issue is lack of understanding that beans defined in Spring are singletons. Also even if you inject a prototype into a singleton it effectively makes it a singleton. Then there are the problems where they improperly implement the singleton pattern, randomly synchronize things that don't need to, or create static variables that are not thread safe. I've seen so many times where developers create a static SimpleDateFormat instance. Recently I saw a DAO with local variables that were not thread safe. I also recently saw a persistence layer where they tried to manually implement the singleton pattern but didn't do it correctly so the local variables that were thread safe were not initialized correctly leading to NullPointerExceptions.

I tend to see threading issues revealed when load testing is performed. However to my amazement load testing is not always performed. I've also seen some some threading issues that have snuck past load testing and have never presented themselves as a problem.

We use a continuous integration build server but it only lists thread safety problems as warnings and then only catches half of them because it doesn't know what should or shouldn't be a singleton and thread safe any more than the developers do.

I've recently initialized an internal developer training effort.
There are relatively few developers that can detect these errors and even fewer that can fix them. So it is really an issue as these developers can not code review every line of code.

Are there any ways to catch these kind of problems earlier or some good resources to aid in developer training? Do people have similar experiences?

It seems most developers don't care that code has any more quality than it appears to work correctly. Am I being a little anal retentive and should just go with the flow, realize that code will not be perfect, and just let these problems exist and get resolved later?