MySQL Bugs: #23759: Query Browser/Administrator lock up connect to server w/ shared memory enabled

Bug #23759	Query Browser/Administrator lock up connect to server w/ shared memory enabled
Submitted:	30 Oct 2006 0:52	Modified:	30 Nov 2006 7:51
Reporter:	Lachlan Mulcahy	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Query Browser	Severity:	S3 (Non-critical)
Version:	1.1.17 QB, 1.1.5 Admin	OS:	Windows (Windows 2003 Server)
Assigned to:	Mike Lischke	CPU Architecture:	Any

Description:
MySQL Query Browser locks up when trying to connect via TCP/IP to a server that has shared-memory enabled.

This only seems to effect Windows 2003 Server.

How to repeat:
Start mysqld with --shared-memory --shared-memory-base-name=MYSQL parameters.
Attempt to connect using Query Browser.

Suggested fix:
n/a

note: the identical problem occurs for MySQL Administrator.

Lachlan, I need more info:

1) Which server version is it?
2) Do you have a server where I can connect to (also via VPN).
3) Was it local or remote access?

Well, I'm not sure this is really a QB bug. It *could* implement an own timeout to  play nicely when the client lib chokes but it cannot be that we duplicate (part of) the work of the client lib. It's the lib that hangs and does not return although it should have a timeout for such kind of connections too. On the other hand shared memory is not officially supported in any way, so QB is not prepared to handle that and we won't add support for shared memory connections in the foreseeable future.

I have installed a .30 64bit server on the AMD64 machine. Not even the command line client is able to connect (but it does not hang, so I assume it uses different settings).

Mike,

Can you open a bug report that details what is wrong with the client library so a libmysql dev can fix it?

I assume this will mean that a new release of the QB/MA tools with the fixed library would be required anyhow?

Setting to "Won't Fix" is not appropriate - The problem still exists whether it is the fault of the tool or a linked library that it uses.

Also, in this case the user does not want to connect to the server using the shared memory method, they simply wish to connect to a server via TCP/IP, that also has the shared memory method available. 

Whether or not support for shared memory is planned for the tools in the forseeable future is irrelevant.

Lachlan, the point here is that shared memory is not officially supported so there will also be no support by the GUI tools. If somebody uses an unsupported feature then he must live with the consequences. It is really difficult to cover every possible case that could happen for all times. If you try to use the server as an email server and it does not work as such then you cannot file a bug report that it doesn't do so, because it is not made for that. Likewise, if you try to use shared memory and the GUI tools don't work with that you cannot file a bug report for that because neither the server nor the tools are made for that.

The docs clearly state it is an experimental feature only: http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-shm-definition.html and we have a lot other things to do, so we won't fix it until it becomes an officially supported feature.

I should add that even the command line client cannot connect via TCP/IP if shared memory is enabled, so it is pointless to start a server with that flag.

Mike,

The page you link to on shared memory refers to MySQL Cluster using shared memory. Use of shared memory as a connection method between regular client and server is, to my knowledge, fully supported.

There is no note in the manual here that indicates it is an experimental option.

http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html

Is there something that I am missing? 

The command-line client seems to connect correctly via TCP/IP provided that you specify the loopback IP for localhost, otherwise there is a "Lost connection to server during query.".

I'll open a new bug about the broken shared memory support. 

If the bug is fixed in the libmysql code, will that require a new build/release of the GUI tools to make use of the fix?

Lachlan, ok, I found more info in the manual (the search returns way too many irrelevant results, so I missed it before). Also talking only about the cluster in the chapter for shared-memory-connections did not help much.

AFAICS it should not be necessary to recompile the GUI tools if the client lib is fixed. I assume the server and the lib both used a different name for the shared memory (although the docs state it would be "MySQL" by default).