This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
After checking in or out a multi-file dataObject, a refresh command and a list command get executed for each file associated with the dataObject. This causes multiple redundant fileChanged events to be fired on the same file. In addition, it breaks our refresh logic in the J2EE modules. Another thing, is there anyway to prevent multiple refresh commands to be issued simultaneous on the same folder? For example, the user can tie the refresh command to a key stroke and rapidly press the key stroke multiple times. If the timing is right, we can run into the same problem.
There is assured, that next refresh is not executed if one refresh is already running on the same directory. This does not seem like to correct approach, because there's an exactly opposite bug (not submitted in Issuezilla yet), that refresh is not executed; which is caused by this behavior. What is needed seems like one refresh after all commands are processed. This would solve both problems. I dont't think we can solve the problem when a user "rapidly press the key stroke multiple times". The current behavior (next refresh is not executed if one refresh is already running) is a good solution for this problem IMHO. Moreover typical user will not associate a key stroke with Refresh (AFAIK it's not even possible).
The problem is hopefully fixed in the main trunk: /cvs/vcscore/src/org/netbeans/modules/vcscore/commands/CommandExecutorSupport.java,v <-- CommandExecutorSupport.java new revision: 1.57; previous revision: 1.56 Checking in VcsCache.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java,v <-- VcsCache.java new revision: 1.59; previous revision: 1.58 done Checking in VcsFSCache.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/caching/VcsFSCache.java,v <-- VcsFSCache.java new revision: 1.39; previous revision: 1.38 done When a refresh is to be run after a command finish, the refresh is not executed immediately.The folders that are to be refreshed are collected first and then in case that no more commands after which the refresh is called are running, request for the refresh. When a refresh is requested, we check for whether the directory is already being loaded. If yes, the refresh is scheduled for later. If there are more refresh requests comming for the same directory, only one refresh is scheduled for the later time. After the directory becomes loaded, the scheduled refreshes are executed.
Created attachment 9990 [details] The contextual diff of the fix.
Created attachment 9992 [details] The binary patch. To apply, put into <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder.
There's one forgotten change, that is necessary for this fix: /cvs/vcscore/src/org/netbeans/modules/vcscore/commands/CommandProcessor.java,v <-- CommandProcessor.java new revision: 1.12; previous revision: 1.11
Created attachment 9994 [details] The updated contextual diff.
Created attachment 9995 [details] The updated binary patch. Use this instead of the previous one.
Would someone please verify this bug? If it will not be verified it will not be fixed in NetBeans 3.5 / S1S 5.0.
Okay, I will try to verify the fix today. However, can you Peter Liu please do the same ?
Sorry, I was unable to apply the patch thus can't confirm whether it's fixed. Peter please do it if you were successful.
> Sorry, I was unable to apply the patch thus can't confirm whether > it's fixed. Peter please do it if you were successful. The problem was, that the patch must go into the installation directory, not the user directory.
I just tried the patch against s1studio 5 and it solves the problem.
Okay, I am going to give it one more try ...
I will probably disappoint you guys but it seems that fix is still not sufficient. I have tried it only 4 times and in 2 attempts the bug occured. Thus I can't verify the fix, sorry. How many times did you try it Peter ? Development build #030417 of Sun ONE Studio 5.0 with the latest patch.
Oops, this relates to another bug. Please ignore my previous comment. I am rollbacking my action, sorry.
The fix of this issue is currently identical with the fix of issue #33132. Because it was found, that issue #33132 is still not fully fixed, I'm waiting with the integration of this into release35 till issue #33132 is fixed.
I've decided to start the process of integration of this into NB 3.5. I will not wait till issue #33132 is fixed. This patch seems to work O.K. and the problem in #33132 may not be related to this. So I've sent a mail to reviewers...
Reviewed without objections.
approved for 3.5
Thanks for the verification, review and approval. Fixed in the release35 branch: Checking in src/org/netbeans/modules/vcscore/caching/VcsCache.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/caching/VcsCache.java,v <-- VcsCache.java new revision: 1.56.2.3; previous revision: 1.56.2.2 done Checking in src/org/netbeans/modules/vcscore/caching/VcsFSCache.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/caching/VcsFSCache.java,v <-- VcsFSCache.java new revision: 1.38.2.1; previous revision: 1.38 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/vcscore/commands/CommandExecutorSupport.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/commands/CommandExecutorSupport.java,v <-- CommandExecutorSupport.java new revision: 1.56.2.1; previous revision: 1.56 done Checking in src/org/netbeans/modules/vcscore/commands/CommandProcessor.java; /shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/commands/CommandProcessor.java,v <-- CommandProcessor.java new revision: 1.8.2.3; previous revision: 1.8.2.2 done
Verified in Sun ONE Studio 5.0 Standard Edition build #030521. If you Peter disagree, don't hesitate to reopen the bug with further description.