Problem in customizing the Executor framework behaviour

[A Shahkar]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Dear all,

I'm developing a small framework which is intended to be used to simulate random requests on custom protocols against server applications. The following classes and interfaces are used to generate random requests which probably meet certain requirements enforced by the protocol.

public interface Randomizer<T> {
    public T randomize();
}
 
public class ProtoRequestRandomizer implements Randomizer<ProtoRequest> {
    // Generates random requests which meet Proto requirements
}
 
public interface RequestResource {
    // Supplies requests to be sent by client simulators.
    public Request getRequest();
}
 
public class MyRequestResource implements RequestResource {
     public RequestResource(Randomizer<? extends Request> randomizer) {
         // ...
     }
     @Override
     public synchronized Request getRequest() {
         // Generates a request using the supplied randomizer. It may simply call
         // randomize() or pick one from a collection of randomized requests.
         // If the collection is thread-safe, this method need not to
 be
 synchronized.
     }
}

There will be a Runnable or a Callable, which fetches a request provided by a RequestResource and sends it to a specified target. Something like this:

public class BlindRequestTask implements Runnable {
    public BlindRequestTask(RequestResource resource, Target target) {
        // ...
    }
    @Override
    public void run() {
        // Fetches a request (or a sequence of requests) from the specified RequestResource and sends it to the target, likely on a network.
    }
}

I want to use a thread pool created by the executor framework to send a total number of N requests (or N sequences of requests, whatever the sending task does) against a target. There is not N different tasks as you see, there's only one task which should be executed N times by multiple threads in a thread pool. However every time the task executes, the request is a different one which is got from the request resource. N can be a very big number, something around a few ten thousands.

The code should also be able to keep executing the task until shut down. Also, I want every thread to wait for a fixed delay before executing the repeated task again. It makes me able to reduce the load on the target if necessary. How can I achieve this? I'm searching for the most (or a very) efficient solution.

I thought it would be good to supply a customized ArrayBlockingQueue which returns the same task for N times to an executor. But I could not proceed any further because I don't know exactly which methods should be overriden, whether it is an efficient solution, and how can I add the delay feature.

Any other comments are also highly appreciated.

Thanks in advance.

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[A Shahkar]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Thanks Erkin.

I was told to take a similar approach when I posted the problem in Sun forums. IMHO, it has a few drawbacks.

Let's suppose N=1,000. We create a fixed thread pool with the size of 10, and instantiate BlindRequest to send 100 requests. We submit the BlindRequestTask 10 times to the thread pool. Now, for any reason, sending the forth request in the second thread takes a long time. Other threads likely finish their work far before the second thread does while it still has a few ten requests to send. Other threads won't help the second one finish its job, and that's not the way thread pool executors are intended to act it. Actually it does not make such difference (specially in performance) if we just run 10 threads instead of a pool, each one executing BlindTaskRequest. Am I right?

Thanks

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[Joe Bowbeer]

A Shahkar wrote:
 

Actually it does not make such difference (specially in performance) if we just run 10 threads instead of a pool, each one executing BlindTaskRequest. Am I right?

Yes, based on my understanding of your description, I think you are right, and that's the approach I'd recommend.

Joe

On Wed, Jul 15, 2009 at 3:11 AM, A Shahkar wrote:

Thanks Erkin.

I was told to take a similar approach when I posted the problem in Sun forums. IMHO, it has a few drawbacks.

Let's suppose N=1,000. We create a fixed thread pool with the size of 10, and instantiate BlindRequest to send 100 requests. We submit the BlindRequestTask 10 times to the thread pool. Now, for any reason, sending the forth request in the second thread takes a long time. Other threads likely finish their work far before the second thread does while it still has a few ten requests to send. Other threads won't help the second one finish its job, and that's not the way thread pool executors are intended to act it. Actually it does not make such difference (specially in performance) if we just run 10 threads instead of a pool, each one executing BlindTaskRequest. Am I right?

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[A Shahkar]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Thanks Erkin. Your idea about supplying the delay to the task's constructor solved one aspect of the problem. Delays are no more considered a dark point. Nice idea!

> So you can create your ThreadPoolExecutor first then pause, submit all
> the tasks and unpause the the threadPoolExecutor. So when test starts,
> you will not observe any delay because of request production.

I think actually now you can really understand what I was talking about in my original post.

As I told before, total number of requests (N) can be a very large number. Submitting a few thousand tasks makes the executor create a huge list of identical items. Not only this approach is extremely inefficient, but it also does not allow the application to make N equal to infinity. What is wrong with a user code which wants the framework's library to keep sending requests in a few threads until shut down?

As you might remember, I told about a customized ArrayBlockingQueue given to the executor in my original post. I thought that such a construct could return one task for N times, solving the huge list problem. It can hold an internal parameter which is equal to N and decrement it each time a thread fetches a task to execute. Or it can ignore the parameter if total number of requests is not known. The problem is, I don't know really how I can effectively implement such a construct which does not harm performance. I don't know which methods should be overriden and in what way. This somehow requires a deep understanding of how an executor works with its BlockingQueue.

Can you help me to implement the customized ArrayBlockingQueue?

Again, thank you for your idea on solving the delays problem.

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[Galder Zamarreno-4]

Where's the response Erkin sent? Did he reply to you direcly?
If so, could you share the email with us?

On 07/15/2009 12:11 PM, A Shahkar wrote:

> Thanks Erkin.
>
> I was told to take a similar approach when I posted the problem in Sun forums. IMHO, it has a few drawbacks.
>
> Let's suppose N=1,000. We create a fixed thread pool with the size of 10, and instantiate BlindRequest to send 100 requests. We submit the BlindRequestTask 10 times to the thread pool. Now, for any reason, sending the forth request in the second thread takes a long time. Other threads likely finish their work far before the second thread does while it still has a few ten requests to send. Other threads won't help the second one finish its job, and that's not the way thread pool executors are intended to act it. Actually it does not make such difference (specially in performance) if we just run 10 threads instead of a pool, each one executing BlindTaskRequest. Am I right?
>
> Thanks
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[Galder Zamarreno-4]

Same here, Erkin's replies do not appear in the archive:
http://cs.oswego.edu/pipermail/concurrency-interest/2009-July/thread.html

On 07/15/2009 02:25 PM, A Shahkar wrote:

> Thanks Erkin. Your idea about supplying the delay to the task's
> constructor solved one aspect of the problem. Delays are no more
> considered a dark point. Nice idea!
>
>
>> So you can create your ThreadPoolExecutor first then pause, submit all
>> the tasks and unpause the the threadPoolExecutor. So when test starts,
>> you will not observe any delay because of request production.
>
> I think actually now you can really understand what I was talking about in my original post.
>
> As I told before, total number of requests (N) can be a very large number. Submitting a few thousand tasks makes the executor create a huge list of identical items. Not only this approach is extremely inefficient, but it also does not allow the application to make N equal to infinity. What is wrong with a user code which wants the framework's library to keep sending requests in a few threads until shut down?
>
> As you might remember, I told about a customized ArrayBlockingQueue given to the executor in my original post. I thought that such a construct could return one task for N times, solving the huge list problem. It can hold an internal parameter which is equal to N and decrement it each time a thread fetches a task to execute. Or it can ignore the parameter if total number of requests is not known. The problem is, I don't know really how I can effectively implement such a construct which does not harm performance. I don't know which methods should be overriden and in what way. This somehow requires a deep understanding of how an executor works with its BlockingQueue.
>
> Can you help me to implement the customized ArrayBlockingQueue?
>
> Again, thank you for your idea on solving the delays problem.
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest