ThreadPoolExecutor.afterExecute(Runnable r, Throwable t) is not behaving as per documentation

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

ThreadPoolExecutor.afterExecute(Runnable r, Throwable t) is not behaving as per documentation

Jagadheeswar Reddy

Hi ,

 

I have created a runnable task and deliberately created an unchecked exception in my run method.

 

My class TaskExecutor extends  ThreadPoolExecutor  and overrides afterExecute method .

 

When I check for Throwable object in this method, it is still null, inspite of throwing unchecked exception in run method

 

My code:

 

public class TaskExecutor extends ThreadPoolExecutor {

       

            public TaskExecutor() {

 

                        super(2, 2, 10, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(5));

}

 

 

            public boolean scheduleTask(Runnable r) {

                                    Future<Object> resultFetcher;

                                    Object result = "hello runnable executed successfully";

                                    resultFetcher =submit(r, result);

                                    return true;

            }

            protected void afterExecute(Runnable r,Throwable t){

                                    try{

                                               

                                    super.afterExecute(r,t);

                                    System.out.println("inside the method afterExecute");

                                   

                                    if(t!=null){

                                                System.out.println("Exception is thrown in Runnable method");

                                    }          

                           

                        }catch(Exception e){

                                    e.printStackTrace();

                        }

                       

            }

 

}

 

 

My runnable task run method throws NullPointerException :

 

  public void  run(){

             Object out=null;

            System.out.println("inside the runnable task method"+out.toString());

     }

 

 

Please let me know if iam doing something wrong

 

Thanks& Regards

Reddy

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ThreadPoolExecutor.afterExecute(Runnable r, Throwable t) is not behaving as per documentation

Joe Bowbeer
On 5/3/06, Jagadheeswar Reddy <[hidden email]> wrote:

>
> I have created a runnable task and deliberately created an unchecked
> exception in my run method.
>
> My class TaskExecutor extends ThreadPoolExecutor  and overrides
> afterExecute method .
>
> When I check for Throwable object in this method, it is still null, inspite
> of throwing unchecked exception in run method
>

The ThreadPool is "executing" a FutureTask rather than a Runnable, and
FutureTask is catching the exception:

    public boolean scheduleTask(Runnable r) {
        Future<Object> resultFetcher;
        Object result = "hello runnable executed successfully";
        resultFetcher =submit(r, result);
        return true;
    }

Try this:

    public boolean scheduleTask(Runnable r) {
        execute(r);
        return true;
    }

--Joe

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: implementing a DB write-behind algorithm

Jonathan Lawrence
Hi,

This response partly overlaps with some of last week's (notably those
discussing hijacking & CAS algorithms).
I've come across a *very* similar problem before, in connection with
batching log writes from multiple threads, using twin bounded size buffers
to hold the records prior to flushing them to a backing store.

The main design parameters were:
- multiple concurrent client threads writing records.
- twin bounded size buffers to hold records prior to flushing to the
backing store.
- a single asynchronous backend process to flush the filled buffers.

Design:
- Employs a controlling monitor component to manage interactions between
threads and the system. This involves hijacking, but only to trigger rather
than perform the backend writes.
- Buffers may be written to concurrently but exclusive access is required
to flush.  This ensures that the records have been fully written before the
buffers are flushed.
- Prevents overtaking (i.e. all records written by a thread appear in the
correct order in the backing store).
- Has been modelled in a formal process algebra and verified using an
automated model-checking tool.

Java implementation.

There is an existing Java implementation of the design which is really a
model of the intended target implementation on another platform, which
would have used low-level primitives such as CAS directly.
The implementation pre-dates JSR 166 and so it uses wait-notify and
synchronization (with highly granular scope) to manage concurrency, however
it could be easily adapted to use the new features such as concurrent
queues & atomic variables instead.

Optional extensions.
The following features could readily be added to the basic design:
- Thread may force record(s) it has written (i.e. request and block until
the record has been committed to the backing store).
- Such requests may be suspended (with timeout) to allow further records to
be added to a partially filled buffer.

If you are interested I could give more details here or offline.

Jonathan.

================
Jonathan Lawrence
Java Technology Centre
IBM United Kingdom Ltd., Hursley Park, Winchester,  SO21 2JN.
Tel: +44 (0)1962 816197  Internal: 246197  Mobex: 272322
[hidden email]

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest