Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Test if Your Multi-Threaded Java Rest Service Is Thread Safe

DZone's Guide to

How to Test if Your Multi-Threaded Java Rest Service Is Thread Safe

Thomas Krieger shows how to test if your rest service is thread safe by analyzing a counter with a race condition and using a multi-threaded test runner.

· Java Zone ·
Free Resource

Verify, standardize, and correct the Big 4 + more– name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!

In the following article, you will see how to test if your rest service is thread safe. Let us start with a simple example—a counter which contains a race condition.

The Not-Thread Safe Counter

As an example, we use the following jersey rest service. It consists of a resource that increments a counter for each post call and returns the new value:

@Path("counter")
public class Counter {

     private static int i = 0;

    @POST
    @Produces(MediaType.TEXT_PLAIN)
    public String addOne() {

    return new Integer(i++).toString();
    }
}

This is clearly not thread safe. The access to the variable counter is not synchronized, which will lead to a race condition, if the method “addOne” is called from too many threads in parallel. Let us see, if we can detect this bug with a test.

The Test

To test if this service is thread safe, we need a multi-threaded test, like the following:

@RunWith(ConcurrentTestRunner.class)
public class CounterTest {

    private HttpServer server;
    private WebTarget target;

    @Before
    public void setUp() throws Exception {
        server = Main.startServer();
        Client c = ClientBuilder.newClient();
        target = c.target(Main.BASE_URI);
    }

    @After
    public void tearDown() throws Exception {
        server.shutdown();
    }


    @Test
    public void testAddOne() {

    String responseMsg = target.path("counter").request().post(Entity.json(null) , String.class);
    /*
     * 
     * Checking the responseMsg left out for brevity...
     * 
     */  
    }
}

The concurrent test runner runs the test method in parallel with THREAD_COUNT threads. To detect race conditions, we need a tool, which can detect race conditions during tests. One such tool is vmlens. We can enable it by adding the vmlens agent path to the vm arguments. After running, we will see the race condition in vmlens:

Race Condition in REST Service

After we have found the race condition, we want to fix the race.

Making the Rest Service Thread Safe

The easiest way to do this is to use a java.util.concurrent.atomic.AtomicInteger. AtomicInteger uses a volatile field internally, making updates visible to all threads. And the used method “addAndGet” is made atomic by using compareAndSet.

@Path("counter")
public class Counter {

     private static AtomicInteger i = new AtomicInteger();


    @POST
    @Produces(MediaType.TEXT_PLAIN)
    public String addOne() {

    return new Integer(i.incrementAndGet()).toString();
    }
}

Conclusion

To test a multi threaded java rest service, we needed two things—a multi-threaded test runner and a tool that can detect Java race conditions. For the multi-threaded test I used concurrent-junit, for the race condition detection I used vmlens. If you have a question or remark, please add a comment in the comments section.

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.

Topics:
java ,multithreading

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}