Community
Participate
Working Groups
One particular project of mine usually takes about 3 minutes to synchronize after doing a complete clean-and-build. Since upgrading to Juno yesterday, It is taking more than 45 minutes (and counting). Just so you don't suspect that my CVS repository is responding slow, I started Helios up, created a new workspace, checked out this project, did a clean build, then did a synch...took only 3 minutes, all the while, Juno is still trying to synch the same project. Additional info: In Helios, during the synch, in the progress view I see a progress bar with the following text underneath: The user operation is waiting for background work to complete.: 1 operation remaining OK In Juno, during the synch, in the progress view I see the same first line, but under that it alternates between "Receiving file: XYZ.java" and "Authenticating using pserver". The 'Authenticating' message is on screen 5-10 times as long as the 'Receiving' message. Did something change in the authentication that makes it re-auth for each file?
One more note, the messages in the progress view are shown when the progress bar is at 79% complete.
I also have very similiar problem. In my investigation, slowness at team synchronizing via CVS mostly occured while JPA entity classes are synching. "Authenticating using pserver" message at progress detail screen can be seen almost for every JPA entity classes.
I also have this problem. I just want to specify that my projects don't use JPA so it is absolutely not JPA-related. IMHO this has to do with any big project. Progress bar @ 79%. IMHO the problem is that eclipse does not cache authentication.
Bug present also in Version 3.8
Also present in mac os x 64 bit (build id 20121004-1855)
It looks like no one is really pushing this and one of our customers with thousands of developers is seriously thinking of NOT USING Juno at all. They have projects with a lot of files to synchronize over CVS and because of the above mentioned bug, it takes sometimes hours to do that… (with eclipse 3.7.2 it works everything fine)
The message "Authenticating using pserver" is shown each time a pserver connection is opened. Thie message: > The user operation is waiting for background work to complete.: 1 operation remaining > OK suggests that the connection is opened by the background operation. Are there any more details about this remaining operation?
Thanks for investigating. The problem is not that "Authenticating using pserver" takes too long. The problem is that it looks like it is re-authenticate for every file in the scope (the entire project if it is syncing that, syncing just a folder takes proportionally less) 3 messages cycle: 1) "Authenticating using pserver" (2-3 seconds each time) 2) Receiving file: <name of the file> (dep. in the filesize, often unnoticeable) 3) Receiving server response (2-3 seconds each time) (goto 1 for another file) An interesting fact, is that the problem is present only the first time a project is syncronized in a work session. Restarting Eclipse makes the problem reappear. CVS View show no activity in this phase, Progress View is showing what described so far Hope this helps Alex
To be precise: An interesting fact, is that the problem is present only the first time a project is SUCCESFULLY syncronized in a work session That is, stopping the sync and resyncing is not a working workaround
Just wanted to confirm that this still persists in Kepler (build 20130614-0229), exactly the same behavior - CVS sync slows to a crawl with 79% and keeps repeating the Authenticating / Receiving cycle for a long time.
I am also experiencing this problem in Version: Kepler Release Build id: 20130614-0229 - CVS sync slows to a crawl with 79% and keeps repeating the Authenticating / Receiving cycle for a long time.
Confirmed this issue in the latest Kepler Eclipse Java EE IDE for Web Developers. Version: Kepler Service Release 1 Build id: 20130919-0819
i might have some bandwidth to help a bit. i wonder if any headway has been made? this one is a real show stopper for a massive move to kepler i'd like to do.
Exists still in Kepler. Version: Kepler Service Release 1 Build id: 20130919-0819 Working on a large project is impossible with this. Cannot use the diff tools of eclipse to see and merge changes. Is there any workarounds or settings that could provide a solution?
just use tortoise cvs which has rich features as well. don't use eclipse for the synchronization. you can use it for everything else. it sucks i know
> just use tortoise cvs which has rich features as well. > don't use eclipse for the synchronization. you can use it for everything else. That (like the comment above already suggests) is horribly impractical for large projects with thousands of java classes (for which the bug is especially relevant anyways, since for small projects and a quick connection it doesn't really matter). When you want to compare based on the code's logical structure, using Tortoise (which knows nothing about Java code and the way packages are structured / relate to each other) is next to useless. How is this not even investigated after a year and a half past the initial report time? This is a really serious bug.
OK then downgrade to Eclipse Helios where this problem was not a factor... import your projects in the earlier version. Then sync. Take care not to accidentally check in your metadata files and project files from the older version. But i feel you are being a bit over dramatic. I've used tortoise cvs on some pretty enormous code bases
I have just verified that the bug is still present in Eclipse Luna M5. Suggesting workarounds such as using CVS outside eclipse might help users with urgent issues, but really doesn't solve the problem. I really don't understand why this hasn't gotten any attention. There must be many users affected by this. It cannot be true, that all projects using eclipse have moved away from CVS, it would be really nice to hear if some users are not experiencing these issues. One note is, that I have extracted the project source using cmd line CVS, and then imported the project into eclipse, and "attached" the project to version control. Although I do seem to have the same issues with projects that I have extracted from the repository using eclipse.
I wish I knew how to check out the CVS add on and work through the issue. Does anyone have any quick tips to get me started and focused on the CVS sync issue?
(In reply to Nicholas DiPiazza from comment #19) > I wish I knew how to check out the CVS add on and work through the issue. > > Does anyone have any quick tips to get me started and focused on the CVS > sync issue? The team and CVS plugins can be found in the repo described at: https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.team You would need to clone that repo and import the projects. I'd probably start with the team.core, team.ui, and team.cvs.* projects. You would probably need an eclipse SDK - http://download.eclipse.org/eclipse/downloads/ with a version of EGit installed - http://download.eclipse.org/egit/updates-nightly or http://download.eclipse.org/releases/luna PW
Good stuff. OK i'll give it a shot tonight and see where I get. IRC: nickdipiazza
I have made a working blog of the issue as I work through it. Please give it a read and see if it gives anyone any ideas. I have a couple ideas but nothing too amazing yet. https://docs.google.com/document/d/1xCVnJA-QXXjVtO19hIbnXc7M0MEqreEPPz0QQsxEnu0/edit?pli=1 Please put in any input you have. Here is the document pasted below: Working on Eclipse CVS Synchronization bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=387412 During this process we will install • Latest Eclipse SDK 64-bit Version • Latest Eclipse Kepler JavaEE 64-bit Version 1) Grab latest copy of Eclipse SDK: http://download.eclipse.org/eclipse/downloads/ 2) Installed the EGit plugin by going to Help -> Install Software -> Select Kepler in the drop down and search for Git -> Install the Eclipse Git software 3) Grabbed latest Java Eclipse IDE for Java EE Developers, 250 MB a. Extract, and edit the eclipse.ini -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 4) Check out a massive CVS project and simulate some edits to a large number of the files. In my use-case, I have 1000’s of real files changed from about 100 days of work that diverged from a CVS repo. The Problem The logical place to start is: org.eclipse.team.internal.ccvs.core.connection.PServerConnection If you go to line 100 it is function public void open(IProgressMonitor monitor), you will see the sub task “Authenticating using pserver” Because this is the Message that displays over and over again as you attempt to sync, naturally you would expect if you trace down from there, you will find some sort of Authentication mechanism that is failing to retain a session, and hitting this over and over. So I put a breakpoint here and traced it down to a function here and that leads me to: org.eclipse.team.internal.ccvs.core.connection.Connection.open(IProgressMonitor) /** * Opens the connection. */ public void open(IProgressMonitor monitor) throws CVSException { if (isEstablished()) return; try { * serverConnection.open(monitor); } catch (IOException e) { throw new CVSCommunicationException(NLS.bind(CVSMessages.Connection_0, new String[] { fCVSRoot.getLocation(true), CVSCommunicationException.getMessageFor(e) }), fCVSRoot, e); } fIsEstablished= true; } So this Connection object is clearly not getting re-used by the RemoteFile’s as they iterate recursively through. Here is a typical stack: Thread [Worker-57] (Suspended (breakpoint at line 100 in PServerConnection)) PServerConnection.open(IProgressMonitor) line: 100 Connection.open(IProgressMonitor) line: 132 CVSRepositoryLocation.createConnection(String, IProgressMonitor) line: 545 CVSRepositoryLocation.openConnection(IProgressMonitor) line: 806 Session.open(IProgressMonitor, boolean) line: 159 RemoteFile.internalFetchContents(IProgressMonitor) line: 217 RemoteFile.fetchContents(IProgressMonitor) line: 195 RemoteFile(CachedResourceVariant).ensureContentsCached(IProgressMonitor) line: 111 RemoteFile(CachedResourceVariant).getStorage(IProgressMonitor) line: 101 CVSResourceVariantFileRevision(ResourceVariantFileRevision).getStorage(IProgressMonitor) line: 27 ContentComparator(AbstractContentComparator).getContents(Object, IProgressMonitor) line: 98 ContentComparator(AbstractContentComparator).compareObjects(Object, Object, IProgressMonitor) line: 55 ContentComparator(AbstractContentComparator).compare(IResource, IFileRevision, IProgressMonitor) line: 46 ContentComparisonDiffFilter.compareContents(IFile, IFileRevision, IProgressMonitor) line: 52 ContentComparisonDiffFilter.select(IDiff, IProgressMonitor) line: 62 WorkspaceSubscriberContext$2.select(IDiff, IProgressMonitor) line: 103 SubscriberDiffTreeEventHandler.addDiff(IDiff, IProgressMonitor) line: 243 SubscriberDiffTreeEventHandler.dispatchEvents(SubscriberEventHandler$SubscriberEvent[], IProgressMonitor) line: 224 SubscriberDiffTreeEventHandler(SubscriberEventHandler).doDispatchEvents(IProgressMonitor) line: 375 SubscriberDiffTreeEventHandler(BackgroundEventHandler).dispatchEvents(IProgressMonitor) line: 394 SubscriberDiffTreeEventHandler(BackgroundEventHandler).processEvents(IProgressMonitor) line: 374 BackgroundEventHandler$1.run(IProgressMonitor) line: 203 Worker.run() line: 53 It will over-and-over-again call for the file contents, which will then hit the connection open method, and there you have it. There is the problem. My Ideas at a Potential Fix I only have a bit of a hack approach right now. • In org.eclipse.team.internal.ccvs.core.client.Session, do not create and destroy a session each time it is asked for. Instead: o Create a Thread Local stored Connection variable the first time it is asked for. o Start a Thread to close the connection after a specified delay. o Restart the timer every time the connection is accessed. Not a very good approach. Does this help anyone get anyone further? I’ll keep working on this throughout the next couple weeks.
Thank you Nicholas for the analysis. I agree on all, but the actual "broken" line is not listed though: class: org.eclipse.team.internal.ccvs.core.resources.RemoteFile line 216: Session session = new Session(getRepository(), parent, false /* create backups */); It always recreate the session. However, do not forget that an ecplise may have multiple repositories, so that cache should have the "repository" as the key (do not know if it is intended to be "compared" with keys, i.e. implements hashCode and equals for java.util.Map use) However things may not be as simple: the code "not bugged" (I checked eclipse version 3.6, plugin version 3.3.301) and the "bugged" one (i checked eclipse version 4.3 and plugin version 3.3.500) the code is identical I think that before stating why it does not work, we must concentrate on "why it used to work", because in mine mind this is more obscure... Alex
Hi Alessandro, I agree with you - that was going to be my next step. But I wasn't clear what versions to grab until you filled in the blank thanks. I'll grab Eclipse 3.6 + CVS plugin 3.3.301 and I'll watch how the Session.open and Session.close are handled. I'll post on here when I learn the difference between the old versus new.
I think this might be related to CachedResourceVariant#isContentsCached - it seems like the original processing is done in another thread and the cache is not shared between threads, so it tries to recheckout the files it has already checked out. The reason why this worked before might be due to the fact that previously the same thread did the original checkout and the rechecking, so the cache was shared. This obscured the original bug, which is what Alessandro noted: the session gets created each time, so each time a new connection is established. Instead, there should be (probably a per-thread) connection cache. However, there is no easy way to do this - each call to RemoteFile#fetchContents is isolated, there is no group fetch, so there is no obvious context for which the session should be stored (and we cannot allow dangling connections to be left hanging). The only solution I can come up atm. is something like this: * a per-thread connection cache * cleanup code during CVS operation shutdown to make sure that all connections from the cache are dumped * or alternatively: an extra thread that works in the background and closes all connections that were not used during the last second or so The per-thread connection cache probably cannot be thread-local due to potential resource leaks - instead it should probably be a synchronized thread-indexed map so that subthreads which leave connections hanging have the cache cleaned up properly. What do you think?
Piotr, That sounded dead-on. I went ahead and put that in the working document. https://docs.google.com/document/d/1xCVnJA-QXXjVtO19hIbnXc7M0MEqreEPPz0QQsxEnu0/edit# I'll try your idea and put together a pull request as soon as possible. I am slow though, because I'm new to the code base. Maybe couple days.
Thank god you guys are working on this, it's happening to me as well. Are you sure this is limited to CVS? Does SVN have this issue as well potentially?
I have a simple implementation of a fix that does the Thread based caching for the connections. Now I need to build this puppy. I run maven clean install with a JDK6 compiler and it fails. Where is there a build guide that I can use? Can i just use Eclipse's export feature to make a quick patch? Links would be great, sorry for my newbie question.
(In reply to Nicholas DiPiazza from comment #28) > > Now I need to build this puppy. I run maven clean install with a JDK6 > compiler and it fails. Where is there a build guide that I can use? https://wiki.eclipse.org/Platform-releng/Platform_Build To just build one bundle, you use cd path/to/bundle; mvn -Pbuild-individual-bundles clean install. To provide it so that others can use it, you would need to make a feature patch (and then build against a target that contained your updated bundle). > Can i just use Eclipse's export feature to make a quick patch? To try it out, you can use File>Export...>Deployable Plug-in and Fragment. Export the bundle into your own Eclipse Install (it's an option under one of the tabs). To provide it so that others can use it, you would need to make a feature patch (you can export that to a separate p2 repository). PW
Thanks. That worked to get Maven through the build. The changes are quite simple and were contained within: org.eclipse.team.cvs.core-3.3.600-SNAPSHOT.jar So drag-and-dropped both those into eclipse-standard-luna-M5-win32-x86_64\eclipse\plugins and deleted the other versions that were there. Now the CVS repositories view won't display at all. How can I see a log of what happened?
OK I found the error log. It had complained that the plug-in Jar files are not still named the same thing. But... it worked!!!!! It's WAYYYY faster again. I'll work on the Thread cleanup logic and put out a post request.
I need some help understanding Eclipse plug-ins. I tried to do the following to install the new plug-in in My Luna M5 Eclipse install: 1) mvn -Pbuild-individual-bundles clean install This generates org.eclipse.team.cvs.core-3.3.600-SNAPSHOT.jar and org.eclipse.team.cvs.core-3.3.600-SNAPSHOT-sources.jar 2) Delete {eclipse-luna-install}/plugins/org.eclipse.team.cvs.core-*.jar 3) Copy org.eclipse.team.cvs.core-3.3.600-SNAPSHOT.jar and org.eclipse.team.cvs.core-3.3.600-SNAPSHOT-sources.jar to {eclipse-luna-install}/plugins/ 4) Edit {eclipse-luna-install}/artifacts.xml and edit the new artifacts <artifact classifier='osgi.bundle' id='org.eclipse.team.cvs.core' version='3.3.600.SNAPSHOT'> <properties size='1'> <property name='download.size' value='582829'/> </properties> </artifact> <artifact classifier='osgi.bundle' id='org.eclipse.team.cvs.core.source' version='3.3.600.SNAPSHOT'> <properties size='1'> <property name='download.size' value='444324'/> </properties> </artifact> 5) Save, start {eclipse-luna-home}/eclipse.exe -clean 6) Errors: eclipse.buildId=4.4.0.I20140123-1600 java.version=1.6.0_30 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -product org.eclipse.epp.package.standard.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.standard.product org.eclipse.team.ui Error Wed Mar 12 09:46:05 CDT 2014 Synchronization with id org.eclipse.team.cvs.ui.workspace-participant is not in the registry What am I doing wrong?
I figured that out. Using eclipse's export plugin feature worked nicely after i renamed the jars. Here is the patch: http://www.wakeandprevail.net/Bug-387412.patch Can someone help me get this feature out there so others can use it and so that it can get into the mainline?
I encountered the same recurring "Authenticating using pserver" message with Kepler SR2. That happened in some of my workspaces, not in every one. That, with the same installation of Kepler, and the same CVS server (just differents branches of the same project, in différent workspaces). ---------- RESOLUTION ---------- After some attempt to get out of this, I figured to this procedure restored the correct working speed I have on the "good" workspace. If someone could confirm that ! /!\ You will loose non-commited files, so commit or save same before. Steps: - Launch Eclipse - Do a full refresh (F5) on the project to be sure to be in sync - Perform a "Team > Revert to Base" on the project - Perform a "Team > synchronize" on the project and update any changes (this synchronized should be quick). - Exit and re-Launch Eclipse, perform a synchronisation, it should be quick
Hi Olivier I do not confirm. Reverting to base actually restores good performance, but touching many files restores the problem I've found a new dirty workaround (working for me at least): setting the flag named "Only look at timestamps to detect changes" to "true" helps
Hello, We are experiencing de same bug in IBM RAD 9.0.0 which is based on eclipse 4.2.1.v20130118-173121-9MF7GHYdG0B5kx4E_SkfZV-1mNjVATf67ZAb7 What can we do to avoid the 20 minutes-synchronize ? Isn't that fixed? Thanks
Hallo, just experienced this problem with my Eclipse (Version: Luna Service Release 1 (4.4.1)). I use this version since months and experienced this problem for the first time. Searching the web I found this thread. I like to share the solution for this problem, that I found somewhere else and that worked for me: The problems seems to be related to the windows firewall (using windows 8.1) . I removed the 'eclipse' rules and the problem disappeared. So check for firewall problems. Best regards Marc
I have the same problem on: Windows 7 Eclipse Luna Release 1 extssh cvs connection The first synchronize is very very very SLOW, the following synchronizes are FAST. I remove the Firewall rules "eclipse" but the problem persists. Please solve this problem because it is very noisy.
I still see this in Neon, SVN, Windows 10 and Solaris 11. It takes an hour or more to synchronize, also that long to merge in changes. Changing applications is not an option nor is changing firewall rules. Honestly, the code should handle this long-term problem. Fiddling with firewall rules is a very bad idea.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
