Bugzilla – Full Text Bug Listing
| Summary: | Update Speed Is Very Slow and Update Items Are Different | ||
|---|---|---|---|
| Product: | Community | Reporter: | Meng-Yuan Huang <myh> |
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> |
| Status: | RESOLVED NOT_ECLIPSE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | myh, pascal |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Meng-Yuan Huang
Today, I find my two Windows 7 PCs can get the latest version updates from this site: http://sveditor.sourceforge.net/update However, I don't know what happened. I meet the some update items not shown problem again recently on SVEditor update site: http://sveditor.sourceforge.net/update One day, I found my Eclipse on Windows can't show newer versions (>0.3.5) of SVEditor. However, my Eclipse on Linux hasn't met this problem. I have tried to use Wireshark to debug. The Wireshark result shows SVEditor update only has site.xml, not content.xml. And I find a content.xml which record information about SVEditor on my one Eclipse subdirectory: F:\eclipse\configuration\org.eclipse.osgi\bundles\402\data\-2114671088\content.xml This content.xml has information about SVEditor only up to version 0.3.5. And I am sure that Wireshark shows my Eclipse on Windows got the latest site.xml from update site and the captured packet data shows that site.xml contains SVEditor version > 0.3.5 (0.3.6~0.3.8). However, my Eclipse on Windows didn't update the content.xml on my hard disk. After I manually deleted the content.xml on my hard disk, I can get the latest SVEditor 0.3.8 now. I have implicitly suggested SVEditor author to use newer Eclipse update method (p2): http://sourceforge.net/tracker/?func=detail&aid=3118451&group_id=230781&atid=1081016 However, I still hope Eclipse developer can solve the problem. I think this might be an Eclipse update bug. Eclipse (Galileo or Helios) on Windows (XP or 7) seems has a update bug, which can't detect the modification of an update site with only site.xml. (In reply to comment #2) > I have tried to use Wireshark to debug. > The Wireshark result shows SVEditor update only has site.xml, > not content.xml. Sorry, I find I mistyped here. I want to express: The SVEditor update "site" only provides site.xml. On other word, it uses older update method instead of p2. Today, I want to update my SVEditor to 0.3.9 on Windows. Unfortunately, it failed. My Eclipse on Windows only showed versions 0.2.8~0.3.8. However, my Eclipse on Linux successfully updated to 0.3.9. This seems to be a old problem. However, I found an error message on my Eclipse Error Log tab! -------------------------------------------------------- Error Message 1 Mon Feb 14 09:01:31 CST 2011 Error reading feature https://sourceforge.net/projects/sveditor/files/update_site/0.3.9/features/net.sf.sveditor_0.3.9.jar/download. eclipse.buildId= java.version=1.6.0_23 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=zh_TW Framework arguments: -product org.eclipse.epp.package.cpp.product Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.cpp.product -------------------------------------------------------- Error Message 2 Mon Feb 14 09:01:31 CST 2011 Provisioning exception org.eclipse.equinox.internal.provisional.p2.core.ProvisionException: Unable to connect to repository https://sourceforge.net/projects/sveditor/files/update_site/0.3.9/features/net.sf.sveditor_0.3.9.jar/download at org.eclipse.equinox.internal.p2.updatesite.UpdateSite.parseFeature(UpdateSite.java:264) at org.eclipse.equinox.internal.p2.updatesite.UpdateSite.loadFeaturesFromSite(UpdateSite.java:535) at org.eclipse.equinox.internal.p2.updatesite.UpdateSite.loadFeatures(UpdateSite.java:441) at org.eclipse.equinox.internal.p2.updatesite.RemoteFeaturesAction.perform(RemoteFeaturesAction.java:40) at org.eclipse.equinox.internal.p2.updatesite.RemoteUpdateSiteAction.perform(RemoteUpdateSiteAction.java:48) at org.eclipse.equinox.p2.publisher.Publisher.publish(Publisher.java:172) at org.eclipse.equinox.internal.p2.updatesite.metadata.UpdateSiteMetadataRepositoryFactory.generateMetadata(UpdateSiteMetadataRepositoryFactory.java:125) at org.eclipse.equinox.internal.p2.updatesite.metadata.UpdateSiteMetadataRepositoryFactory.initializeRepository(UpdateSiteMetadataRepositoryFactory.java:110) at org.eclipse.equinox.internal.p2.updatesite.metadata.UpdateSiteMetadataRepositoryFactory.load(UpdateSiteMetadataRepositoryFactory.java:74) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:54) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:669) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:617) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:88) at org.eclipse.equinox.internal.provisional.p2.ui.operations.ProvisioningUtil.loadMetadataRepository(ProvisioningUtil.java:88) at org.eclipse.equinox.internal.provisional.p2.ui.QueryableMetadataRepositoryManager.doLoadRepository(QueryableMetadataRepositoryManager.java:55) at org.eclipse.equinox.internal.provisional.p2.ui.QueryableRepositoryManager.loadRepository(QueryableRepositoryManager.java:195) at org.eclipse.equinox.internal.provisional.p2.ui.QueryableRepositoryManager.loadAll(QueryableRepositoryManager.java:108) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$2.run(PreloadingRepositoryHandler.java:71) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.net.ConnectException: Connection timed out: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:125) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346) at org.eclipse.ecf.provider.filetransfer.httpclient.HttpClientRetrieveFileTransfer.performConnect(HttpClientRetrieveFileTransfer.java:1017) at org.eclipse.ecf.provider.filetransfer.httpclient.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:610) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:808) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:506) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:98) at org.eclipse.equinox.internal.p2.repository.FileReader.sendRetrieveRequest(FileReader.java:317) at org.eclipse.equinox.internal.p2.repository.FileReader.readInto(FileReader.java:263) at org.eclipse.equinox.internal.p2.repository.RepositoryTransport.download(RepositoryTransport.java:71) at org.eclipse.equinox.internal.p2.repository.RepositoryTransport.download(RepositoryTransport.java:127) at org.eclipse.equinox.internal.p2.updatesite.UpdateSite.parseFeature(UpdateSite.java:249) ... 19 more -------------------------------------------------------- Error Message 2 shows the keyword "Connection timed out." It seems to be my Eclipse can't acquire this file: https://sourceforge.net/projects/sveditor/files/update_site/0.3.9/features/net.sf.sveditor_0.3.9.jar/download However, I can download the file by Google Chrome. I don't know why my Eclipse wanted to acquire that file in the background. However, I think because my Eclipse can't get the file, it didn't show SVEditor 0.3.9 update item in my update manager. In addition, my Eclipse on Linux has never complained "Connection timed out" for that URL. Hi everyone, After I continued using Wireshark to debug, I found a cause that I can't get the latest SVEditor. I am an National Central University (NCU) Taiwan student. I use my computers in my school. And my school has a SourceForge mirror (140.115.17.45). When my Eclipse tried to acquire files on sf.net, sf.net always redirected the file location to 140.115.17.45. However, it seems 140.115.17.45 has some network connection problems. My Wireshark captures shows 140.115.17.45 was very slow on acquiring SVEditor 0.3.9. However, Eclipse on Linux finally can get the latest SVEditor, 0.3.9. But, unfortunately, Eclipse on Windows can't wait the slow respone of 140.115.17.45 and showed the timeout error. I had reported this connection problem to NCU. If they can solve this problem, I will tell you the good news. Hi everyone, I had reported this problem to the NCU SF mirror manager. This problem is confirmed as an NCU SF mirror problem. The problem stems from: My IP is 140.115.x.x. SourceForge(SF) automatically redirects my request to a default mirror. The default mirror can only be changed to another through a SF webpage. But, Eclipse has no such web browser to surf the webpage and change. It means the Eclipse user can't change to another SF mirror. The worse thing is if the default mirror is broken, the Eclipse user can't get files from another normal SF mirror. I had searched by Google and found a similar discussion: https://sourceforge.net/apps/trac/sourceforge/ticket/13031 Could Eclipse provide any way to change the SourceForge mirror site? > Could Eclipse provide any way to change the SourceForge mirror site? In your hosts file (C:/Windows/System32/Drivers/etc/hosts) simply add the ip address of another mirror, and call it sf.net x.x.x.x sf.net sourceforge.net But that may be tricky, since they seem to redirect you to the moon before a download. Try downloading the jar files from mirror directly: http://cdnetworks-us-2.dl.sourceforge.net/project/sveditor/update_site/0.3.9/features/net.sf.sveditor_0.3.9.jar Unfortunately, this is not an Eclipse bug, or anything the Eclipse project teams can do to fix. (In reply to comment #7) > > Could Eclipse provide any way to change the SourceForge mirror site? > > In your hosts file (C:/Windows/System32/Drivers/etc/hosts) simply add the ip > address of another mirror, and call it sf.net > > > x.x.x.x sf.net sourceforge.net > > But that may be tricky, since they seem to redirect you to the moon before a > download. > > Try downloading the jar files from mirror directly: > > http://cdnetworks-us-2.dl.sourceforge.net/project/sveditor/update_site/0.3.9/features/net.sf.sveditor_0.3.9.jar > > Unfortunately, this is not an Eclipse bug, or anything the Eclipse project > teams can do to fix. Hi Denis Roy, Thanks for your help. |