I know this sort of question has been asked for a few times, I read some of them but did not get any smarter.
My Java application is connecting to a database server via JDBC through a SSH Tunnel. The tunnel is opened once at beginning. When starting I opened the database connection everytime it is used. Due to changes in the app I needed the connection opened on startup and decided to keep it open until my application is closed. When I close the app I sometimes, not always, get following error:
- Could not retrieve transation read-only status server
java.sql.SQLException: Could not retrieve transation read-only status server
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 369.901 milliseconds ago. The last packet sent successfully to the server was 8 milliseconds ago.
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
Could this be because of the always open database connection? I test the application only for short times. It will run on 4 computers all day long. Can I expect this error more often then? The connection is used every few minutes, so it should be more performant to keep it open, but maybe during break it is not used for half an hour.
What would you recommend me to do? Always reopen the connection or keep it like it is and find a workaround when I get this error? Do you maybe have another idea why this error appears?
Just ask if you need more error log, database code or whatever you need.
Thanks!
I'm going to say yes, your issue is probably due to the fact that you have a persistent connection open.
I took over a website a while ago and the guy before me had the same idea: Open a single connection, send the queries through it when needed, and never close it. A month after I took over the site, the database wouldn't return any more query results just like this.
As a general rule of thumb and for good programming practice, always clean up after yourself. If you're not using a variable, set it to null and delete it. Not using a connection? Terminate it. This is way less prominent in Java than it is in C++ as Java does all the cleaning up for you for the most part.
Related
This question already has answers here:
FtpClient storeFile always return False
(5 answers)
Closed 1 year ago.
I have a Java program that uploads new/changed files to my Web site via FTP. It currently uses the Apache Commons Net Library, version 3.8.0.
After moving to a new city, the program, which I’ve been using for almost 20 years, began failing. It still connects to the FTP server and signs in successfully. But when it tries to upload a file, it pauses for 20-30 seconds, then fails. It always fails on the first file, 100% of the time.
The failing call is to org.apache.commons.net.ftp.FTPClient.storeFile(). The documentation says storeFile() turns True if successfully completed, false if not. Curiously, the method is also documented to throw various forms of IOException. The documentation doesn’t say when or why the method decides to return a boolean versus throwing an exception.
My problem is that storeFile() is returning a false (indicating failure), and never throws an exception. So, I have no error message to tell me what caused the failure. File name & path look OK. The Web hosting company tried to determine why the failure was occurring, but was unsuccessful.
This problem has been going on for weeks now. Anyone have any ideas on how to debug this?
If the cause of your problem is moving to a new city, and you can still open the control connection, the most likely culprit is a change to your underlying ISP and network that is blocking the data transfer stream from opening.
FTP port 21 is used for opening connections and is normally allowed by all networks but then a new, random, unprivileged port is negotiated over the control connection and then used for the actual DATA transfers. I bet your "storeFile()" is trying to open a data connection and hitting a block which is probably causing a timeout. You may be interpretting this as "never throws an exception" but in reality it might throw a Timeout Exception after you sit around and wait long enough.
One thing I would recommend is find a way to have your FTP client use PASSIVE mode for the FTP data transfer. This is designed into the protocol to avoid these types of problems. You can read about it in detail on the wiki https://en.wikipedia.org/wiki/File_Transfer_Protocol under "Communications and Data Transfer"
I run a java programm and try to use it with a hosted DB, I run the Vserver ubuntu 12.04 with Mysql myself, full root-access.
I changed the my.cnf to have more resources.
When I start the application it is fast, hardly any difference to a local database.
My problem is that after a while of inactivity the program freezes probably because the connection dropped.
There is no entry in any errorlog. If I kill the application and restart it, it is working again, nothing else but kill works, it is a linuxPC.
I used ?autoReconnect=true but I am not sure this is correct, the tables are innodb.
Does anyone have an idea how to avoid the connection to drop or how to make sure a reconnection is made?
PS [17.12.2015]
?autoReconnect=true was removed
today I got some details after a long wait
com.openbravo.basic.BasicException:
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 2.435.471 milliseconds ago. The last packet sent successfully to the server was 959.832 milliseconds ago.
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
Communications link failure
The last packet successfully received from the server was 2.435.471 milliseconds ago. The last packet sent successfully to the server was 959.832 milliseconds ago.
java.net.SocketException:
Is this what happens when wait_timeout is too short?
After the "error" the program worked again!
Your question lacks specific info, but I guess what is happen. MySQL Server has a parameter called wait_timeout (See official doc).
When you have a connection that exceed that timeout, MySQL will close it, and if you don't manage SQLExceptions properly, your application will have problems.
You can try to increase wait_timeout or review your connection code to manage exceptions, but both are workarounds.
I wouldn't recommend you to relay on autoReconnect as an alternative for any problem, instead it would be better to encapsulate connection management into business logic in order to manage open/close connection every time you need. Maybe connection pooling can help you.
I mean, when you call a business method from you UI (it doesn't mind if it is web, ws, desktop or whatever) you have to manage open connection and start transaction, (and other cross cutting concerns as authorization, audit, log, ...). During all businesses logic, control possible exceptions, commit or rollback and free resources.
If you post some code, you will get more specific answers.
Hope it helps!
autoReconnect is dangerous for InnoDB. When the connection is lost in the middle of a transaction the previous actions in the transaction are rolled back. But the code proceeds to run as if the transaction continues. This can lead to subsequent writes not being consistent with the rolled back data.
You would be better off recognizing the lost connection and restarting the transaction.
I have to maintain java code that is timing out with a sql call. The error is:
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: communications link failure
The last packet successfully received from the server was 7706,043 milliseconds ago. The last packet sent succesfully to the server was 2 milliseconds ago.
I think the program is doing as it should. It actually takes 2 hours to process the full return value from the sql call! I've already written a patch which would fix the timeout issue, and other issues, but it would be a month before we can release it to the production servers.
In the meantime is there a way I can configure the JDBC to use a longer timeout window? I can't touch the code, but is there any way I can use either properties files or a command-line argument to configure the default JDBC timeout?
This can be done by updating the URL that is used to connect to SQL. The exact arguments used to expand the URL depend on which DB is connected to, but this webpage presents them in detail:
http://www.cubrid.org/blog/dev-platform/understanding-jdbc-internals-and-timeout-configuration/
Here is a copy of the relevant facts;
mysql: jdbc:mysql://xxx.xx.xxx.xxx:3306/database?connectTimeout=60000&socketTimeout=60000 (in ms)
mysql (jtds) jdbc:jtds:sqlserver://server:port/database;loginTimeout=60;socketTimeout=60 (in sec)
I am trying to insert the tens of millions of data into oracle database by through java application but after 850k data inserted I am getting the error:
java.sql.exception: IO Exception :Connection reset by peer socket
write error.
I have a similar issue in my aplication.
In my case, after a few minutes in which the connection has not used, oracle server resets the connection and when I had to use it again, this exception was thrown.
I found that the problem was that oracle sets the timeout for connection at 10 minutes in sqlora.net file.
Maybe you can try to increase this time interval or check if the connection is still valid instead to check if it is closed (a connection can be not valid even if it is not closed).
The last option works fine for me.
I hope this helps.
My java application does use DB Connection pooling. One of the functionality started failing today with this error:
[BEA][SQLServer JDBC Driver]No more data available to read
This doesn't occur daily. Once I restart my application server things look fine for some days and this error comes back again.
Anyone encountered this error? Reasons might vary, but I would like to know those various reasons to mitigate my issue.
Is it possible that the database or network connection has briefly had an outage? You might expect any currently open result sets then to become invalid with resulting errors.
I've never seen this particular error, but then I don't work with BEA or SQL Server, but a quick google does show other folks suggesting such a cause.
When you're using a connection pool, if you do get such a glitch, then all connections in teh pool become "stale" or invalid. My application server (WebSphere) has the option to discard the entire connection pool after particular errors are detected. The result then is that one unlucky request sees the error, but then subsequent requests get a new connection and recover. If you don't discard the whole pool then you get a failure as each stale connection is used and discarded.
I suggest you investigate to see a). whether your app server has such a capability b). how you application responds if the database is bounced, if this replicates the error then maybe you've found the cause.