Community
Participate
Working Groups
Created attachment 171923 [details] dstore trace and stack trace This is a problem reported on RSE 3.0.3.x. Our product provides a source look up container for the debugger. It contains a list of filter strings. When the debugger asks for the source, the container asks RSE to resolve the filters it has and goes through them to find the matching file. This source look up works fine and we are unable to reproduce the problem as the customer. The stack trace and RSE host trace were collected and attached.
One observation I've made with the stacktrace is that you're doing RSE queries on the main thread: Thread[main,6,main] java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:196) org.eclipse.rse.services.dstore.util.DStoreStatusMonitor.waitForUpdate(DStoreStatusMonitor.java:373) org.eclipse.rse.services.dstore.util.DStoreStatusMonitor.waitForUpdate(DStoreStatusMonitor.java:288) org.eclipse.rse.services.dstore.util.DStoreStatusMonitor.waitForUpdate(DStoreStatusMonitor.java:236) org.eclipse.rse.services.dstore.AbstractDStoreService.dsQueryCommand(AbstractDStoreService.java:127) org.eclipse.rse.internal.services.dstore.files.DStoreFileService.fetch(DStoreFileService.java:2114) org.eclipse.rse.internal.services.dstore.files.DStoreFileService.list(DStoreFileService.java:1975) org.eclipse.rse.subsystems.files.core.servicesubsystem.FileServiceSubSystem.internalList(FileServiceSubSystem.java:375) org.eclipse.rse.subsystems.files.core.servicesubsystem.FileServiceSubSystem.list(FileServiceSubSystem.java:567) org.eclipse.rse.subsystems.files.core.subsystems.RemoteFileSubSystem.list(RemoteFileSubSystem.java:975) com.ibm.tpf.connectionmgr.core.IRemoteFileBaseItem.listMatchingFiles(IRemoteFileBaseItem.java:2551) com.ibm.tpf.connectionmgr.core.ConnectionManager.getFilesAndFolders(ConnectionManager.java:184) com.ibm.tpf.connectionmgr.core.ConnectionManagerHelper.getFilesAndFolders(ConnectionManagerHelper.java:2744) com.ibm.tpf.connectionmgr.core.ConnectionManagerHelper.getFilesAndFoldersAsyn(ConnectionManagerHelper.java:2831) com.ibm.tpf.connectionmgr.core.ConnectionManager.getMatchingFilesAndFolders Is it not possible to do this query on a worker thread?
The change has already made to move the source look up to the non-GUI thread. It will be in our next release. The customer hasn't got it yet.
Hi Dave, We ran into this nudge problem with DStoreStatusMonitor and DownloadListener a few times now. And it took much time to collect data, investigate problem and provide fix. I wonder whether it's possible to do a bit more investigation on this data transfer mechanism and come up with a solution which can address the root cause.
(In reply to comment #3) > Hi Dave, > We ran into this nudge problem with DStoreStatusMonitor and DownloadListener a > few times now. And it took much time to collect data, investigate problem and > provide fix. I wonder whether it's possible to do a bit more investigation on > this data transfer mechanism and come up with a solution which can address the > root cause. Hi Samuel, It's possible that the following would fix this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=328060 Have you tried with a driver that has that fix?
Hi Dave, We usually cannot reproduce these problems and the customers may not even reproduce the problem at will. As I said in comment 3, I'm hoping this can be investigated not as an individual case but as a solution t address the root cause.
(In reply to comment #5) > Hi Dave, > We usually cannot reproduce these problems and the customers may not even > reproduce the problem at will. As I said in comment 3, I'm hoping this can be > investigated not as an individual case but as a solution t address the root > cause. Well, my point is that bug 328060 may be the root cause since it seems to have been the cause of a similar hang in other cases.
It's really good news. We've sent dstore_core.jar from bug 328060 to a customer. Hope the problem will be gone.
(In reply to comment #7) > It's really good news. We've sent dstore_core.jar from bug 328060 to a > customer. Hope the problem will be gone. I don't know whether it's the same problem but so far it's the only explanation we have for a command that seems to get lost on the server. Hopefully this is it.
