Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Can someone assist in debugging a RejectedExecutionException thrown by IProcessClientService.findProcessArea?

We have a Java application that is concurrently accessing two RTC project areas.  After upgrading to RTC 4.0.1, we encounter a java.util.concurrent.RejectedExecutionException in a call to IProcessClientService.findProcessArea:
   protected IProjectArea toProjectArea( String projectAreaName,
         ITeamRepository repository )
         throws TeamRepositoryException, UnsupportedOperationException
   {
      IProcessClientService processClient = (IProcessClientService)repository
            .getClientLibrary( IProcessClientService.class );
      URI uri = URI.create( projectAreaName.replaceAll( " ", "%20" ) );
      IProjectArea projArea = (IProjectArea)processClient.findProcessArea(
            uri, null, null );
      if (projArea == null)
      {
         throw new UnsupportedOperationException( "Project area '"
               + projectAreaName + "' not found." );
      }
      return (projArea);
   }
RejectedExecutionException is not listed as a possible exception in IProcessClientService.findProcessArea's Javadoc (from the RTC 4.0.1 SDK source code) .

Note that the same scenario worked just fine with RTC 4.0.  Here's is the full stack trace:
java.lang.UnsupportedOperationException: java.lang.UnsupportedOperationException: Failed to create/update work item
    at com.ibm.ArtifactTechnology.ABS.ArtifactBroker.ArtifactBroker.performAction(ArtifactBroker.java:821)
    at com.ibm.ArtifactTechnology.ABS.ArtifactBroker.ArtifactBroker.broker(ArtifactBroker.java:702)
    at com.ibm.ArtifactTechnology.ABS.ArtifactBridge.ArtifactBridge.broker(ArtifactBridge.java:463)
    at com.ibm.ArtifactTechnology.ABS.ArtifactBridge.ArtifactBridge.bridge(ArtifactBridge.java:384)
    at com.ibm.ArtifactTechnology.ABS.ArtifactBridge.ArtifactBridge.bridge(ArtifactBridge.java:553)
    at com.ibm.ArtifactTechnology.ABS.ArtifactBridge.AbstractArtifactBridge.processInboxArtifacts(AbstractArtifactBridge.java:95)
    at com.ibm.ArtifactTechnology.ABS.common.AbstractABSComponent$InboxProcessor.run(AbstractABSComponent.java:796)
Caused by: java.lang.UnsupportedOperationException: Failed to create/update work item
    at com.ibm.ArtifactTechnology.ABS.performers.RTC.UpdateAction.processArtifact(UpdateAction.java:99)
    at com.ibm.ArtifactTechnology.ABS.performers.RTC.UpdateAction.performAction(UpdateAction.java:61)
    at com.ibm.ArtifactTechnology.ABS.ArtifactBroker.performers.common.ActionPerformerBase.performAction(ActionPerformerBase.java:179)
    at com.ibm.ArtifactTechnology.ABS.ArtifactBroker.ArtifactBroker.performAction(ArtifactBroker.java:784)
    ... 6 more
Caused by: java.util.concurrent.RejectedExecutionException
    at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1779)
    at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:778)
    at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:669)
    at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.queue(EventSource.java:770)
    at com.ibm.team.repository.client.util.EventSource.sendEvents(EventSource.java:637)
    at com.ibm.team.repository.client.util.EventSource.release(EventSource.java:402)
    at com.ibm.team.repository.client.internal.ItemManager.applyItemUpdates(ItemManager.java:734)
    at com.ibm.team.repository.client.internal.ItemManager.applyItemUpdates(ItemManager.java:722)
    at com.ibm.team.process.internal.client.ProcessClientService.shareSingle(ProcessClientService.java:923)
    at com.ibm.team.process.internal.client.ProcessClientService.findProcessArea(ProcessClientService.java:794)
    at com.ibm.ArtifactTechnology.ABS.performers.RTC.RTCActionPerformerBase.toProjectArea(RTCActionPerformerBase.java:321)
    at com.ibm.ArtifactTechnology.ABS.performers.RTC.RTCActionPerformerBase.setProjectArea(RTCActionPerformerBase.java:263)
    at com.ibm.ArtifactTechnology.ABS.performers.RTC.RTCActionPerformerBase.setupAndLogin(RTCActionPerformerBase.java:186)
    at com.ibm.ArtifactTechnology.ABS.performers.RTC.UpdateAction.createWorkItem(UpdateAction.java:111)
    at com.ibm.ArtifactTechnology.ABS.performers.RTC.UpdateAction.processArtifact(UpdateAction.java:91)
    ... 9 more
