[jboss-jira] [JBoss JIRA] Created: (JBAS-6400) ExecutionContext returns the trasnaction timeout in seconds, but we use that argument to schedule the thread that is in milliseconds.

[Jay Howell (JIRA)]

ExecutionContext returns the trasnaction timeout in seconds, but we use that argument to schedule the thread that is in milliseconds.
-------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-6400
                 URL: https://jira.jboss.org/jira/browse/JBAS-6400
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-5.0.0.GA, JBossAS-4.2.2.GA
            Reporter: Jay Howell
            Assignee: Jesper Pedersen
             Fix For: JBossAS-5.0.1.GA, JBossAS-4.2.4.GA


PLEASE NOTE:  THIS ONLY AFFECTS 3RD PARTY ADAPTERS RUNNING INSIDE THE JBOSS APP SERVER.  THIS DOES NOT AFFECT ANY OF THE ADAPTERS THAT JBOSS SHIPS WITH.

The implementing adapter handles scheduling work to be performed.  So they usually do something like..

     WorkManager wm = adapter.ctx.getWorkManager();
     TestWork work = new Somework();
     ExecutionContext ec = new ExecutionContext();
     ...
     ec.TransactionTimeout(trans.getTimeout())
     wm.doWork(work, 0l, ec, null);

Usually the work class schedules the work by telling the WorkManager to do some work(dowork).  If you don't specify a timeout in the execution context, the thread will wait indefinilty to finish the work.  In our adapters(JMS, MAIL), I don't see where we ever set a timout in the ExecutionContext.  So we will never run into the but I'm getting ready to describe.


The ExecutionContext, is required to express the timeout in seconds(not milliseconds).  http://java.sun.com/j2ee/1.4/docs/api/javax/resource/spi/work/ExecutionContext.html

The org.jboss.resource.work.WorkWrapper(implements Task)  is the task that gets passed to the thread pool.  It implements getCompletionTimeout.  getCompletionTimeout on the task is in milliseconds.  You can see by the following method we pass the executionContext.getTransactionTimeout() as the completion time for the task.  So we go from seconds to milliseconds.

public long getCompletionTimeout()
   {
      return executionContext.getTransactionTimeout();
   }

This means that if you initially have a timeout as 6 seconds, it will be passed to the thread pool as 6 milliseconds.

to move further down the stack(skipping a few layers ), you can see that in BasicThreadPool, you can see that we pass the timeout into the runTaskWrapper method, which constructs the TimeoutInfo Object.


long completionTimeout = wrapper.getTaskCompletionTimeout();
      TimeoutInfo info = null;
      if( completionTimeout > 0 )
      {
         checkTimeoutMonitor();
         // Install the task in the
         info = new TimeoutInfo(wrapper, completionTimeout);
         tasksWithTimeouts.insert(info);
      }

then in the TimeoutInfo constructor we set the timout time in milliseconds...

TimeoutInfo(TaskWrapper wrapper, long timeout)
      {
         this.start = System.currentTimeMillis();
         this.timeoutMS = start + timeout;
         this.wrapper = wrapper;
      }


What we should do to fix this is inside the org.jboss.resource.work.WorkWrapper

public long getCompletionTimeout()
   {
      //get completionTimout on the task is in milliseconds.  We need to convert.
      return executionContext.getTransactionTimeout()*1000;
   }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira