Subsequent REST call is blocked until previous one is finished

Question

I Have REST service

@Path("/rest")
@Component
public class MyRestService
{
    @Inject
    private MyBean bean;

    @GET
    @Path("/do")
    public String start()
    {
        this.logger.info("Before do " + Thread.currentThread().getId());
        String result = this.bean.do();
        this.logger.info("After do " + Thread.currentThread().getId());

        return result;
    }
}

which calls method of injected Spring singleton bean (with some state inside)

@Service
public class MyBean
{
    public String do()
    {
        // do something big...
    }
}

When I call ".../rest/do" in browser the first call goes as expected, but if I make same call in another tab this call waits until first is finished to process second call in same thread.

If I do second call as ".../rest/do?async=true" it does not wait and processes second request in new thread, but if I do both requests as ".../rest/do?async=true" - second one again waits for the first one to finish.

What could be the reason for such behavior? Is it actually expected?

My web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    version="2.5">

    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
    </welcome-file-list>

    <display-name>My REst</display-name>

    <!-- spring configuration by annotations -->
    <context-param>
        <param-name>contextClass</param-name>
        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
    </context-param>

    <!-- spring configuration class -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>app.Config</param-value>
    </context-param>

    <!-- to return data according to extension -->
    <context-param>
        <param-name>resteasy.media.type.mappings</param-name>
        <param-value>json : application/json, xml : application/xml</param-value>
    </context-param>

    <!-- this has to match with resteasy-servlet url-pattern -->
    <context-param>
        <param-name>resteasy.servlet.mapping.prefix</param-name>
        <param-value>/rest</param-value>
    </context-param>

    <listener>
        <listener-class>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class>
    </listener>

    <!-- resteasy spring connector (to use DI in rest-resources) -->
    <listener>
        <listener-class>org.jboss.resteasy.plugins.spring.SpringContextLoaderListener</listener-class>
    </listener>

    <servlet>
        <servlet-name>resteasy-servlet</servlet-name>
        <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
    </servlet>

    <!-- this has to match with resteasy-servlet url-pattern -->
    <servlet-mapping>
        <servlet-name>resteasy-servlet</servlet-name>
        <url-pattern>/rest/*</url-pattern>
    </servlet-mapping>

    <!-- Bind Jboss's TransactionManager (EntityManagerFactory) to JNDI -->
    <persistence-unit-ref>
        <persistence-unit-ref-name>persistence/ReferenceDataDS</persistence-unit-ref-name>
        <persistence-unit-name>ReferenceDataDS</persistence-unit-name>
    </persistence-unit-ref>
</web-app>

Answer 1

You can solve this issue running your application server in debug mode. Do the test with two different clients e.g. Firefox, Chrome, IE, Opera, ... While waiting for the answer pause all the threads.

• If you see only one workerthread active, then the settings of the application server are the problem.
• If you see multiple workerthreads active but one of them is waiting for a semaphore, you have a problem with multiple threads accessing the same resource
• If you have multiple workerthreads active but one of them is waiting for a connection to the persistence store, then you're datasource doesn't have a connection pool.