Community
Participate
Working Groups
When using forwarded ports through SSH, with a configured Task Repository URL such as bugzilla:http://localhost:8889/bugs, the Bugzilla pane reports: "Could not download task data, possibly due to timeout or connectivity problem. Please check connection and try again." Note that querying this repository w/ the above URL works.
Tony, am I correct in saying that queries from Mylar (for example Search > Repository Task) work but you are unable to load the resulting hits? Can you confirm that urlbase is set on your repository?
Hey Robert - yes, you are correct in saying that. What exactly are you referring to when you say urlbase? Is this something I can set inside of Task Repository Settings, or is this set somewhere else?
urlbase is a property set in the bugzilla server settings. If the repository isn't your own you probably will not have access to this. One way of checking is to point your browser to <your-repository-url>/config.cgi?ctype=rdf (then view the page source) and check that the rdf:about attribute is not blank (ie. <bz:installation rdf:about="AddressOfRepositoryHere?">). If there is a proper repository url there then we will need to investigate further.
<bz:installation rdf:about="http://bugs.tuvox.com/"> is what's there. This machine is behind the company firewall, so I'm using SSH and the above URL to access this repo. Should this be a problem?
One more note - if I VPN in and use http://bugs.tuvox.com, I don't encounter this issue.
A few thoughts: - Have you tired redirection using something like http://localhost:8889/bugs:sshtunnelportnumberhere or is this not how your ssh client works? - Try adding the trailing / to the url you enter in the task repository config Sorry but I haven't tried a port forwarding configuration so am just throughing ideas out there. :) Let me know if either of these ideas work and if not, perhaps you can let me know what ssh product you are using and I can try to reproduce the environment here?
The trailing / is automatically removed once I close the Task Repository Settings Dialog. I'm using SSH Secure Shell 3.2.9.
I'll have to set up a similar environment here and test. I'll get back to you asap.
I've tested port forwarding here using both SecureCRT and SSH Secure Shell 3.2.9 and can't reproduce the error with either. Are there any hints in the error log?
Could you give me some details about the Bugzilla repository itself such as: -Is it customized? -What version is it? -Are you able to retrieve bugs as xml? (I've added an entry about this to the faq http://wiki.eclipse.org/index.php/Mylar_FAQ#Bugzilla_Connector_troubleshooting)
- Is the repository using LDAP authentication?
No to both anything useful in the error log and LDAP auth. Did you use a similar url when you tested the port forwarding w/ SSH?
I tried http://localhost:8889/myrepository with 8889 redirected to 80 on the remote host without problems. I also tried with https without failure.
Do you have a test SSH account in your environment so I can try connecting to it? It would be interesting to see if the problem is with the setup of my company's repo.
There is now a guest account on mylar.eclipse.org for you to test against. I'll send you the password and details over email.
I have no issues when using this test environment that you've setup. The Bugzilla Pane/View is working as expected. This really only leaves the Bugzilla instance/config at fault. Any other ideas? If I get access to this Bugzilla instance, are there any logs or settings that I should check?
I must admit I'm running out of ideas here. The only observation I can make is that if it works over VPN but not over an ssh tunnel then the trouble must be the tunnel, no? As far as the bugzilla config goes you could check that: - it is version 2.18 or higher - check to ensure that the parameter regarding use of ssl is in fact set to 'never' But I'm still convinced this is something to do with the tunnelling. :)
So here's the setup. This machine's Internet addressable IP is 64.221.252.202 / dev02.tuvox.com. Inside the firewall/intranet, the machine is aliased as bugs.tuvox.com with IP 10.232.10.10. The url for bugzilla is http://bugs.tuvox.com/bugs. I've tried all the combinations in terms of specifying machine name/url in the tunneling and ssh options. I think this is the difference in your environment. The IP/Machine Name that I SSH to is not (and cannot) be the same as the IP/Machine Name specified in the tunneling. Can you confirm that both those are the same in your test env?
Yes, the test server (mylar.eclipse.org) you are connecting to over ssh is the same (virtual) server that hosts the bugzilla server. So when tunneled, can you query and download bug reports via the web ui without failure?
I can't help but wonder if apache is doing name based virtual hosting, but that doesn't make sense because you said you can retrieve query results...
I actually did set both settings to dev02.tuvox.com (both for the destination host for SSH and then the destination host for the tunnelling), and it still doesn't work. What's so frustrating is that I don't get any more detail then just: "Could not download task data, possibly due to timeout or connectivity problem. Please check connection and try again." I guess if I grabbed the source and set some breakpoints... Does mylar.eclipse.org have other aliases? Is this host name specified in the Bugzilla install? My suspicion is still with the multiple names (whether configured via Apache or the OS) this machine is serving Bugzilla through.
I'll try adding some more debug output and then ask Mik to cut a dev build for you to try out - perhaps then we'll be able to track this down.
I just noticed that in comment#18 you mention that the url for bugzilla is http://bugs.tuvox.com/bugs but in comment#4 the config you provide is pointing to http://bugs.tuvox.com/. This could be the problem, could you double check these?
This is the problem I think. When VPN'd in, both of the above urls will get to the start page in the browser. However, when tunnelling, only http://localhost:8889/bugs will work. But the Bugzilla url base is set to http://bugs.tuvox.com. Not sure what's the best way to resolve this one
I think the only resolution is to get the sysadmin to set the urlbase on the bugzilla server to the correct url http://bugs.tuvox.com/bugs. My guess is that there is some redirect happening for http://bugs.tuvox.com/ that isn't happening when you are tunnelled in.
Were you able to get the urlbase updated Tony?
The change request was put in last week, and I'm looking forward to testing this sometime today. Will keep you posted.
Any luck Tony?
If you guys come up with any additional steps or caveats with connecting in tunneled mode please put them here: http://wiki.eclipse.org/index.php/Mylar_FAQ#Network_and_proxy_server_troubleshooting Rob: you should also make sure that the misconfigured hostname problem is listed in the troubleshooting: http://wiki.eclipse.org/index.php/Mylar_FAQ#Bugzilla_Connector_troubleshooting
We didn't change the urlbase, but we did change the apache virtual mapping so that the virtual root now points to the bugzilla instance. So now I can access from my browser (when ssh'd/tunneled) to http://localhost:8889/ instead of the old http://localhost:8889/bugs. However, the problem is still there. I'm not sure what the next step is...
A version of today's dev build with additional logging info is now available from: download.eclipse.org/technology/mylar/update-site/test You may need to give it up to 30 minutes to replicate. Version is:0.6.2.v20060922-1830 Note that this is an Eclipse 3.3M2 build, but everyting other than the automatic context test suite should work fine.
Using the dev build, here are excerpts from .log: VPN'd AND SSH'd (works!): !ENTRY org.eclipse.mylar.core 1 0 2006-09-22 23:40:23.940 !MESSAGE Mylar: Retrieving task data from: http://localhost:8889, source: java.lang.Class VPN'd and NOT SSH'd (still doesn't work): !ENTRY org.eclipse.mylar.bugzilla 4 0 2006-09-22 23:40:12.486 !MESSAGE Report download from http://localhost:8889 failed, please see details. !STACK 0 java.net.ConnectException: Connection refused: 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.Socket.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at java.net.HttpURLConnection.getResponseCode(Unknown Source) at org.eclipse.mylar.internal.bugzilla.core.AbstractReportFactory.collectResults(AbstractReportFactory.java:57) at org.eclipse.mylar.internal.bugzilla.core.RepositoryReportFactory.populateReport(RepositoryReportFactory.java:44) at org.eclipse.mylar.internal.bugzilla.core.BugzillaServerFacade.getBug(BugzillaServerFacade.java:97) at org.eclipse.mylar.internal.bugzilla.core.BugzillaOfflineTaskHandler.downloadTaskData(BugzillaOfflineTaskHandler.java:80) at org.eclipse.mylar.tasks.ui.SynchronizeTaskJob.run(SynchronizeTaskJob.java:101) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Just to clarify, that second scenario above "VPN'd and NOT SSH'd (still doesn't work)" did you mean "SSH'd and NOT VPN'd"?
Sorry about the confusion - you are right. It should be SSH'd and NOT VPN'd
The exception posted in comment#32 indicates that the host isn't listening on port 8889. This is very strange since you are able to query the server. I'm going to look into this further and will get back to you asap. In the mean time, could you try opening a report with your repository configured for anonymous access and see if this has some effect? Thanks.
I'll see if the admin guys will be willing to allow anon access temporarily.
Also, in the Eclipse toolbar menu go to Search > Search... > Task Search, select the repository in question and press Update Attributes from Repository. Let me know if the fields populate with values or if it remains blank.
Task Search works when I'm SSH'd and using http://localhost:8889
I spent more time on this yesterday to see if perhaps some invalid url construction was causing this upon task retrieval but again I couldn't re-produce. The only time I came remotely close to reproducing was when the web host was doing redirection which would cause a problem but you aren't seeing html 'move' related exceptions so I've hit a dead end again. You mentioned you might be willing to download the source and set a few break points, perhaps that is our next best option?
I'd be happy to do that. We can coordinate over IM?
Tony: the workspace setup instructions are here http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Workspace_setup If you have any problems getting set up it would be good if you could update those. Feel free to post questions about that on this bug report in case Rob is more responsive on Bugzilla than on IM, since it's our practice to assist with debugging/configuration stuff on Bugzilla whenever possible (so that the conversations are captured for others to reuse if needed).
Tony, have you had a chance to look at this?
I have my environment all set. Want to give me the breakpoints I should set?
It looks like an exception is being thrown around line 57 in AbstractReportFactory because connection is refused. So just set a break point at line 55 where the WebClientUtil.openUrlConnection(url, proxySettings, false) call is and check that the url is sound....then we can go from there. Set the break point and then just right click on a hit and select synchronize which should exercise this code.
here's what i found. line 115 returns and we get to the finally pretyt much right away when i get a task from a repository that works (like the bugs.eclipse.org), but it takes a long time using my example, but it still gets to the finally clause... ...and then after the finally, the ConnectionExcpetion is caught inside downloadTaskData of BugzillaOfflineTaskHandler
Great. Lets just confirm that we're getting data by adding the line: System.err.println(characters); just after line 71 in the SaxBugReportContentHandler.characters(..) method. This will spit out the data (if any) we're getting back in each xml element.
I can't figure out what's going on - there are some inconsistencies in tracing through. Without ever vpn'ing in (only tunneled), I was once able to retrieve a task. I was tracing deep through the call stack, and the only thing I can figure out is that this "run" had enough time to complete the task, whereas normally, it times out.
Okay thanks Tony! I've had one other user mention similar behavior so will investigate the possibility of timeouts causing this problem.
Hey Rob - any updates?
There were some changes to task data retrieval that made it into 0.8 release. Could you give this release a shot. I still haven't been able to reproduce and therefore solve out-right though. Some more major changes are ahead for 0.9 as I'll be moving to apache's HttpClient library exclusively.
Tony, I've made some major changes in task data retrieval (switched to Apache HttpClient from java's URLConnection). I've also added http authentication to the mix. Mik will be cutting a dev build that includes these changes this afternoon. It would be great if you could test with it. I'll post the version number so you're sure to have the correct build.
There were some encoding issues in last nights build. We'll be cutting another dev build Friday evening that fixes these issues and others (targets M3).
Hi Tony, any chance you could test with the latest release (0.9)?
It's now working! And it only took 54 comments ;)
Great! Thanks for the confirmation Tony.
Wow, talk about persistence guys, nice work on all sides :) Marking this as a "greatbug" due to the trickiness (problems with java.net.URL failures), and the amount of collaboration needed to figure out that we had had to go as far as changing our authentication/connection architecture to resolve it.
