>Concurrency Testing in Eclipse

>Gary Karasiuk recently did a good presentation on Multi Threading for the Web Tools Platform committers. While I agree with much of the information there is some I think from an adopter and design stand point is a little over kill. Personally I’m not a fan of making an object Immutable with the final qualifier. With that said, I do agree with much of the other information.

One question I asked, was if there was any research that had been done for this presentation on how one can go about testing for concurency issues? They had not looked into unit testing for these issues, yet. I know that in Robert Martin’s (aka Uncle Bob) book, “Clean Code” they devote a couple of chapters to it. They recommend many of the items that Gary suggested plus several more. One testing framework that they did mention, that works with your existing Junit tests, is ConTest. I have not reviewed or used this yet, mainly because I try to avoid threading unless it is absolutely necessary. However, ConTest does have some information on how to use it with your Eclipse Plugin Tests to help detect and test for various concurrency issues.

Personally, I think threading is being over used most of the time. Just because it can be used does not necessarily mean it should be used. Also, as outlined in Clean Code, there is not enough seperation between the threading code and the non-threaded code. In many cases this gets mixed together, and becomes a nightmare to maintain and debug when issues occur. So my general rules:

  • Only implement threading if you absolutely need it.
  • Keep your threaded code short, avoid long running threads.
  • Write Unit Tests for your threaded code.
  • Test your code on multiple target platforms. Different JVM’s and Operating Systems handle threading differently. What works on one system may fail on another.

Testing threaded code is a pain. Just look at all the concurrency issues that can happen during testing the Launching and Debugging framework. In XSL Tools, we have one test that periodically fails, and it’s due to testing the Launching of XSL Transformations. This is a multi-threaded process and is a pain to debug. Sometimes it works, sometimes it doesn’t during the test runs.

If a test is randomly failing, you may have a concurrency issue that is causing the failure. These types of issues are madenning to debug. So unless you need threads, avoid them. Use them when they really provide a benefit, and use them for short durations. The longer the duration a thread or the more it spawns it’s own threads, the more likely you are to run into concurrency issues.

This entry was posted in agile, eclipse, testing, xml. Bookmark the permalink.

7 Responses to >Concurrency Testing in Eclipse

  1. >Hi Dave,I agree that threading is probably over-used. However, writing thread-safe code is a good habit even when one does not create threads directly oneself.In an OSGi environment, we write components that are (or should be) reusable in unanticipated future scenarios. Even if we avoid threading in our own bundles, other bundles in the framework may use threading extensively. As a result, our components must be prepared to receive callbacks and service invocations in multiple threads concurrently.The more robust we make our components, the more reusable they are, so testing tools like ConTest could be really useful.Neil

  2. David Carver says:

    >Neil, agreed. In fact, I ran into this little issue with XSL Tools when executing some XPaths using Xalan. Xalan is not setup to be threadsafe, so I had to wrap it in a synchronize lock for that particular portion.I just went through threading hell for the launching/debugging framework, but that is another blog entry.

  3. >Why do you feel that using final and immutability is overkill? I’ve been using them the last couple of years after having read Java Concurrency in Practice and now I use them whenever I can, particularly when trying to crate immutable objects.Take a look at this excellent talk on testing concurrent software by that book’s author and two others (Brian Goetz, Bill Pugh and Cliff Click)

  4. David Carver says:

    >@Robert: Let me clarify a little on my oposition to final. Final is fine when used on fields within classes. Where I have the issue is when a class itself is made final in the name of making it Immutable just for the sake of making it thread safe. The issue here is that as soon as a you make a Class final, it can not be extended.In many cases when designing software and frameworks, and particularly plugins/bundles we do not necessarily know what our users of these frameworks and bundles will want to do with the classes you provide. I’ve run into this a number of occassions when working with various frameworks, and it drives me insane when I run accross a final class that should be allowed to be extended.There are exceptions, but they have to be very special, and there has to be no other way to do it before I’ll make a class or method final.

  5. >@David that’s a good point about the framework. I’m sure you know there are ways to deal with framework extension without relying on inheritance (e.g. delegation) but I’m not arguing in favor of it, just making sure it’s mentioned.While this can be infuriating at times as a framework extender, why not default to final / private, and on request, move things toward non-final / public, which, by the way, is a way bigger issue than concurrency.

  6. David Carver says:

    >@Robert: The problem there is the amount of time that it can take to get what appears to be a small change actually completed. I’ve seen such requests sit in bugzilla for years, and I’ve seen them reacted to very quickly.There needs to be a balancing act between how much lockdown we do with the Final qualifier and how extensible through inheritance we allow the classes. I tend to favor a more extensible approach, and lockdown only when absolutlely necessary, as opposed to a more closed approach.Regardless threading is an issue we all have to deal with and maybe making sure synchronize is on all the methods is enough, or making sure we are using the Concurent Classes that were introduced in Java 5 will help. Of course the later does no good for code that has to run on JRE 1.4.

  7. tomita says:

    >If you happen to be developing on Windows (Linux soon), you can use PetraVM's product, "Jinx" to amplify the occurrence rate of concurrency errors in threaded code. The tool works with Eclipse although there is no specific Eclipse plugin. We have an article we wrote about this topic at this link. PetraVM's website is here. This seems apropos enough to not be spam. Would enjoy hearing your feedback.Cheers,Pete

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s