Restlet 2.2.1 only serves from one thread

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Restlet 2.2.1 only serves from one thread

Robert Barnett
I had a very strange latency issue pop up today which I have isolated to an apparent issue with 2.2.1.  I can take the "Hello World" stand alone example from Restlet.com and modify the Resource to be:

package firstSteps;

import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;

public class HelloWorldResource extends ServerResource {

    @Get
    public String represent() throws InterruptedException
    {
        System.out.println(Thread.currentThread().getId());
        Thread.sleep(10000);
        return "hello, world";
    }
}

I then take two browsers, Firefox and Chrome, and make a request from each.  Firefox shows Hello World after 10 seconds and Chrome after 20.  Looking at the console I see that both requests were serviced by the same thread.  I can the take my load generator, jMeter, and send a lot of requests in parallel to Restlet.  Restlet processes them one at a time and always with the same thread. It is as if the default thread pool size is one. When I downgrade to 2.1 and run the same tests, the issue goes away with a variety of threads servicing the requests in parallel.

Please advise.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3086285
Reply | Threaded
Open this post in threaded view
|

Re: Restlet 2.2.1 only serves from one thread

Thierry Boileau-4
Hello Robert,

I've added an issue for that question with a few line for analysis: https://github.com/restlet/restlet-framework-java/issues/937
This issue concerns the internal HTTP server connector which can be used for development, but not for production.

You can use the Jetty and Simple connectors which are right choices for production environments.

Best regards,
Thierry Boileau


2014-08-06 6:17 GMT+02:00 Robert Barnett <[hidden email]>:
I had a very strange latency issue pop up today which I have isolated to an apparent issue with 2.2.1.  I can take the "Hello World" stand alone example from Restlet.com and modify the Resource to be:

package firstSteps;

import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;

public class HelloWorldResource extends ServerResource {

    @Get
    public String represent() throws InterruptedException
    {
        System.out.println(Thread.currentThread().getId());
        Thread.sleep(10000);
        return "hello, world";
    }
}

I then take two browsers, Firefox and Chrome, and make a request from each.  Firefox shows Hello World after 10 seconds and Chrome after 20.  Looking at the console I see that both requests were serviced by the same thread.  I can the take my load generator, jMeter, and send a lot of requests in parallel to Restlet.  Restlet processes them one at a time and always with the same thread. It is as if the default thread pool size is one. When I downgrade to 2.1 and run the same tests, the issue goes away with a variety of threads servicing the requests in parallel.

Please advise.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3086285

Reply | Threaded
Open this post in threaded view
|

RE: Re: Restlet 2.2.1 only serves from one thread

Robert Barnett
Hi Thierry,

Can you help me understand why the out of the box configuration is not appropriate for production?

Best,
Matt

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3086334
Reply | Threaded
Open this post in threaded view
|

RE: Re: Restlet 2.2.1 only serves from one thread

Thierry Boileau-4
Hello Robert,

from the beginning of Restlet Framework, our most important aim is to provide a clear and rich API for developing both client and server side applications.
Implementation comes later and we're fine to take shortcuts and to leverage well-established frameworks such as Jetty (which was the first HTTP server connector shipped with Restlet).

Of course, we had, and yet still have, the intention to provide production-ready home made client and server HTTP connectors. The first implementations relied on the classic basic IO, then an effort was made to develop full NIO connectors, because we saw that as an opportunity to provide scalable connectors, asynchronicity, etc. At a time, we recognized that we were lacking time or contributions in order to fully achieve this task (even if we think we are close to it), and thus decided to export this into the org.restlet.ext.nio module, and replace it with the com.sun implementations internally. In addition, constantly and transparently we always claimed that these internal connectors are fine for development environment not for production.

I'm not sure to give you the best answer, feel free to ask for more, or to help us reconsider the current position.

Best regards,
Thierry Boileau
PS: I've just committed code in the 2.2 and 2.3 branches, in order to add a decent thread pool to the internal HTTP server connector.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3087184