Can one actionListener interrupt another?

Question

Good afternoon,
I've searched these forums and online for a solution to my problem, but I have had no luck thus far. In my JSF application, I have a page with multiple buttons bound to actionListener methods in the backing bean. One such button ('Start') initiates a process that could run indefinitely (to a maximum number of iterations as configured by the user), and another button ('Stop') is intended to terminate the first process at some user-specified time, if they want to stop it before it reaches it maximum.
(Both buttons/methods operate over private member data in a session scope bean -- there's no need to worry about coordinating communication between objects, just about two methods in the same object.)
I manage the interaction between the two methods via a separate class (each instance of the backing bean class gets its own instance of this manager class) with synchronized access to the flags that define the current state of Start's process. When the user clicks 'Stop', the bound method updates a flag that indicates the process should stop immediately (at the end of the 'Start' method's current loop iteration) and then calls a method that forces it to wait() until 'Start' finishes its processing and calls notifyAll(). Debugging through the interaction of the two threads, it looks like the mutli-threading control code works correctly.
When we actually get into the 'Stop' method's code, that is. What I am seeing is that after I click 'Start', while the request is still in the Invoke Application phase of the life cycle, if I then click 'Stop', the page is immediately rendered without completing the current iteration of the 'Start' method (and without the final processing step that method performs). In my debugger, I see that this first click of 'Stop' doesn't even hit the backing bean at all. It takes a second click to invoke the method bound to the button, at which point the multi-threading code executes as expected.
I could work around this problem by performing my "post-loop processing" as the final step inside the loop, but this could result in potentially expensive data massaging being needlessly performed many times. I could also treat it as a user-education issue and just tell them to click the button twice, but that's hardly professional. :-) I'm wondering if there's some well-known limitation that I'm not aware of, or (hopefully) some well-known solution to the problem of one actionListener seeming to abort while another is in process.
Thanks in advance for any help or advice,
Roger Alix-Gaudreau

Answer 1

Yes, that's pretty much what's happening. I thought that with both components being bound to the backing bean via actionListener elements (instead of action elements), I would be able to use some multithreading code to force the second click's processing to wait until the first was complete, thus making them end at the same time. I guess the technology doesn't quite support that approach, however. I should probably do some reading to get a deeper understanding of the technology...
Given that your guess that we're trying to interrupt one request with another is correct, I'm not sure if posting the code will help (except to confirm that guess), but here is the code for the buttons from the JSP page:
<h:commandButton styleClass="kiosk_cmd" id="btnStart"
   onclick="document.body.style.cursor = 'wait';"
   rendered="#{userSessionBean.viewableCompsMap['ReadEPCs.StartRead']}"
   disabled="#{userSessionBean.disabledCompsMap['ReadEPCs.StartRead']}"
   value="#{msgBundle.EPCMGR_Common_StartReadButton}"
   actionListener="#{readBean.doRead}"
   title="#{msgBundle.EPCMGR_Common_StartReadButtonTooltip}"/>
<h:commandButton styleClass="kiosk_cmd" id="btnStop"
   onclick="document.body.style.cursor = 'default';"
   rendered="#{userSessionBean.viewableCompsMap['ReadEPCs.StopRead']}"
   disabled="#{userSessionBean.disabledCompsMap['ReadEPCs.StopRead']}"
   value="#{msgBundle.EPCMGR_Common_StopReadButton}"
   actionListener="#{readBean.doStopRead}"
   title="#{msgBundle.EPCMGR_Common_StopReadButtonTooltip}"/>The method backing the Start Read button looks like this:
public void doRead(ActionEvent ae){
   //notify the StopReadManager that we're now reading
   stopMgr.setReading(true);
   loadReaderParms(EPCMgrConst.APP_LAYER_TRAN_READ,EPCMgrConst.APP_LAYER_ACT_READTAGS);
   if(!isReaderActive()){
      m_Logger.displayMsg(EPCMgrUtil.getMessage(EPCMgrConst.EPCMGR_ErrorKey_ReaderNotActive),EPCMgrConst.MSG_TYPE_ERROR);
      stopMgr.setReading(false);
   //build map of keyfields for request XML
   Map keymap= new HashMap();
   keymap.put(EPCMgrConst.XML_KEYVAL_DURATION, getDuration());
   keymap.put(EPCMgrConst.XML_KEYVAL_INTERVAL, getInterval());
   keymap.put(EPCMgrConst.XML_KEYVAL_CNTRINFO, "1");
   //perform the read(s), get epc data
   int readCycle= 0;
   while(readCycle < getMaxReads() && !stopMgr.isStopNow()){
      doStartRead(keymap);
      readCycle++;
      buildTagDisplayData();
   //notify the StopReadManager that we're done reading
   stopMgr.setReading(false);
}The code backing the Stop Read button looks like this:
public void doStopRead(ActionEvent ae){
   if(stopMgr.isReading()){
      stopMgr.setStopNow(true);
      while(!stopMgr.isReadingFinished()){
         //do nothing, the call waits until reading is done.
      //reset the StopReadManager
      stopMgr.setStopNow(false);
}And lastly, the code for the StopReadManager that those methods refer to:
public class StopReadManager {
   private boolean reading;
   private boolean stopNow;
   public StopReadManager(){
      reading= false;
      stopNow= false;
    * Producer for the reading flag is the "StartRead" process, consumer is "StopRead".
    * StartRead must set it to true when reading is in progress, StopRead should
    * only be able to exit a call to this method when reading is done (i.e. when
    * StartRead sets the reading flag to false.)
    * @return True when reading is finished.
   public synchronized boolean isReadingFinished(){
      while(reading){
         try{
            wait(); //Wait until StartRead is complete
         }catch(InterruptedException ie){ }
      //We are done reading.
      return true;
   public synchronized boolean isReading(){
      return reading;
   public synchronized void setReading(boolean value){
      reading= value;
      //If no longer reading, notify any threads waiting on the lock.
      if(!reading)
         notifyAll();
   public synchronized boolean isStopNow(){
      return stopNow;
   public synchronized void setStopNow(boolean value){
      stopNow= value;
}As I mentioned, the multithreading control code works correctly, once we hit it, which happens the second time I click the Stop button. The first time I click it, the screen immediately reloads (though the Start process continues in the background). So what I really need is the ability to make sure that if I click Stop while Start is still processing, it actually hits the backing bean code and enters the multithreading control code properly. You metion something called "shale's token". What is that, and how can it solve my problem?
Thanks,
Roger Alix-Gaudreau