I agree it is not nice to blindly reconnect on every possible error. This might be extremely bad thing to do if the query failures are due to database server having hard time handling extensive load. I guess it would be easiest and cleanest to test the validity of the connection after failing with mysql_real_query() inside GkMySQLConnection::ExecuteQuery(), and attempt to reestablish it if failure. It should be possible to use the existing connection pointer (MYSQL*), not needing to replace the failing one with brand new one like I suggested below. I intend to do some testing with plain MySQL C library API to learn more about MySQL library behavior and to understand how to recognize when the reconnect feature is likely to not be utilized by the MYSQL connection. --- Zygmuntowicz Michal <m.zygmuntowicz@xxxxxxx> wrote: > 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/ > ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html ------------------------------------------------------- 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/