Does anyone know the cause of the RejectedExecutionException?  Does it indication an RTC bug?  Or does it indicate a problem with our code?

0 votes



3 answers

Permanent link
Javadoc for RuntimeExecutionException indicates that there may be a "message" field in the exception to assist with problem determination.  Have you looked at that value to see if it gives any clues?

My only thought here is that .getClientLibrary() method is refusing to run because it is being invoked within a thread where the required function cannot be run at the time of the call.

Could there be some subtle timing issue between the concurrent access threads in the application?  Can you serialize the access in the application to see if this avoids the problem?

0 votes

Comments

There's no message in the RejectedExecutionException as any message would have been included in the stack trace.

I'm not sure how easy it would be serialize RTC access in our Java application.  And I'd we'd need to consider the performance impact of changing from concurrent RTC access to serialized RTC access.  So, I'd like to avoid that if at all possible.


Permanent link
Is the problem consistently reproducible? From the stack trace, it looks like a low-level problem between com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher and the ThreadPoolExecutor from the JVM.

I've never seen this before, but the JavaDoc on ThreadPoolExecutor#execute says: "Executes the given task sometime in the future. The task may execute in a new thread or in an existing pooled thread. If the task cannot be submitted for execution, either because this executor has been shutdown or because its capacity has been reached, the task is handled by the current RejectedExecutionHandler .". Here's the reference: http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#execute%28java.lang.Runnable%29

So maybe you're just running out of threads.

0 votes

Comments

I'm able to reproduce the problem in my development environment.  While the RejectedExecutionException occurs frequently, it doesn't occur every time.  I'm still investigating to see if there's some commonality when the exception occurs.

I've looked at the Javadoc for ThreadPoolExecutor.  It looks as though the exact reason for a task to be rejected by ThreadPoolExecutor.execute and how the rejection is handled depends on how the ThreadPoolExecutor instance is created and configured.  Since the RTC code creates the ThreadPoolExecutor instance and since RejectedExecutionException is not listed as a possible exception in IProcessClientService.findProcessArea's Javadoc, I would say that the RTC use of ThreadPoolExecutor is internal RTC implementation, and thus that it's responsibility of the RTC code handle the RejectedExecutionException.

One thing to note is that we only starting encountering this problem with RTC 4.0.1; we haven't seen it on either RTC 4.0 or RTC 3.0.x.  Did the RTC implementation of IProcessClientService.findProcessArea perhaps change between RTC 4.0 and 4.0.1?

Yes, you certainly shouldn't have to handle RejectedExecutionException. I'm not sure why you're seeing this with the findProcessArea method. There's nothing special about that method at all, it's just fetching items from the server and sharing them with the ItemManager like many other methods.

I don't think you're looking at problem with "findProcessArea". I think you're looking at an issue with the ThreadPoolExecutor.

Also, my test scenario only accesses two RTC project areas, so I doubt our application is running out of threads.  Is there additional debug information I can collect, such as the maximum number of threads, number of threads in use, and so on, that might be helpful in determining the cause of the RejectedExecutionException?

Yes, I agree that the issue is with ThreadPoolExecutor.  The reason I mentioned findProcessArea is that this is the RTC method that our application calls that fails with the RejectedExecutionException.  From the stack trace, it appears that findProcessArea is (indirectly) using ThreadPoolExecutor.


Permanent link
I have a web service written with RTC SDK. If I got an exception and try to execute the web service once again I encounter this error.

It happens during a fetch for an invalid user. If RTC cannot find this user it throws TeamRepositoryException. After a second time this error occurs. Do I have a chance to validate the user without having an eception???

0 votes

Comments

You don't say what version of RTC you're running.  My problem was fixed under Defect 250057 RejectedExecutionException thrown by IProcessClientService.findProcessArea in RTC 4.0.5.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,930

Question asked: Jan 31 '13, 10:18 a.m.

Question was seen: 9,575 times

Last updated: Apr 02 '14, 11:50 a.m.

Confirmation Cancel Confirm