Unable To Stop A Sqlyog Query Process If The Process No Longer Exists

[jrossiter]

Unable to stop a SQLYog query process if the process no longer exists on the server. (In the event of a server crash, for instance.)

If the process on the server no longer exists, it's impossible to regain control of the application. Attempting to stop the process yields an error message (screenshot) but doesn't unlock the UI.

You're unable to close the app (without killing it manually) because “there is a query in progress”.

[peterlaursen]

Exactly how did you trigger this ?

I tried:

1) Running a query (a 'select * from …' running for a few minutes) and killing MySQL Server while query is running. Error message 'Lost connection to server during query' occurs. I can close this popup and close the program easily. This applies to direct connection and SSH-tunnelling as well.

2) Connecting with HTTP-tunnelling and killing the webserver while query is running. HTTP-error '… wrong handle …' occurs. I also can close this popup and close the program.

3) Opening two SQLyog program instances to the same server, running a query from one. While query isrunning I kill user thread used by first program instance from the other instance. No error message occurs, but I can stop the query from red 'X' icon without problems.

4) Tried the same three things with an 'export as SQL'. No problems here either.

All tested with 5.1b4

However I think there is another issue: if the main program thread locks for some reason the red 'X' icon is not responsive. But that is quite another thing.

[peterlaursen]

I wonder ..

Do you use LOCKs, TRANSACTIONs .. anything special?

Storage Engine? MySQL version ?

I am not sure if the Server should allow for closing client connection (to avoid data corruption).

[peterlaursen]

And of course I also tried just stopping the query too!

No problems either!

[peterlaursen]

The error message is a MySQL server message.

http://dev.mysql.com/doc/refman/5.0/en/err…ges-server.html

[jrossiter]

I'm aware of all of those things, however as I stated, a server crash doesn't explicitly kill connections.

I am running on MySQL 4 and 5, using both direct connections and SSH tunnelling.

The issue doesn't have to be reproducable to fix, however. Receiving an error message from the server stating that the thread doesn't exist should simply terminate the UI-lock.

[peterlaursen]

It would still be a help if you could tell how this was reproducable.

If I kill the thread I don't get this error!

[jrossiter]

peterlaursen wrote on Mar 24 2006, 10:50 AM:

If I kill the thread I don't get this error!

Sure, if you kill a thread *that exists*.

Try killing one that doesn't exist.

As I stated, in the event of a server crash or other malfunction, connections are not terminated. SQLYog still thinks it's connected to the server, and when the server is functioning again, it sends a kill command for a processid that doesn't exist.

[peterlaursen]

Then let me repeat ..

Quote:

I tried:

1) Running a query (a 'select * from …' running for a few minutes) and killing MySQL Server while query is running. Error message 'Lost connection to server during query' occurs. I can close this popup and close the program easily. This applies to direct connection and SSH-tunnelling as well.

2) Connecting with HTTP-tunnelling and killing the webserver while query is running. HTTP-error '… wrong handle …' occurs. I also can close this popup and close the program.

3) Opening two SQLyog program instances to the same server, running a query from one. While query isrunning I kill user thread used by first program instance from the other instance. No error message occurs, but I can stop the query from red 'X' icon without problems.

4) Tried the same three things with an 'export as SQL'. No problems here either.

First:

A server crash (whether MySQL server or webserver) raises an error.

Second:

I killed the thread used by SQLyog from another client! And I could stop the 'hanging' query from SQLyog.

And let me repeat again:

Quote:

It would still be a help if you could tell how this was reproducable.

If I kill the thread I don't get this error!

The more information you can give the better chances to find the issue! I don't doubt that you experienced this. The screenshot speaks for itself.

[Author]

Posts