TC7.51 hangs for ~90 seconds when access script files.
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-18-2010
07:32 AM
01-18-2010
07:32 AM
TC7.51 hangs for ~90 seconds when access script files.
Hello,
I just upgraded a project from TC6.5 to TC7.51. Whenever I access a script file TC hangs for well over 1 minute. I am opening files over the network using network suites.
I ran process monitor to see what was happening. 100% of the time the blocking is at the same place on the same Events.tcax file. regardless of which script file I am trying to open.
I have attached a copy of the process monitor results. This is a major productivity killer for me. Any help is appreciated.
Thanks!
I just upgraded a project from TC6.5 to TC7.51. Whenever I access a script file TC hangs for well over 1 minute. I am opening files over the network using network suites.
I ran process monitor to see what was happening. 100% of the time the blocking is at the same place on the same Events.tcax file. regardless of which script file I am trying to open.
I have attached a copy of the process monitor results. This is a major productivity killer for me. Any help is appreciated.
Thanks!
4 REPLIES 4
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-18-2010
08:23 AM
01-18-2010
08:23 AM
I removed a project to track the behavior. It appears the NotifiyChangeDirectory operation stops completing quickly after about 32 calls. The specific file/directory appears to be irrelevant. I am access files from a share on a system running Vista.
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2010
12:55 AM
01-19-2010
12:55 AM
I copied the entire project to a Windows 2003 server. Now I can open a script file with a delay of about 15 seconds. If I turn off process monitor the a script file opens in about 5 seconds.
Process Monitor shows 50 successful NotifyChangeDirectory requests followed by 10 more that return "Too Many Commands". All of the requests complete very quickly. None of the file access requests hang. The time to open a file is purely related to the size of the project and how many requests are issued. The OS that I access the files from is clearly part of the issue.
I did not have this problem using TC6.x
Process Monitor shows 50 successful NotifyChangeDirectory requests followed by 10 more that return "Too Many Commands". All of the requests complete very quickly. None of the file access requests hang. The time to open a file is purely related to the size of the project and how many requests are issued. The OS that I access the files from is clearly part of the issue.
I did not have this problem using TC6.x
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-19-2010
01:01 AM
01-19-2010
01:01 AM
I found a backedup version of my project that is still based on TC6.53.
I reran the test of opening the project using TC6.53 and access script files. In TC6.53 there are no NotifyChangeDirectory requests issued. Nor is the entire project reloaded every time I open a script file. In TC7.51 you clearly see the entire project tree get reloaded or at least reviewed every time you open a script file.
AutomatedQA Dev, Is there a switch that will revert the file change logic to the older, more effiecent way? The current model does not work for large projects suits.
I reran the test of opening the project using TC6.53 and access script files. In TC6.53 there are no NotifyChangeDirectory requests issued. Nor is the entire project reloaded every time I open a script file. In TC7.51 you clearly see the entire project tree get reloaded or at least reviewed every time you open a script file.
AutomatedQA Dev, Is there a switch that will revert the file change logic to the older, more effiecent way? The current model does not work for large projects suits.
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-21-2010
08:06 PM
01-21-2010
08:06 PM
Hello Brian,
Let us work on the problem in the M0068418 Support case you have recently opened.
-----
Alexander
Customer Care Manager
Alexander
Customer Care Manager
