Community
Participate
Working Groups
When the saving profile job is going on, sometimes the context menu takes a while to appear. Steps to Reproduce: 0. Create a new connection. 1. Right click on Local and select Properties. 2. Click Okay. A Saving Profile job will start shortly. 3. Right click on any subsystem of the new connection you created while the saving profile job is going. --> Context menu will take a few seconds to pop up. On one of our slow machines it takes 30 seconds. After it pops up a few seconds later the saving job is happening again. Another way to reproduce: 1. Create a new connection. 2. When the saving profile job is running right click on the Files subsystem of that new connection.
I tried reproducing with just RSE and couldn't, but if I installed user actions and loaded them up first the saving profile job took long enough to see the problem.
Do you see any entries in the error log? If the delay is caused by a deadlock due to bundle activation for bringing up the context menu (causing a 5 second wait), it should show up in the error log. As I have repeatedly said, I think that the "saving profile" job itself may be part of the problem. We don't have such vast amounts of data to save that it would justify to take even a second to save. Yet I observe the "saving profile" running much longer at times. I think that a separate bug is open for that. 30 seconds wait time for a context menu to pop up is clearly unacceptable from a product perspective. A thread dump during that 30 second wait time should be helpful. Given that you likely cannot switch UI focus while the context menu waits for popping up, you'll likely have to create that thread dump from a different machine. On Linux, this is quite easy (log in from a different machine and send a kill -QUIT signal to the Eclipse process that you want the thread dump from. On Windows, you'll either need (a) some way to log in remotely (with a separate Windows dstore daemon and RSE for instance; then if you use JDK 1.6 you can use jps / jstack to get the Thread dump, or (b) Start Eclipse with -vmargs -Xdebug and perform remote debugging [1] [1] For more information on getting a Thread Dump from a remote machine, see http://wiki.eclipse.org/How_to_report_a_deadlock#Remote_Diagnosis
(In reply to comment #2) > Do you see any entries in the error log? If the delay is caused by a deadlock > due to bundle activation for bringing up the context menu (causing a 5 second > wait), it should show up in the error log. Nothing shows up in the Error Log. > As I have repeatedly said, I think that the "saving profile" job itself may be > part of the problem. We don't have such vast amounts of data to save that it > would justify to take even a second to save. Yet I observe the "saving profile" > running much longer at times. I think that a separate bug is open for that. I agree. Bugs Open: Bug 197043, Bug 243919, Bug 244172 > 30 seconds wait time for a context menu to pop up is clearly unacceptable from > a product perspective. A thread dump during that 30 second wait time should be > helpful. Given that you likely cannot switch UI focus while the context menu > waits for popping up, you'll likely have to create that thread dump from a > different machine. > > On Linux, this is quite easy (log in from a different machine and send a > kill -QUIT > signal to the Eclipse process that you want the thread dump from. On Windows, > you'll either need > (a) some way to log in remotely (with a separate Windows dstore daemon and RSE > for instance; then if you use JDK 1.6 you can use jps / jstack to get the > Thread dump, or > (b) Start Eclipse with -vmargs -Xdebug and perform remote debugging [1] > > [1] For more information on getting a Thread Dump from a remote machine, see > http://wiki.eclipse.org/How_to_report_a_deadlock#Remote_Diagnosis > Don't have access to a Linux machine. Will see if I can figure out a way to do this for windows when I get some time.
On Windows, I recommend the "Remote Debug" approach, it's really easy to do: http://wiki.eclipse.org/How_to_report_a_deadlock#Remote_Debug_Connection # On target machine, launch eclipse -vmargs -Xdebug -Xnoagent -Djava.compiler=NONE \ -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 # On debug machine, launch Eclipse, create a new Debug Launch of type "Remote Java Application" and enter the hostname / port number (5005)
I believe the problem is due to the number of files being written for profiles that contain compile commands. There are a large number of definitions, each one written as a separate property set. Furthermore the tree is fairly deep due to the use of nesting in the property sets. The best way to handle this is to merge the profile into its persistent form rather than rewriting it in its entirety. In addition we should be recognizing exactly which files need to be rewritten. The beginnings of such merge support are in the DOM handling classes, but merging is difficult and should be done with care. There could also be hints added to property sets that can indicate where the file boundaries should be. The DOM reader and writer are capable of nesting nodes either in a single file or as separate files in a directory structure. We make assumptions about this in the non-property-set nodes of the profile and thus make a trade-off between the number of files written and the volatility of each file.
Dave did you run a profiler to verify your assumption? I've been told that YourKit is good and simple to use: http://www.yourkit.com/
Since this seems to be a profile writing issue, I'm reassigning to Dave D.
(In reply to comment #6) > Dave did you run a profiler to verify your assumption? I've been told that > YourKit is good and simple to use: http://www.yourkit.com/ > No, but I've seen the problem. The is a *lot* of disk activity when using compile command definitions. The property sets in one of my profiles takes 600 files and 600 folders to write. It's clearly a data-to-file allocation problem.
Gosh. 600 files and folders is evil. I daresay there is a flaw in the way the data is partitioned...
Fixed by making nested property sets and properties embedded nodes in the persistent form. This change is completely backward and forward compatible since the persistent form can be written and read by the current support in either scheme. This fix drastically reduces the number of files written for a profile that uses property sets such as those defining compile commands and user defined actions.
Can we backport this fix? The difference with and without this is huge. Thanks Dave!!
(In reply to comment #11) > Can we backport this fix? The difference with and without this is huge. > Thanks Dave!! > I certainly plan on this. The fix is very self-contained and repairs existing profiles as well.
Bug 254842 now tracks this important backport.
CQ:WIND00146302
Diff for the fix is here: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.rse/plugins/org.eclipse.rse.core/src/org/eclipse/rse/internal/persistence/PropertyFileProvider.java?root=DSDP_Project&r1=1.11&r2=1.12
