Cannot Cancel @Asynchronous call to EJB

Question

What am I doing wrong in this simplest of examples? (Glassfish 4.0-b87 + Eclipse Kepler m6)

Myself.java

package com.example.cancelbug;

import java.util.concurrent.ExecutionException;
import java.util.concurrent.Future;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.inject.Inject;

@Singleton
@Startup
public class Myself {
  @Inject Other other;
  private Future < Integer > future;

  @PostConstruct
  public void post_construct () {
    System.out.println("post_construct started");
    future = other.ton_of_work();
    System.out.println("post_construct ended");
  }

  @PreDestroy
  public void pre_destroy () {
    System.out.println("pre_destroy started");
    System.out.println("cancel result: " + Boolean.toString(future.cancel(true)));
    try {
      System.out.println("future result: " + future.get().toString());
    } catch (InterruptedException | ExecutionException e) {
      System.out.println("future result: interrupted");
      Thread.currentThread().interrupt();
      System.out.println("thread reinterrupted");
    }
    System.out.println("pre_destroy ended");
  }
}

Other.java

package com.example.cancelbug;

import java.util.concurrent.Future;

import javax.ejb.AsyncResult;
import javax.ejb.Asynchronous;
import javax.ejb.Stateless;

@Stateless
public class Other {
  @Asynchronous
  public Future < Integer > ton_of_work () {
    System.out.println("other: ton_of_work started");
    int i;
    for (i = 0; i < 10; ++i) {
      try {
        System.out.println("other: take a nap");
        Thread.sleep(1000L);
        System.out.println("other: woke up: " + Integer.toString(i));
      } catch (InterruptedException e) {
        System.out.println("other: ton_of_work interrupted");
        Thread.currentThread().interrupt();
        break;
      }
    }
    System.out.println("other: ton_of_work returning");
    return new AsyncResult < Integer >(new Integer(i));
  }
}

Output

post_construct started
post_construct ended
other: ton_of_work started
other: take a nap
other: woke up: 0
other: take a nap
other: woke up: 1
other: take a nap
other: woke up: 2
other: take a nap
pre_destroy started
cancel result: false            <<<<<<< expected true; ton_of_work: interrupted
other: woke up: 3               <<<<<<< expected no such output
other: take a nap               <<<<<<< expected no such output
other: woke up: 4               <<<<<<< expected no such output
other: take a nap               <<<<<<< expected no such output
other: woke up: 5               <<<<<<< expected no such output
other: take a nap               <<<<<<< expected no such output
other: woke up: 6               <<<<<<< expected no such output
other: take a nap               <<<<<<< expected no such output
other: woke up: 7               <<<<<<< expected no such output
other: take a nap               <<<<<<< expected no such output
other: woke up: 8               <<<<<<< expected no such output
other: take a nap               <<<<<<< expected no such output
other: woke up: 9               <<<<<<< expected no such output
other: ton_of_work returning
future result: 10               <<<<<<< expected 2
pre_destroy ended

Expected Output:

post_construct started
post_construct ended
other: ton_of_work started
other: take a nap
other: woke up: 0
other: take a nap
other: woke up: 1
other: take a nap
other: woke up: 2
other: take a nap
pre_destroy started
cancel result: true             <<<<<<< actual false
other: ton_of_work interrupted  <<<<<<< actual missing
other: ton_of_work returning
future result: 2                <<<<<<< actual 10
pre_destroy ended

Answer 1

EJB 3.1 only provides cooperative async interupts; that is, the EJB can check if the client has called cancel. There is no way to get an actual Thread.interrupt even if Future.cancel(true) is called.

There is an open EJB specification issue (EJB_SPEC-73) to allow actual thread interrupts. This was discussed on the EJB 3.2 expert group (1, 2, 3, 4, 5, 6), but the discussion was eventually deferred to the next version of the EJB specification.