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