It's all about the answers!

Ask a question

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


Aaron LaBella (5143) | asked Dec 03 '09, 6:57 p.m.
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

3 answers



permanent link
Cindy Luk (1311) | answered Sep 19 '12, 4:37 p.m.
I have also just encountered this same situation.  Did you find a resolution?

Comments
Aaron LaBella commented Sep 19 '12, 8:22 p.m.

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


permanent link
Aaron LaBella (5143) | answered Dec 04 '09, 4:25 p.m.
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

permanent link
Patrick Streule (4.9k21) | answered Dec 04 '09, 3:38 p.m.
JAZZ DEVELOPER
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

Your answer


Register or to post your answer.