Logic for controll concurrent in block/method

1)My environment is web application, I develop servlet to receive request.

A) In some block/method i want to control concurrent to not greater than 5

B) if there are 5 request in that block , the new coming must wait up to 60 second then throws error

C) if there are sleep/waiting request more then 30, the 31th request will be throwed an error

How I do this?

2)(Optional Question) from above I have to distribute control logic to all clustered host. I plan to use hazelcast to share the control logic (e.g. current co开发者_C百科unter)

I see they provide BlockingQueue & ExectorService but I have no idea how to use in my case. Please recommend if you have idea.

For A take a look at this: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Semaphore.html

For B take a look at Object.wait() and Object.notify()

C should be easy if you have A and B.

The answers by @Roman and @David Soroko say how to do this within a servlet (as the OP asked).

However, this approach has the problem that tomcat has to allocate a thread to each request so that the they can participate in the queuing / timeout logic implemented by the servlet. Each of those threads uses memory and other resources. This does not scale well. And if you don't configure enough threads, requests will be either dropped by the tomcat request dispatcher or queued / timed out using different logic.

An alternative approach is to use a non-servlet architecture in the webserver; e.g. Grizzly and more specifically Grizzly Comet. This is a big topic, and frankly I don't know enough about it to go deeply into the implementation details.

EDIT - In the servlet model, every request is allocated to a single thread for its entire lifetime. For example, in a typical "server push" model, each active client has an outstanding HTTP request asking the server for more data. When new data arrives in the server, the server sends a response and the client immediately sends a new request. In the classic servlet implementation model, this means that the server has to have an request "in progress" ... and a thread ... for each active client, even though most of the threads are just waiting for data to arrive.

In a scalable architecture, you would detach the request from the thread so that the thread could be used for processing another request. Later (e.g. when the data "arrived" in the "server push" example), the request would be attached to a thread (possibly a different one) to continue processing. In Grizzly, I understand that this is done using an event-based processing model, but I imagine that you could also uses a coroutine-based model as well.

Try semaphors:

A counting semaphore. Conceptually, a semaphore maintains a set of permits. Each acquire() blocks if necessary until a permit is available, and then takes it. Each release() adds a permit, potentially releasing a blocking acquirer. However, no actual permit objects are used; the Semaphore just keeps a count of the number available and acts accordingly.