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

com.ibm.team.repository.client.util.ThreadCheck checkLongOps

I'm really stuck on this issue ... I've investigated the forums, and the closest thing to what I'm doing and what others have encountered is this:

http://jazz.net/forums/viewtopic.php?t=4718&highlight=checklongopsallowed

My application is a simple swing application, and all I'm doing is setting the workflow action and saving the workitem working copy. If I update timeSpent at the same time, the stack trace doesn't show up ... its only when I update *only* the workflow action. My original code was running in a completely separate Thread, and I've also tried moving the code to a class that extends org.eclipse.core.runtime.jobs.Job. I don't understand whats happening. Can't I just tell the workitem guy to not notify/update the cache on the save, since that appears to be the source of the issue according to the stack:

Dec 3, 2009 6:50:36 PM com.ibm.team.repository.client.util.ThreadCheck checkLongOpsAllowed
SEVERE: Long-running operations prohibited on this thread
java.lang.IllegalStateException: Long-running operations prohibited on this thread
at com.ibm.team.repository.client.util.ThreadCheck.checkLongOpsAllowed(ThreadCheck.java:117)
at com.ibm.team.repository.client.internal.ServiceInterfaceProxy.invoke(ServiceInterfaceProxy.java:81)
at $Proxy1.queryItemsInContext(Unknown Source)
at com.ibm.team.workitem.common.internal.AuditableCommon$1.run(AuditableCommon.java:90)
at com.ibm.team.workitem.common.internal.AuditableCommon$1.run(AuditableCommon.java:1)
at com.ibm.team.workitem.client.internal.ClientServiceContext$1.run(ClientServiceContext.java:41)
at com.ibm.team.repository.client.internal.TeamRepository$3.run(TeamRepository.java:1169)
at com.ibm.team.repository.common.transport.CancelableCaller.call(CancelableCaller.java:79)
at com.ibm.team.repository.client.internal.TeamRepository.callCancelableService(TeamRepository.java:1162)
at com.ibm.team.workitem.client.internal.ClientServiceContext.callCancelableService(ClientServiceContext.java:45)
at com.ibm.team.workitem.common.internal.AuditableCommon.queryItemsInContext(AuditableCommon.java:93)
at com.ibm.team.workitem.common.internal.util.ItemQueryIterator.update(ItemQueryIterator.java:78)
at com.ibm.team.workitem.common.internal.util.ItemQueryIterator.hasNext(ItemQueryIterator.java:58)
at com.ibm.team.workitem.common.internal.util.QueryIterator.toList(QueryIterator.java:26)
at com.ibm.team.workitem.common.internal.AttributeCache.updateCache(AttributeCache.java:68)
at com.ibm.team.workitem.common.internal.util.CacheHelper.internalCheckCache(CacheHelper.java:107)
at com.ibm.team.workitem.common.internal.util.CacheHelper.checkCache(CacheHelper.java:64)
at com.ibm.team.workitem.common.internal.util.CacheHelper.checkCache(CacheHelper.java:55)
at com.ibm.team.workitem.common.internal.AttributeCache.findAttributes(AttributeCache.java:58)
at com.ibm.team.workitem.common.internal.AttributeCache.findAttribute(AttributeCache.java:40)
at com.ibm.team.workitem.common.internal.WorkItemCommon.findAttribute(WorkItemCommon.java:306)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry$InternalListener.featureChanged(WorkItemWorkingCopyRegistry
at com.ibm.team.workitem.common.internal.util.EMFListener.notifyChanged(EMFListener.java:36)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:247)
at com.ibm.team.workitem.common.internal.model.impl.WorkItemImpl.setInternalState(WorkItemImpl.java:1001)
at com.ibm.team.workitem.common.internal.model.impl.WorkItemImpl.eSet(WorkItemImpl.java:2380)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:1071)
at com.ibm.team.workitem.common.internal.util.EMFHelper.merge(EMFHelper.java:117)
at com.ibm.team.workitem.common.internal.util.EMFHelper.merge(EMFHelper.java:70)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.remoteUpdate(WorkItemWorkingCopyRegistry.java:870)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.access$14(WorkItemWorkingCopyRegistry.java:846)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry$8.run(WorkItemWorkingCopyRegistry.java:1781)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry$8.run(WorkItemWorkingCopyRegistry.java:1)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyImpl$1.run(WorkItemWorkingCopyImpl.java:421)
at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:173)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyImpl.run(WorkItemWorkingCopyImpl.java:415)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyImpl.write(WorkItemWorkingCopyImpl.java:410)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.saveWorkItems(WorkItemWorkingCopyRegistry.java:1779)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.saveAffected(WorkItemWorkingCopyRegistry.java:1658)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.save(WorkItemWorkingCopyRegistry.java:1559)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyRegistry.save(WorkItemWorkingCopyRegistry.java:1530)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyManager.save(WorkItemWorkingCopyManager.java:115)
at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyImpl.save(WorkItemWorkingCopyImpl.java:228)
at com.ibm.mmthis.gui.rtc.RTC.updateWorkItemsById(RTC.java:924)
at com.ibm.mmthis.gui.threads.RTCUpdateJob.run(RTCUpdateJob.java:125)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Any help/direction is of course greatly appreciated, since this one is driving me crazy.

