That's what we need to do before releasing 2.2.3. The question is whether the MySQL client library returns a proper error to the gatekeeper indicating that the connection is lost. We cannot reconnect on any arbitrary error.
----- Original Message ----- From: "Mikko Oilinki" <moilinki_os@xxxxxxxxx>
Sent: Monday, May 16, 2005 7:07 AM
--- Zygmuntowicz Michal <m.zygmuntowicz@xxxxxxx> wrote:That's how it (unfortunatelly) works now. MySQL client driver has a nice feature to reestablish lost connections, for PostgreSQL we would have to implement this.
Unfortunately this reconnect does not always work... :-( Maybe the reconnection work only when losing the connection but not in other kind of errors.
I am using gnugk 2.2.2 in Solaris 9, linked against static mysql client libraries. In the compilation platform the reconnect field of the MYSQL
structures are true (1). I guess it should be also true in the platform
I have had problems, but I have not actually confirmed that. Anyway,
once in a while, maybe once in one or two or three days there is error
executing the query (sqlauth.cxx(236)) - first I get:
Lost connection to MySQL server during query,
and then (not sure if always, I just have one print-out in front of me):
Can't connect to MySQL server on 'db.blahblahblah.com'.
On the MySQL server log (warning level for the server must be incremented
to see this, I guess):
[warning]: Aborted connection N to db: 'XXXXXX' user: 'XXXXX' host: `N.N.N.N' (Got an error reading communication packets)
or [warning]: Aborted connection N to db: 'XXXXXX' user: 'XXXXX' host:
`N.N.N.N' (Got a timeout reading communication packets)
Until reload issued (SIGHUP) the SQL connectivity is lost and gnugk is in useless state.
I have tried to reproduce the problem by taking sql stuff from gnugk apart and running a simple test program but have failed to reproduce the problem (I cannot use the same database server).
I guess it would not be so difficult to make the SQL connectivity much more robust for all kind of SQL drivers.
One way to fix the problem would be as follows:
On encountering an error executing the actual SQL driver specific
ExecuteQuery() method, the concrete GkSQLConnection::ExecuteQuery() methods could recreate the connection and try once again. Based on my glance on the code, it seems having successfully called AcquireSQLConnection() the SQLConnPtr connptr should be in m_busyConnections (if the connection pool is larger than 1)
or in m_idleConnections (if the size of the connection pool equals 1).
It should be okay to replace the connection with a newly created one.
I do not know if there is a way to find if a SQL connection works or not without making a query... if yes then we could test that before
recreating the connection so that we would not unnecessary burden the SQL server in case of configuration errors producing faulty SQL queries.
----- Original Message ----- From: "Costin Manda" <siderite@xxxxxxxxx>
Sent: Tuesday, May 10, 2005 11:35 AM
Yesterday I did something in Postgres that resulted in a non standard error. Basically, the Postgresql client told me that the connection to the server was lost and any software that had a connection to postgres open got an error like "possible memory corruption, connection lost". Reconnecting to postgres worked. Gnugk reacted to this by not being able to connect to pgsql but didn't reestablish the connection either. Until reloaded, it failed to do anything.
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________________
Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
