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 |
3 answers
I'm really stuck on this issue ... I've investigated the forums, and 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 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 |
