I'm currently querying a huge Firebird (v2.5) table (with millions of rows) in order to perform some row-level operations. To achieve that, the code is using chunking from Laravel 5.1, somewhat like this:
DB::connection('USER_DB')
->table($table->name)
->chunk(min(5000, floor(65500/count($table->fields))), function($data) {
// running code and saving
});
For some reason, I keep receiving the following error:
SQLSTATE[HY000]: General error: -902 Error reading data from the connection.
I've already tried changing chunk size, and different codes, but the error still appears. Sometime it happens at the beginning of the table, and sometimes after parsing several hundred-thousands or even millions rows. The thing is that I need to parse only the rows in this transaction (so I can't stop and reopen the script).
Tested for memory on the server (running on different place than the database), and it is not using nearly anything of it.
While writing this, I rechecked the Firebird log and found the following entry:
INET/inet_error: read errno = 10054
As far as I could find, this isn't actually a Firebird problem, but a winsock reset error, is that correct? If so, how could I prevent this from happening during the chunk query? And how can I check if that is a problem with windows or the firewall?
Update I
Digging on the firebird2.5.log on the PHP server, found this errors:
INET/inet_error: send errno = 104
REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
I have found the root of my problem. The thing is that the server was resetting the connection. In order to avoid that, I added a "heartbeat" query to run every few minutes. With this strategy I was able to prevent the connection from being reset.
Related
Have a docker container build using php-ssh2. php version 7.2 When trying to use
$con = ssh2_connect('hostname');
I am getting Error starting up SSH connection(-43): Failed getting banner . Interesting thing is 43 here. Whats the significance of 43. What does that mean? Also any idea how to fix this? There is no heavy load, running connection manually.
Deepdive into libssh2
This number -43 is an error code that comes directly from libssh2, specifically LIBSSH2_ERROR_SOCKET_RECV. The Failed getting banner message is the dynamic error message that accompanies the error code. These two pieces of information give the location where this error is thrown, namely in the receive_banner.
Underlying problem
It was the result of the socket throwing a receive error when libssh2 tried to read from it as part of initialising your SSH session. Either the server is misconfigured and is not sending a banner or the underlying connection disconnected for some reason.
Solution
The best course of action seems to have adequate retrying in place for these kinds of errors. You are connecting to a network which is an action that can fail. As the number of servers you are connecting to increases, you are going to run into errors that are a result of the underlying network. Adequate error handling is your best course of action.
You can find how to set exception handlers from the PHP docs.
Very simple-to-explain problem here (at least after struggling with it and simplifying it almost up to the absurd).
I do a connection via the OCI driver inside a file called whatever.Test.php. Just that, make a simple query, and exit. I then call the file from the browser, and the data taken from the database is properly displayed. Next step: I run PHPUnit over the same file, with the following result:
PHP Warning: oci_connect(): ORA-12154: TNS:could not resolve the connect identifier specified in ...
Any ideas?
The final solution was a little bit obvious once I came up with it. Somehow the server could figure out what the server I was trying to connect with was, via the tnsnames.ora file somewhere, I guess. However, since the script execution doesn't trigger all the server processes this information was not reachable any more from there. So what I needed to do is to provide all the data in the oci_connect() $connection_string parameter, using the format [//]host_name[:port][/service_name][:server_type][/instance_name] (check documentation). Previously I was only giving the host_name part.
(Thanks anyway for your reply, user*).
I'm building a web app that uses lots of requests to my database. Every thing was working perfectly smooth until a half an hour ago when the requests weren't returning... I checked the PHP file directly and it displays the following:
<br />
<b>Warning</b>: mysql_connect() [<a href='function.mysql-connect'>function.mysql-connect</a>]: Too many connections in <b>/home/sanity/public_html/dev/forest/js/database.php</b> on line <b>7</b><br />
Unable to connect to MySQL
So I figured let's check phpMyAdmin, but it's not showing me ANYTHING except for a big red box that says:
SQL query: Edit Edit
SET CHARACTER SET 'utf8';
MySQL said: Documentation
#1045 - Access denied for user 'root'#'localhost' (using password: NO)
Between the last time it worked and now I haven't changed any configurations or code.. How do I begin to fix this?
Could this be caused by the fact my PHP files don't close the connection after using it? If so should I be closing the connection after every query? I figured the connection would close automatically when the user leaves the web site.
EDIT: The requests are sending through now and phpMyAdmin is back up, but how do I prepare this site for heavier traffic?
When I started my job, one of my first tasks was to continue working on what one of the directors had started coding. In his code, I saw this monstrosity:
function getTicket($id) {
mysql_connect("localhost","username","password");
mysql_select_db("database");
$sql = mysql_query("select * from tickets where id = ".intval($id));
return mysql_fetch_assoc($sql);
}
In other words, he was creating a whole new database connection every single time he wanted something from the database, and never closing any of them (instead letting them be closed at the end of the script automatically)
This was fine for basic testing, but as soon as I started writing more advanced stuff (before I'd discovered this piece of code) things majorly screwed up with the same "too many connections" error as you.
The solution was simple: restart the server to clear all pending connections, and fix the code to only connnect once per script execution.
This is what you should do. There should only ever be one call to mysql_connect (or indeed any database library's connect function) in your script (and I don't mean in a function that gets called several times!)
You should also check the database's configuration, just in case someone accidentally set the maximum connections too low, but generally this shouldn't be a problem if you manage your connections properly.
Though the mysql_* functions are deprecated (use a modern driver like PDO for instance), you should take a look at the mysql_close($con) function.
Here is the doc.
EDIT
If you are not using mysql_pconnect function, then your connection should be closed at the end of the execution of your script.
Apparently, one reason for such error is shared hostings. If you are using a shared hosting, generally speaking, the maximum connections to the server allowed by the hosting is not the greatest.
If you can change the max_connections system variable then try to change it to a greater number:
max_connections = 200
Getting the error sporadically:
"Failed to acquire exclusive database access"
in my PHP application on the live server.
Can't see anything in the logs.
Checked the server settings and:
max_connections: 100
max_user_connections: 0
As I understand from the documentation the 0 means no limit and is the default.
Anyone got any ideas?
Thanks.
I used to see an error similar to this all the time in Access but haven't seen it with MySQL before. I don't think your max_user_connections is the problem because the key word in that error message is "exclusive" meaning you need to have the ONLY access to a table.
My guess would be it's something with InnoDB and its locking mechanism. If you don't require transaction safe records, try switching your table to MyISAM and see if the error persists.
Take a look here for InnoDB locking:
http://dev.mysql.com/doc/refman/5.0/en/innodb-locks-set.html
I'm connecting to an ftp server that I have no control over, and I'm pretty sure is using something old and outdated due to other issues I've run into.
I'm simply using this code in a loop to get all the files in a directory.
ftp_get($this->conn_id, $remote, $local, FTP_ASCII);
The first time all goes well, but after that I get this error thrown for each file I try to get: "There is already an active transaction"
I've tried both passive & active, as well as a nonblocking get with no luck. It's the exact same code I use to connect to other FTP servers and get files with no problem.
edit: Oddly enough, closing the connection, sleeping 3 seconds, and creating a new connection between each get yields the same results...
EDIT: Solved. Turns out that despite the errors, the files are still being got. The catch block was just catching the error so I didn't realize it. I'll just ignore that error.
Try using ftp_fget instead and saving the file before trying to get another one.
It seems like "There is already an active transaction" may mean it is still transfering data when you try to use that connection again. Maybe use a sleep() function after puts and gets to give the transaction time to finish and see if that makes a difference. You shouldn't have to do that for php but I would try it just to rule it out as a possible issue.