Hello
Is it possible to send null packets (keepalive packets) to keep a session active? It would be nice if the seconds between the packets could be configured.
Tnx
Keep Alive
Our firewall is the one disconnecting the idle sessions, not the MySQL server, as our mysql-server's timeouts are set to 8 hours.
I'm working with HeidiSQL every day. I like how the program evolved throughout versions 3 to 5, but i've always missed this feature.
I understand you're not going to implement the feature again, certainly when you dropped it earlier, but are there some workarounds?
I'm working with HeidiSQL every day. I like how the program evolved throughout versions 3 to 5, but i've always missed this feature.
I understand you're not going to implement the feature again, certainly when you dropped it earlier, but are there some workarounds?
With a working reconnection logic, why would you ever want to keep your connection alive, for what purpose?
Also, you should keep in mind that your firewall and/or the MySQL server disconnects you for a specific reason, which is: nothing to do for more than x seconds. Sending keep-alives seems to me like disabling a good feature.
Also, you should keep in mind that your firewall and/or the MySQL server disconnects you for a specific reason, which is: nothing to do for more than x seconds. Sending keep-alives seems to me like disabling a good feature.
Hi HostYou and Anse
I have the same problem as HostYou. After about 20 minutes with no use Heidi is unresponsive (not always but usually) for about 30 seconds. It's pretty frustrating.
I have raised this issue previously, and pointed out that the problem was present, was fixed in heidisql.r2688, and reappeared shortly after. I've looked back through the history and I suspect it was r2629 that fixed it.
I often use load version r2688 to avoid this very problem - I can assure you it doesn't occur with it.
Regards
Muzza
I have the same problem as HostYou. After about 20 minutes with no use Heidi is unresponsive (not always but usually) for about 30 seconds. It's pretty frustrating.
I have raised this issue previously, and pointed out that the problem was present, was fixed in heidisql.r2688, and reappeared shortly after. I've looked back through the history and I suspect it was r2629 that fixed it.
I often use load version r2688 to avoid this very problem - I can assure you it doesn't occur with it.
Regards
Muzza
The slowness fixed in both similar changes (r2629 and r2688) is still fixed - and was caused by loading table names from the current database into an internal list. Should not be a problem in the newer builds as this was not changed afterwards.
However, this thread discusses some unusual wait interval when connecting to a MySQL server through some firewall.
However, this thread discusses some unusual wait interval when connecting to a MySQL server through some firewall.
Hi Anse
I have just tested version 2688 vs 3528 after connecting them to the same database and then leaving them for an hour. V2688 was immediately responsive, while V3528 took 25 seconds to start again.
Interesting the V2688 exe is 932Kb and V3528 is 4748Kb. Possibly this is a clue?
I presume this issue doesn't affect everyone, but it's annoying for those it does affect. If you wanted to debug in this area I'd be happy to assist.
Regards
Muzza
I have just tested version 2688 vs 3528 after connecting them to the same database and then leaving them for an hour. V2688 was immediately responsive, while V3528 took 25 seconds to start again.
Interesting the V2688 exe is 932Kb and V3528 is 4748Kb. Possibly this is a clue?
I presume this issue doesn't affect everyone, but it's annoying for those it does affect. If you wanted to debug in this area I'd be happy to assist.
Regards
Muzza
Filesize has mainly grown due to not using UPX anymore. Should of course not be any problem, apart from traffic on my website.
I highly guess r2688 also takes 25 seconds for the first connect, does it? If so, it will of course be a problem of the connection itself, Firewall stuff, server reachability or something else - no debugging in Heidi required in that case.
I highly guess r2688 also takes 25 seconds for the first connect, does it? If so, it will of course be a problem of the connection itself, Firewall stuff, server reachability or something else - no debugging in Heidi required in that case.
Hi Anse
One version of HeidiSQL doesn't give me a problem, and the latest one does. On the face of it, it looks like a software issue not a server issue, since it's the same server and setup.
Anyway, decision to investigate is yours (my offer stands).
Thanks as always, for providing this software.
Regards
Muzza
One version of HeidiSQL doesn't give me a problem, and the latest one does. On the face of it, it looks like a software issue not a server issue, since it's the same server and setup.
Anyway, decision to investigate is yours (my offer stands).
Thanks as always, for providing this software.
Regards
Muzza
Hi Anse
1. Leave HeidiSQL for 30 minutes or so
2. Connected: shows 00:44:00 or similar
3. Bottom right states "Idle"
4. Click a table
5. Bottom right states "Fetching Rows"
6. After 30 seconds or so the rows appear
7. Connected: shows 00:00:03
So I guess it's the connection handshake.
Thanks
Muzza
1. Leave HeidiSQL for 30 minutes or so
2. Connected: shows 00:44:00 or similar
3. Bottom right states "Idle"
4. Click a table
5. Bottom right states "Fetching Rows"
6. After 30 seconds or so the rows appear
7. Connected: shows 00:00:03
So I guess it's the connection handshake.
Thanks
Muzza
Yes, sounds right. Only I'm not able to reproduce such slowness neither here in conjunction with 5 different server versions nor in my company, nor using SSH tunnel or SSL options. Makes no sense to look after some bug when it does not appear here. That's the reason why I keep thinking it has something to do with your connection to the server.
Hi Anse
I expect it is a connection issue too, it's just that one version avoids or solves my problem and one doesn't.
> Makes no sense to look after some bug when it does not appear here <
I'm in a similar business to you, and I appreciate the non-reproducibility issue. Hence my suggestion to assist debug.
No problem though.
Thanks
Muzza
I expect it is a connection issue too, it's just that one version avoids or solves my problem and one doesn't.
> Makes no sense to look after some bug when it does not appear here <
I'm in a similar business to you, and I appreciate the non-reproducibility issue. Hence my suggestion to assist debug.
No problem though.
Thanks
Muzza
Hi Anse
My libmysql.dll wasn't the latest one (I hadn't installed for ages, just run the updates). My version was April 2009.
I have now installed and have a February 2010 version of libmysql.dll, and tested over the last few hours. The situation does not appear to have changed.
Regards
Muzza
My libmysql.dll wasn't the latest one (I hadn't installed for ages, just run the updates). My version was April 2009.
I have now installed and have a February 2010 version of libmysql.dll, and tested over the last few hours. The situation does not appear to have changed.
Regards
Muzza
Don't you think the server should not receive anything as long as the user doesn't click anywhere? If you get a reconnect too often you could increase your "wait_timeout" variable:
This is 8 hours, the default value on newer servers. Older servers had 20 minutes by default if I recall right.
SET @@wait_timeout := 28800
This is 8 hours, the default value on newer servers. Older servers had 20 minutes by default if I recall right.
Please login to leave a reply, or register at first.