Community
Participate
Working Groups
Window > Show View > Other > General > Progress Select a file under Local : My Home, Copy Select a folder under FTP : My Home, Paste The Progress view first shows a Job for uploading the file, and then a job "Saving RSE Profile". There should be no need for saving the profile just because of an upload operation. Saving a profile is a relatively heavy-weight operation, so it should be avoided if possible. -----------Enter bugs above this line----------- TM 2.0.1 Testing installation : eclipse-SDK-3.3-linux-gtk-x86_64, emf-sdo-xsd-SDK-2.3.0 Download RSE-2.0.1RC1: RSE-SDK,examples,tests,discovery,terminal java.runtime : Sun 1.5.0_12-b04 64-bit Server VM, mixed mode os.name: : OpenSUSE 10.2 64-bit uname : Linux osgiliath 2.6.18.8-0.5-default x86_64 GNU/Linux ------------------------------------------------ systemtype : Linux-local / FTP-only targetos : Solaris-sparc 5.9, Sun 1.4.2_05 targetuname : SunOS szg-anar 5.9 Generic_118558-06 sun4u sparc SUNW,Sun-Blade-1500 ------------------------------------------------
Dave's can you comment on this? - Most of our clients do uploads / downloads all the time, so we should really not save the profiles every time. Dbl clicking a file to edit it under an FTP connection also leads to "Saving Profile".
For some reason there are cases where the model is touched and marked dirty during normal operations that haven't actually changed the model. When this happens, the profile is marked dirty and a write of the profile is scheduled. I suspect that this is what is happening here. Sometimes this is easy to fix, sometimes not, but the cases should be tracked down and dealt with.
Yes, I agree that this certainly isn't what we want to happen. We'll need figure out where the unnecessary dirty marking takes place.
The reason we see this job is because of setting the encoding. FileServiceSubSystem.getRemoteEncoding() tries to get a default encoding preference set locally. Doesn't find one so it gets the remote encoding and then sets the hosts default remote encoding to what it found. This always causes a save. No matter if it's the same encoding that is already saved! We need to make sure we aren't doing a commit of a profile when the encoding hasn't changed. New connections don't have an encoding persisted, so when opening a file for the first time it will cause a save job, but after that we shouldn't see any unless the encoding changes.
Created attachment 78437 [details] Only do a commit if encoding has changed This patch will make sure we only do a commit when we change the encoding. Therefore opening a file for the first time will still do a save because the encoding is not persisted yet. Future operations won't cause the save job if the encoding doesn't change. Legal Message: I, Kevin Doyle, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
Patch looks good to me, Dave can you commit this for 2.0.1 or should I?
Patch looks fine to me too. I'll commit this.
I've applied the patch and committed to cvs.
