It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×10,826
×1

question asked: Jan 31 '13, 10:18 a.m.
question was seen: 8,894 times
last updated: Apr 02 '14, 11:50 a.m.

Related questions

FAQ - How this Forum works

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

0
Geoff Alexander (196●2●39●48) | asked Jan 31 '13, 10:18 a.m.
edited Jan 31 '13, 2:15 p.m. by Jared Burns (4.5k●2●9)
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?

3 answers

Most liked answers|Newest answers|Oldest answers ↑

0
permanent link
Tim Hahn (51●1) | answered Jan 31 '13, 1:47 p.m.
JAZZ DEVELOPER
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?

Comments
Geoff Alexander commented Jan 31 '13, 4:05 p.m.

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.

0
permanent link
Jared Burns (4.5k●2●9) | answered Jan 31 '13, 2:03 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
Comments
Geoff Alexander commented Jan 31 '13, 4:54 p.m. | edited Jan 31 '13, 4:58 p.m.

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?

Jared Burns commented Jan 31 '13, 5:01 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.

Geoff Alexander commented Jan 31 '13, 5:03 p.m. | edited Jan 31 '13, 5:05 p.m.

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?

Geoff Alexander commented Jan 31 '13, 5:54 p.m. | edited Jan 31 '13, 5:54 p.m.

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.

0
permanent link
Canberk Akduygu (992●3●73●71) | answered Apr 02 '14, 10:33 a.m.
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???
Comments
Geoff Alexander commented Apr 02 '14, 11:50 a.m.

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 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.