> Taverna understands the proxy configuration perfectly as I can see > "myExperiment". However, certain workflows do not work.
Just to be sure that the Proxy configuration is used - could you try to modify the proxy configuration slightly so that it has say the wrong username? Taverna should fail to list any public services under "Available services" - and searching for anything in the myExperiment perspective should not work. If this is the case, then change the proxy configuration back to the correct values - we are now pretty certain that it is used. > I've run "validate service" from taverna on "getTableNames" on the > following services, and those are the outputs: > http://140.105.77.30:8080/helio-hec/HelioTavernaService => Taverna was > unable to connect to ... within 10.0s. > Eyy! there's a Tab with Solutions. It says, open it on the browser, if > it works (it does), then increase the time: Ok 15 s. .... Now it works! > at least getTableNames. Let's test SQLSelect.... > .... "validating service": Success!! > Ok, let's run workflow:..... > .... 502 Bad Gateway. This does not sound very good - it can connect in 15 seconds - but not in 10? Running the workflow should still work in this case - because for WSDL service execution the default timeout is 60 seconds - but of course it could be the proxy itself that has a different time out when it is calling the service. The validator would give a warning for any server errors returned which are 500 or higher - including 502. http://140.105.77.30:8080/helio-hec/HelioTavernaService responds very fast in a browser when I test that manually. "Validate" does a HEAD request on that URL which should complete even faster. Such a delay could in some cases indicate a DNS issue (for instance a laptop at work, still trying to use the DNS servers of the ISP at home) - but in this example the service is addressed using IP addresses which don't have that problem. Are you sure your proxy allows you to connect to services at non-standard ports like :8080 ? Many organisations block such ports - although 8080 is common to leave open. When you try this link in the browser - you say it works - how fast does it respond - and is it using the exact same proxy configuration? Which operating system and browser are we talking about? Could you try to add something to the URL in the browser to make sure you don't load it from cache? For instance: http://140.105.77.30:8080/helio-hec/HelioTavernaService?qwerasdfasdf > http://msslxw.mssl.ucl.ac.uk:8080/helio-ics => perfect! > http://msslxw.mssl.ucl.ac.uk:8080/helio-ils => perfect! > http://voparis-helio.obspm.fr/helio-hfc/HelioTavernaService => Port > response: An error occurred invoking the WSDL service > > As you can see there's something weird!! I've tried that at home and it > works, here at work it does not. As I said before I've been wondering if > that could be related with the proxy (as it's the big difference from > here to my home connection), but I don't get why some work perfectly > (mssl), and others don't (italy and france). No, I agree this does not make sense. Also my previous port-suggestion is obviously not the case, as these other :8080 services worked, and the French one which is at standard :80 does not work. Just a quick check - which distribution and version of Java are you running? Run "java -version" on a command line. Another side note - some servlet containers behave very strangely and give a 404 Not Found or 500 Server Error on HEAD, yet 200 OK on GET. Taverna's WSDL validator therefore always tries a GET if it gets a non-200 error on the HEAD request. Some of your services are of this kind: : stain@ralph ~; curl --verbose --head http://140.105.77.30:8080/helio-hec/HelioTavernaService >/dev/null * About to connect() to 140.105.77.30 port 8080 (#0) * Trying 140.105.77.30... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected * Connected to 140.105.77.30 (140.105.77.30) port 8080 (#0) > HEAD /helio-hec/HelioTavernaService HTTP/1.1 > User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e > zlib/1.2.3.4 libidn/1.22 librtmp/2.3 > Host: 140.105.77.30:8080 > Accept: */* > < HTTP/1.1 404 Not Found < X-Powered-By: Servlet/3.0 < Server: GlassFish v3 < Content-Length: 0 < Date: Tue, 06 Dec 2011 09:27:45 GMT < 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 * Connection #0 to host 140.105.77.30 left intact * Closing connection #0 While GET works fine: : stain@ralph ~; curl --verbose http://140.105.77.30:8080/helio-hec/HelioTavernaService >/dev/null * About to connect() to 140.105.77.30 port 8080 (#0) * Trying 140.105.77.30... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected * Connected to 140.105.77.30 (140.105.77.30) port 8080 (#0) > GET /helio-hec/HelioTavernaService HTTP/1.1 > User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e > zlib/1.2.3.4 libidn/1.22 librtmp/2.3 > Host: 140.105.77.30:8080 > Accept: */* > < HTTP/1.1 200 OK < X-Powered-By: Servlet/3.0 < Server: GlassFish v3 < Content-Type: text/html;charset=utf-8 < Content-Length: 4767 < Date: Tue, 06 Dec 2011 09:27:52 GMT < { [data not shown] 100 4767 100 4767 0 0 34773 0 --:--:-- --:--:-- --:--:-- 54170 * Connection #0 to host 140.105.77.30 left intact * Closing connection #0 However it could very well be that the HTTP proxy choses to understand the 404 HEAD response as truly, there is no resource there - and although no cache information was included, it could in theory be caching that response, which would break later GET (but should not break the POSTs done at execution). I'm just guessing wildly here now.. but perhaps you could verify this using curl on the command line? Note that you will need to include additional options to use your proxy: --proxy 1.2.3.4:5678 --proxy-user fred:passwd ex: : stain@ralph ~; curl --verbose --head --proxy 1.2.3.4:5678 --proxy-user fred:passwd http://140.105.77.30:8080/helio-hec/HelioTavernaService >/dev/null * About to connect() to proxy 1.2.3.4 port 5678 (#0) If you send those traces to me, make sure that your "passwd" is not included. -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ taverna-users mailing list [email protected] [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/about/contact-us/
