forums › forums › SQLyog › SQLyog: Bugs / Feature Requests › Http Tunnel Timeout
- This topic is empty.
-
AuthorPosts
-
-
August 11, 2006 at 5:49 am #9797jrossiterMember
I've got my timeout set to 999 seconds, because I frequently do long queries. (In some circumstances, much longer than 999 seconds)
The problem is that the HTTP tunnel times out after 30 seconds of query execution, no matter what value I give it!
Quote:Error Code : 1HTTP Error. Could not connect to the tunneling URL.
(0 ms taken)
Same error, every time. I know it's executing properly because I can see the query in the processlist, but it just doesn't wait for a return value.
Why is it not smart enough to simply understand that it has a connection to the page and let the query time out on its own.
The Tunnel timeout value should be for initiating the connection only.
-
August 11, 2006 at 12:22 pm #22102peterlaursenParticipant
I am not sure I understand this.
Are you sure that it is SQLyog that initiates this disconnect?
To me it looks like it must a settting at your ISP that does that?
First try to edit the tunnelling file and replace the mysql_connct() with mysql_pconnect() connection method.
http://webyog.com/faq/21_103_en.html (paragraph 3)
-
August 11, 2006 at 5:18 pm #22103jrossiterMemberpeterlaursen wrote on Aug 11 2006, 05:22 AM:I am not sure I understand this.
Are you sure that it is SQLyog that initiates this disconnect?
To me it looks like it must a settting at your ISP that does that?
First try to edit the tunnelling file and replace the mysql_connct() with mysql_pconnect() connection method.
http://webyog.com/faq/21_103_en.html (paragraph 3)
Definitely not my ISP – they're my company servers, and I admin them.
I'll try pconnect, though I doubt it will make any change. connect has no time limits associated with it.
The query itself does not stop running at 30 seconds – the SQLYog connection aborts with the 'failed to connect'. To me it seems like SQLYog doesn't even know that it connected in the first place.
-
August 11, 2006 at 5:54 pm #22104jrossiterMember
As I suspected, no change.
It's not set_time_limit(), it's not apache aborting the connection…
-
August 11, 2006 at 6:18 pm #22105peterlaursenParticipant
OK .. I think I understand now.
You experience this when running a single query lasting more than 30 seconds to complete.
Well .. then I agree that mysql_connect and mysql_pconnect should not make any difference!
I cannot reproduce. I just executed a query like 'Select * from …' taking more than 15 minutes to complete on the server at webyog.com and another similar on my local WAMP stack lasting about 6 minutes. They both returned what they should and I did not have such message.
Quote:To me it seems like SQLYog doesn't even know that it connected in the first place.Maybe so! But it is not a general problems then! I will have to call in developers to tell HOW SQLyog decides that a connection is established with HTTP tunnel!
If you have an option to connect directly or with SSH it would be nice to know if it is the same problem!
Quote:connect has no time limits associated with itThere is no PHP config setting that you overlooked ?
What is the SQLyog program version?
-
August 11, 2006 at 7:02 pm #22106peterlaursenParticipant
Also: you do not have a proxy that 'cuts' after 30 seconds?
-
August 11, 2006 at 10:17 pm #22107peterlaursenParticipant
I can add that I repeated the query to the webyog.com server while downloading 5 CD-ISO's. Due the bandwidth limitation the query now took more than 2 hours to complete. No such timeout!
There must be some specific reason for this on you network. Saying so I do not say that there is not something that can be improved or optimized. But we will need to know that specific reason then! At least I agree that the error message could be better in this situation!
And actually I do not think it is true that the query takes that long. It is the transfer of data over the HTTP-tunnel that does. At least with what I did. How the data (and what data) are buffered I really do not know!
-
August 12, 2006 at 5:58 am #22108jrossiterMember
PHP and Apache settings are fine. The servers are developed for and running commercial PHP apps, and I configured them myself. We have administrative pages that can easily run for 5 minutes or 2 hours with no interruptions.
There's no proxy between myself and the server in question. There is a NAT, but again, I've personally built and configured that and there are definitely no timeouts present.
This is the entire scenario:
My machine connects through permanently-attached-VPN via web to the administrative machine using SQLyogTunnel.php
The administrative machine connects to a third machine which houses the DB. The only reason I do this with the tunnel instead of a direct connect is due to security considerations that were taken in the network routing. External machines are not allowed to talk directly to the internal network. (Network routing tables, not firewall, so again there's no timeout potential here.)
I have done SSH tunnels, and from what I remember this was not a problem. I continue to use SSH tunnels to access my home server when I'm in the office. The reason I opted not to use SSH for the work machines is that I often want to connect multiple sessions, and to do that with tunneling requires creating multiple profiles (which is kind of a pain). (Now, if SQLYog were smart enough to automatically use a random local port when creating its SSH tunnels, this would be really easy.)
The queries that have problems are always ones that actually take more than 30 seconds to execute (Generally speaking, DELETEs on large data sets) where no data is being returned at all.
That I know of, I've had no issues with situations where the data transfer takes more than 30 seconds, but it's hard to estimate that given my bandwidth to the server. It would have to be a very large resultset for that to occur in the first place.
-
August 12, 2006 at 2:02 pm #22109peterlaursenParticipant
As I wrote I'll need developers to answer in technical terms how SQLyog 'finds out' that a connections is established. Probably we will need some kind of debug build or remote access.
But if this was a general issue we would have heard about it long time ago. An we are not that silly (I hope not).
-
-
AuthorPosts
- You must be logged in to reply to this topic.