Is it reasonable to take15-30 minutes to refresh Pending Changes view?
My client complained that it takes a long time to refresh the Pending Changes view in RTC 5.0.1 client. It usually takes 15-30 minutes. Is it reasonable? Any way to improve it?
Some streams can contain 200K files with size of 2GB in total. Anybody has similar experience in a real environment?
I found this post and it seems that some users did have similar issues in the past.
https://jazz.net/forum/questions/95786/can-we-disable-auto-refresh-in-pending-changes-view-when-login-rtc-repository
Some streams can contain 200K files with size of 2GB in total. Anybody has similar experience in a real environment?
I found this post and it seems that some users did have similar issues in the past.
https://jazz.net/forum/questions/95786/can-we-disable-auto-refresh-in-pending-changes-view-when-login-rtc-repository
One answer
If they are refreshing their Pending Changes view because they have updated some files directly on disk, instead of doing so via Eclipse, and they know in which file or folder the changes have been made, then it would be much faster to refresh just that file/folder, rather than refreshing the entire Pending Changes view.
Comments
Thanks Geoffrey. It can be a good workaround for the client. I will ask them to give it a try.
I think that is NOT an acceptable work around. put the work on the customer..
Obviously it would be best if the command just ran faster with no user guidance, but until a way is discovered to make that happen, it is useful to know about potential ways to work around the problem. In particular, if you happen to know which file was changed (or what folder the changed files are under), then refreshing that file or folder will be significantly better than refreshing the entire Pending Changes view.
Comments
Arun K Sriramaiah
Jan 08 '16, 9:45 a.m.Hi Donald,
I think its taking too much time, it is bit higher side.
1) Could you please check the Client Resources and also check is it same on the server for other clients as well.
2) Run the metronome and verify which one is getting more response time.
Regards,
Arun.
sam detweiler
Jan 10 '16, 12:49 p.m.what is the network topology between the client and the server?
As I recall. Pending changes uses file compare, so it has to construct the last version at the server, then send it to the client to compare.. 1 file/change object at a time.
If your clients are connected over a WAN link, this could explain the issue.
long ago at my prior job, I proposed a squid server proxy caching model to get those calculated file versions near the client users, at LAN speeds. There is no tuning capability at the client to do any of this.
Donald Nong
Jan 10 '16, 6:51 p.m.It appears that the hard word cannot be avoided then. I will work with the client to do a proper analysis and find out what's wrong.