Community
Participate
Working Groups
I get this error: ---------------------------------------------------------- Unable to complete action for feature "Graphical Modeling Framework (Callisto Edition)" due to errors. The File "/tmp/1895651917/eclipse/.update/1151741076112/1151741076216/eclipse38969.tmp" is not a valid JAR file. [error in opening zip file] The File "/tmp/1895651917/eclipse/.update/1151741076112/1151741076216/eclipse38969.tmp" is not a valid JAR file. [error in opening zip file] ---------------------------------------------------------- The file containts this: ---------------------------------------------------------- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html><head> <title>Menu for /eclipse/callisto/releases/plugins/org.eclipse.gmf.map.edit_1.0. 0.v20060627-1200.jar</title> </head><body> <h1>Menu for /eclipse/callisto/releases/plugins/org.eclipse.gmf.map.edit_1.0.0.v 20060627-1200.jar</h1> <hr /> [an internal server error occured] </body> </html> ---------------------------------------------------------- It seems that the mirror (I was using SWITCH in Switzerland) couldn't deliver the file for some reason. When I download it manually, it works. I tried to start the update again but when I don't restart Eclipse, it uses the cached files (which is usually clever but not in this case). Next, I deleted the faulty file and restarted the update (which means I have to remember what I wanted to install in the first place ...). Eclipse didn't like that at all: Now, I got an IOException. So I did a touch of the file. Now, Eclipse pretended to download it again but the file just contains the error above once more. So I downloaded the file and overwrote the faulty one. That's a bit hard because: 1. I have to figure out the download path somehow (the path in the error message is just relative to the update site path) 1. Eclipse somehow notices that the file was changed and tries to download it again. For some reason that always fails with the same error despite the fact that I can download it with wget (I tried 5 times). But I found a workaround: First, I move the faulty file away. Then, I copied the download to the name of the faulty file and lastly, I reset the date with touch -r, to Eclipse couldn't see the difference. Now, the update worked. But it would be better if there was a more simple way :-) Update should really check whether the file it downloads is actually what it expects. Maybe you should add file size and MD5 checksum to site.xml. I'm wondering though, why the download in Eclipse always fails while it always works with wget :-/
I got this too, from Windows (see posting to Cross project issues list). The two mirrors I tried were: Georgia Tech. Software Library (http) SAS Institute Inc. (http) [internal mirror for SAS employees] When I switched the mirror to: Eclipse Foundation Callisto Mirror 2 (http) [I can't remember if it was mirror 1 or 2] then it downloaded and installed GMF with no problem.
This appears to be a "dup" of but 131031 and believe the fix is entirely on the mirror server side. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=131031#c6 Perhaps the mirrors reported with the problem should be removed from the mirrors list, until confirmed fixed?
Removing the mirrors doesn't solve anything, and I disagree that the fix is *entirely* server side: 1. New mirrors could potentially exhibit this problem also 2. If the file can be fetched with wget and/or any http client, then why can't Eclipse fetch it? 3. Also, another solution would be to discontinue using filenames with .map in them, because servers associate these extensions to something else, and these JAR files in update sites are made to be served from http servers. 4. Anyone who wants to extend the Update Manager can have these problems too, unless Eclipse itself is fixed to work around this. D.
(In reply to comment #3) > Removing the mirrors doesn't solve anything, Why's this? If someone chooses the mirror, or if its choosen automatically, update will fail. So, why leave it on the list of working mirrors? > and I disagree that the fix is > *entirely* server side: Sorry, I misinterpreted the way you resoved bug 131031. There it sounded like servers had to improve the way they were configured. > 2. If the file can be fetched with wget and/or any http client, then why can't > Eclipse fetch it? > I have wget vesion 1.10.2 (on windows, probably from cygwin) and I get same error results from switch mirror, using following simple command. wget http://mirror.switch.ch/eclipse/callisto/releases/plugins/org.eclipse.gmf.map.edit_1.0.0.v20060627-1200.jar Aaron, what was your wget command that worked? Or, did you get it from another site? > 3. Also, another solution would be to discontinue using filenames with .map in > them, because servers associate these extensions to something else, and these > JAR files in update sites are made to be served from http servers. > All suggestions welcome, I guess, but this one does not seem practical. > unless Eclipse itself is fixed to work around this. Suggestions welcome ... how could eclipse be fixed to change how the server responds to the request for a jar file?
Just to document it, I wrote a small script to get all the callisto mirrors (those that have the site.xml file, and use the http protocol). I found 26 such mirrors (as of 7/3, 10 PM Eastern). And of those, 3 responded with HTML text, instead of the binary jar content, when using wget, to request that one specific gmf "map" plugin. The three were mirror.switch.ch SWITCHmirror eclipse.dcc.fc.up.pt Departamento de Ciência de Computadores, FCUP www.gtlib.gatech.edu Georgia Tech. Software Library (Natually, there could be other "internal" mirrors, like the SAS mirror, we could never know about, but these were the three "public" ones).
So... misconfigured Apache that should use a pattern like "\.map$" instead of just "map"? Short term fix is to remove from mirror list, long term fix is to get the webmasters to fix the Apache configuration?
(In reply to comment #6) > So... misconfigured Apache that should use a pattern like "\.map$" instead of > just "map"? Short term fix is to remove from mirror list, long term fix is to > get the webmasters to fix the Apache configuration? > Yes. mirror.switch.ch has already fixed theirs. And, I think, long long long term, Denis would like update manager to be more robust, so it if got an unexpected response, it would have a fall back plan, such as to simply go back to <home> server to get the file.
Just the bug seems fixed, just for historical reasons: I was using wget 1.10.2 on Linux on the mirror.switch.ch and I could download the file while the bug was still active. I could download it several times while the update with Eclipse always failed.
(In reply to comment #8) > Just the bug seems fixed, just for historical reasons: I was using wget 1.10.2 > on Linux on the mirror.switch.ch and I could download the file while the bug > was still active. > > I could download it several times while the update with Eclipse always failed. > Thanks Aaron. I assume you used similar "plain" command as I did in comment #4. I find this counter intuitive that we'd get different results (me getting the html response, you the binary jar response) ... so, mind digging a little deeper? Do you have a wgetrc file defined ... such as in /usr/local/etc/wgetrc or $HOME/.wgetrc ? I'm just wondering if there's some parameter there that could explain the difference ... could be as extreme as a proxy setting, or as subtle as an accept/reject parameter.
eclipse.dcc.fc.up.pt Departamento de Ciência de Computadores, FCUP has acknowledge "fixed", and while I haven't seen note from www.gtlib.gatech.edu Georgia Tech. Software Library testing just now, 7/4 6 PM Eastern, indicates theirs has been fixed too.
David, although this is a mirror problem and not "Callisto proper" it still feels that it belongs more in Callisto inbox then here in update. If you agree I will be moving it Callisto soon.
Sure, Callisto is fine, as might be easier to find there for reference. I have opened bug 149718 to track the update manager improvements that would be needed to handle this "bug" in server configurations.
I have /etc/wgetrc with these two options active: passive_ftp = on waitretry = 10 These shouldn't influence the HTTP download, though :-/
I think all the current mirrors are fixed now in this respect and bug 149718 can be tracked to monitor (or vote) for future improvements on the client side. One thing I'd like, sometime, is a simple program that would get each mirror, and test "getting" all the files ... this would help detect these sorts of problems a little earlier, or after some big wad of new conent was deployed.
count as fixed, thought future improvements are desired.
To help determine when the Callisto switch could be "flipped", I had created a small script that checked the mirrors that reportedly had the specified file (parameter) and display the overall accuracy. I had picked the last file in the directory, as RSYNC transfers files in alphabetical order. It's noteworthy that simply checking *one* file as below takes 37 seconds, so I estimate it would take about 29 hours to check is all 50 .zip files for platform :) Scanning for /eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip za Africa http://ftp.sun.ac.za/ftp/pub/mirrors/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! id Asia http://anak.kambing.vlsm.org/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! il Asia http://mirrors.nsa.co.il/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! jp Asia http://ftp.jaist.ac.jp/pub/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! jp Asia http://www.ring.gr.jp/pub/misc/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! kr Asia http://eclipse.areum.biz/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! tw Asia http://eclipse.cdpa.nsysu.edu.tw/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! th Asia http://www.datawiz.co.th/mirror/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! au Australia/Oceania http://mirror.pacific.net.au/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! au Australia/Oceania http://eclipse.planetmirror.com/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! at Europe http://gd.tuwien.ac.at/softeng/eclipse/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! bg Europe http://eclipse.prolet.org/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! cz Europe http://ftp.sh.cvut.cz/MIRRORS/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! cz Europe http://mirror.thisway.cz/eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! fr Europe http://eclipse.objectweb.org/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! fr Europe http://eclipse.work2gather.com/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! de Europe http://ftp.wh2.tu-dresden.de/pub/mirrors/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! de Europe http://mirror.yoxos-eclipse-distribution.de/eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! de Europe http://sunsite.informatik.rwth-aachen.de/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! de Europe http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! gr Europe http://ftp.ntua.gr/mirror/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! hu Europe http://eclipse.gabriel.co.hu/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! is Europe http://mirror.isir.is/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! it Europe http://rm.mirror.garr.it/mirrors/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! mk Europe http://eclipse.panton.com.mk/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! pl Europe http://www.eclipse.ps.pl/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! pt Europe http://eclipse.dcc.fc.up.pt/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! ro Europe http://ftp.roedu.net/mirrors/eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! ch Europe http://mirror.switch.ch/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! tr Europe http://mirrors.cs.hacettepe.edu.tr/eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! tr Europe http://eclipse.ulak.net.tr/eclipseMirror/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! gb Europe http://www.mirrorservice.org/sites/download.eclipse.org/eclipseMirror/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! ca North America http://gulus.USherbrooke.ca/pub/appl/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! us North America http://mirror.calvin.edu/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! us North America http://mirrors.cat.pdx.edu/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! us North America http://www.gtlib.gatech.edu/pub/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! us North America http://mirrors.ibiblio.org/pub/mirrors/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! us North America http://ftp.ussg.iu.edu/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! us North America http://ftp.osuosl.org/pub/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! us North America http://mirror.uta.edu/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! us North America http://www.software-mirror.com/eclipse/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! br South America http://eclipse.teccomm.les.inf.puc-rio.br/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- BAD br South America http://mirrors.uol.com.br/pub/eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/swt-3.2-win32-win32-x86.zip -- OK! There is an error. 43 mirrors total, 1 bad mirrors.
(In reply to comment #16) > > It's noteworthy that simply checking *one* file as below takes 37 seconds, so I > estimate it would take about 29 hours to check is all 50 .zip files for > platform :) > That is good to know! I'm assuming this was to fetch the whole file? So I won't try that! I was actually just thinking of doing a HEAD HTTP request, and checking the content type since that would be enough to 1) see if the server was there and responding, and 2) catch this mis-match of server configuration so it returns html instead of binary (jar) data for "*.map.jar" requests. Oh ... and was I only thinking of the update jars :)
> That is good to know! I'm assuming this was to fetch the whole file? Hell no, just an HTTP HEAD. Typical connection, command, response time is between .5 second and 2 seconds, multiplied by 43 servers. Anyway, it gives you an idea.
Seems like all of the mirrors could be tested in parallel so it would just take .5 to 2 seconds total (plus some overhead).
(In reply to comment #19) > Seems like all of the mirrors could be tested in parallel so it would just take > .5 to 2 seconds total (plus some overhead). > I agree, I just lack the programming skills to do that. D.