Thanks!

Aaron

0 votes



3 answers

Permanent link
I'm really stuck on this issue ... I've investigated the forums, and
the closest thing to what I'm doing and what others have encountered
is this:

http://jazz.net/forums/viewtopic.php?t=4718&highlight=checklongopsallowed

My application is a simple swing application, and all I'm doing is
setting the workflow action and saving the workitem working copy. If
I update timeSpent at the same time, the stack trace doesn't show up
.. its only when I update *only* the workflow action. My original
code was running in a completely separate Thread, and I've also tried
moving the code to a class that extends
org.eclipse.core.runtime.jobs.Job. I don't understand whats
happening. Can't I just tell the workitem guy to not notify/update
the cache on the save, since that appears to be the source of the
issue according to the stack:

That's strange. The intention of the thread check is to prevent blocking
operations to run in the UI thread.

But you said that you invoke the save in a background thread, so this
check shouldn't be triggered. The threads to be checked have to be
'marked' explicitly using ThreadCheck.prohibitLongOps(). You could set a
breakpoint there to figure out where the call originates and which
thread is involved.

--
Regards,
Patrick
Jazz Work Item Team

0 votes


Permanent link
I'm really stuck on this issue ... I've investigated the forums, and
the closest thing to what I'm doing and what others have encountered
is this:

http://jazz.net/forums/viewtopic.php?t=4718&highlight=checklongopsallowed

My application is a simple swing application, and all I'm doing is
setting the workflow action and saving the workitem working copy. If
I update timeSpent at the same time, the stack trace doesn't show up
.. its only when I update *only* the workflow action. My original
code was running in a completely separate Thread, and I've also tried
moving the code to a class that extends
org.eclipse.core.runtime.jobs.Job. I don't understand whats
happening. Can't I just tell the workitem guy to not notify/update
the cache on the save, since that appears to be the source of the
issue according to the stack:

That's strange. The intention of the thread check is to prevent blocking
operations to run in the UI thread.

But you said that you invoke the save in a background thread, so this
check shouldn't be triggered. The threads to be checked have to be
'marked' explicitly using ThreadCheck.prohibitLongOps(). You could set a
breakpoint there to figure out where the call originates and which
thread is involved.

--
Regards,
Patrick
Jazz Work Item Team

Patrick,

I'll try setting a breakpoint to see if I can gather any more information. Without really seeing any source code, I'm guessing its a combination of this line in the stack:

at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:173)

combined with perhaps a bug in ThreadCheck checkLongOpsAllowed.

Any way you could divulge the source for checkLongOpsAllowed and we can see why it thinks my completely separate Thread and Job are UI threads?

Maybe there could be a way to tell the work item working copy manager that I really am a safe Thread, so, just run normally ;-)

at com.ibm.team.workitem.client.internal.WorkItemWorkingCopyImpl.run(WorkItemWorkingCopyImpl.java:415)

Thanks again for the help and direction ... a lot of this is complicated by the fact that I don't have any javadocs or any source :-D

Aaron

0 votes


Permanent link
I have also just encountered this same situation.  Did you find a resolution?

0 votes

Comments

No, I never found a solution ... the stack still appears I think, but, it seems to work fine.

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,937

Question asked: Dec 03 '09, 6:57 p.m.

Question was seen: 6,947 times

Last updated: Sep 19 '12, 8:22 p.m.

Confirmation Cancel Confirm