Server doesn't respond

[Neil Porter]

I might not have anything to add from the MySQL side, but I've noticed with a MSSQL NT Webserver of mine, that it used to appear to not respond after a GPF.

I use GPFReporter to restart the service, but it appeared to restart almost too quickly, and couldn't properly bind to the port that I wanted, because it was still in use.

I spoke to Bruce to see if there was a way to test if the init had worked correctly, but he couldn't think of a way of doing it, so I placed a 10 second pause before the init of the webserver, and I haven't had a hang since.

Regards,

Neil.

[lanmicro]

Hi Neil,

That's interesting.  I am using GPFReporter to restart the application too, and it always hangs on the restart.

That's why I am using task scheduler to restart the program.  If the task scheduler continues to work I will try the 10 second pause before the init of the webserver.

[lanmicro]

Wolfgang,

The Website is reachable at 50.62.74.129:88.  This takes you to a logon screen where the problem manifests itself.

Problem is that there is a heartbeat in the WebServer procedure that reads the MySQL file every two minutes.  It never gives an error.

Opening the file just before accessing a record doen't give an error.  It is only upon accessing a record in the logon screen that the error comes back that MySQL server has gone away.

I believe there is a backup run every night but shouldn't that affect the heartbeat code that runs every two minutes too?

The IP address is static.

Thanks for the thoughts.

[Wolfgang Orth]

My suspicion is that the Backup locks some files, hence the unresponsive db.

[Larry Sand]

Gregory, do you have all of the hooks hooked in your sever so you can everything to a file?  Message, Assert, Stop, Halt, etc...

Larry Sand

[lanmicro]

Hi Wolfgang,

That's an idea, but I don't think that its the problem.  The file that has the problem is the same file that I do a heartbeat on every 2 minutes. (heartbeat = open and read first record in file)

My code for accessing the file before the GPF is essentially.

open( file )
clear( record )
fil:field = username
set( key, key )
next( file )    !This is where I get the message MySQL has gone away. Why didn't I get the message on the file open?

[lanmicro]

Gregory, do you have all of the hooks hooked in your sever so you can everything to a file?  Message, Assert, Stop, Halt, etc...

Larry Sand

Not sure what your asking here.  After starting the program during the day I have no problems accessing anything in the file.  After the site sits overnight the first access to the password file causes a GPF.

[kevin plummer]

I would add the exact code to your heartbeat that you use in your login but hardcode the username for starters.

Add a trace to your dbowner value in the login before file access.

Then try to add a super user to your login that will bypass the login file access and see if the rest of the program operates ok to isolate if it is just your login.

If it is just the login try using prop:sql for file access.

[lanmicro]

Hi Kevin,

I have tried prop:SQL and get the same error on the attempt to read the logon.

I have run the program with the ODBC trace turned on.  Everything looks fine (even the open of the file) until the attempt to read the logon. When I get the MySQL has gone away message.

I have not tried the super user.  But since I only get one test per day it is difficult to try everything.

BTW, so far for 3 days in a row.  Closing the app at midnight and using the scheduler to restart at 12:05AM has worked.

[kevin plummer]

do you think it is the time you restart or the hours since last accessed is the key? If you restart at 11:55pm or 8:00pm or 6:00am does that still work in the morning?

I would even run a 2nd web app on another port to try and isolate if it is the app or mySQL.

It is odd that the heatbeat does not throw an error (although you didn't mention if you changed the code to be the same as the login) which suggests that it is not MySQL. It's almost like it looses the connection string.

[lanmicro]

Hi Kevin,

Don't know if it is the time.  I have tried loging in at 11pm and it works.  The next morning it fails.

The code in the heartbeat is the same as the code in the login.

Really the only difference would be that the login would be on a different thread. 

But shouldn't the MySQL has gone away message happen on the open and not the row access?

And when testing the PROP:SQL method of accessing the password file I used a dummy table to return the data into so its not something wrong with the Clarion buffer.  It's the access of the row.

BTW, 4 days in a row working with the shutting down of the app at midnight and using task manager to restart at 12:05AM.