odd WindowsXP check-in issue?
I've just analyzed an odd situation here at our CRG location(s).
We had been having an intermittent problem with one of our PCs regarding connectivity.
We have 3 running locations (soon to be 4), each with dedicated Check-In PC. All of the systems, save 1, are running Windows7. The strange behavior is that every so often our WindowsXP system -- one of the dedicated Check-In PCs loses connectivty to one of the two other distant locations. However, it is ONLY that PC -- the other POS sytems maintain their connection. This results in a 'foreign' member having to manually do a check-in with staff on one of the other local POS systems.
Further, this errant Check-In application system doesn't re-connect even after full reboot. And neither does a DataEntry application re-connect on that PC. That is unless I first start a POS process on it... After starting it, BOTH DataEntry and Check-In (in either order) can be started/restarted with full connectivity.
An odd problem.
Thoughts?
ADVthanksANCE,
miC
CentralRockGym
Comments
The reboot not fixing the problem is very telling that it is either the VPN or one of the MySQL servers *blocking* connections from that machine for some reason. I don't think this has anything to do specifically with the RGP applications.
On each of your servers, look at the my.ini file in c:\program files (x86)\mysql\mysql server and confirm that "skip-name-resolve" is listed in the [mysqld] section.
Hello again AndyL:
Hmm... possibly, but I'm not sure the facts fit that explantion.
If the VPN was an issue, why would the other PCs here not have the problem?
And also, why would the problem go away when then no change was made to VPN?
The problem only was resolved by starting the POS application before bringing up that Check-In application on that particular WinXP PC. (this done 3x in a row on same day -- I was trying to reproduce the problem and succeeded each time).
I've checked that skip-name-resolve directive and it's there on the running servers.
I would agree that the :3306 might be blocked somehow by the 'missing' server but I noted pairs of ESTABLISHED :3306 to each of the servers from each of the workstations -- I'll reproduce the issue yet again and provide the evidence of this if you'd like.
It's not a huge issue since we have a workaround -- simply telling the staff to start the POS application and re-starting the Check-In when the problem is seen. But, since an RGP behavior like this clears the problem it does feel like an RGP issue.
Regards,
michael grimes
Michael,
POS/CheckIn/DataEntry are all the same application just with different shortcuts. All the database initialization code is - literally - identical. There is no difference between launching Check In and Launching POS.
My suspicion is MySQL or the VPN is blocking that machine specifically for some reason. And my biggest guess is MySQL. There is something about the sequence of events of that machine connecting that is causing MySQL to stop accepting connections (or, very probably, hang with a connection) from that machine.
Touchstone runs 8 locations with a huge mix of Win7 and XP machines without this problem, thus I don't believe XP has anything to do with the issue either.
Next time it happens, before doing ANYTHING else..... try connecting to the remote MySQL servers directly from that machine outside of RGP. To do that..
* Download Navicat FREE on that machine
* When the problem occurs, fire up Navicat and attempt to make a connection to each of the servers (New Connection in Navicat)
* I suspect you will find you can't connect from Navicat to one (or both) of the remote servers
If RGP is failing to connect, yet Navicat can concurrently connect... than there problem obviously lies with RGP. But if Navicat can't connect either, then we know there is some type of connection problem.
Hope this helps
Also, look in the my.ini file and make sure max_connections is set to a very large number
(1000+) on all of the servers.
looks like it was the MySQL .ini setting.
If failed to reproduce for me today.
Checked .ini on the HADLEY server -- the one that was failing to connect to our WorcesterCheckIn system -- and it was max_connections=100
I'll increase to 1000 and double check the other servers.
Thanks, Andy -- great support as always!
miC
Just a reminder that you'll need to restart the MySQL service to have any changes take effect after modifying the INI file.
Please sign in to leave a comment.