Your browser was unable to load all of the resources. They may
have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.
QB: 7.04 with Mysql db
Quite often, especially when I trigger manually a new build, steps fail with this error: "is failed: could not extract ResultSet".
It happened on "Checkout" step once and many times on "trigger" steps.
Could you explain when this error comes up?
Can you please show me the detailed error in build log?
Unfortunately the log does not say more than:
"Step XXX is failed: could not extract ResultSet"
Even with the Build log level set to "Debug level".
OK... I don't if it's the same problem, but another configuration raised this execption :
"org.hibernate.exception.JDBCConnectionException: could not extract ResultSet"
And again to another place, the configuration shows this :
"2017-03-06 14:02:12 - could not extract ResultSet
caused by: Could not send query: unexpected end of stream, read 0 bytes from 4"
Maybe our database is dying :(
Maybe our database is dying :(
I'd like to suggest you to start a new instance with a fresh database to see whether the error persists.
Same issue again 6 months later: "is failed: could not extract ResultSet" especially when calling a "trigger" step.
Creating a new DB fixed the problem but it happens again. I have to create a new fresh DB.
Do you have any idea what could cause the corruption?
We use QB 7.0.20 and a Mysql DB. Its size is around 900Mb when corruption appears.
Do you think we should switch to another DB (SQL Server for instance)?
900M is not that large. Looks like some of the pooled connections to MySQL has some issues. Does restart of QB server help?
Thanks for the quick reply.
Actually we were so persuaded that this issue was related to the DB that we didn't try to restart the server before creating a new DB...
After fixing the issue with a new DB, we made some tests to check the integrity of the supposed corrupted DB but didn't find any errors. So you're maybe right, just restarting the server would have probably fixed our problem.
We'll try this option if it happens again.
If you have more information about this error or any suggestions, let me know.
Googled around and found that this might be caused by timed out MySQL connections. Please add below to <QB server>/conf/hibernate.properties to test connections before using:
After changing this, restart QB server.
Thanks a lot for the suggestion. I'll add that.
We had the problem again today, but this time we also get the error: "Already have an associated managed connection"
Step 'master>== Targets>== Noblob>== Perforce>Sync code (do not unshelve)' is failed: Already have an associated managed connection
15:24:15,604 ERROR 15:24:15,604 TRACE - Stack trace for the failure
15:24:15,604 ERROR com.pmease.quickbuild.RemotingException: Already have an associated managed connection
15:24:15,604 ERROR at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:65)
15:24:15,604 ERROR at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162)
15:24:15,604 ERROR at com.pmease.quickbuild.persistence.SessionInterceptor.invoke(SessionInterceptor.java:77)
15:24:15,604 ERROR at com.pmease.quickbuild.entitymanager.impl.DefaultIdManager.getId(DefaultIdManager.java:42)
It seems something went wrong on the QB server that didn't close a transaction.
We had to restart our server to fix the problem.
Any errors printed in server log?
Right... I forgot to share the server log. Sorry.
I sent it by email because it is quite long.
It happened again... 2 years later (QB 8.20).
After deleting a configuration, the server logged this exception:
2019-08-01 16:51:08,989 [qtp1141797772-8570018] ERROR com.pmease.quickbuild.web.WicketConfig - Error handling wicket request.
org.apache.wicket.WicketRuntimeException: Method onLinkClicked of interface org.apache.wicket.markup.html.link.ILinkListener targeted at [ [Component id = deleteConfiguration]] on component [ [Component id = deleteConfiguration]] threw an exception
2019-08-01 16:51:08,992 [qtp1141797772-8570018] WARN com.mchange.v2.c3p0.impl.NewPooledConnection - [c3p0] A PooledConnection that has already signalled a Connection error is still in use!
2019-08-01 16:51:08,997 [qtp1141797772-8570018] WARN com.mchange.v2.c3p0.impl.NewPooledConnection - [c3p0] Another error has occurred [ java.sql.SQLNonTransientConnectionException: (conn=43188288) Connection is closed ] which will not be reported to listeners!
java.sql.SQLNonTransientConnectionException: (conn=43188288) Connection is closed
After this exception the configuration was still present in the tree and the user had to delete it again.
From that moment, many builds anywhere in QB started failing with the error "could not extract ResultSet" and we had to restart the server to fix the issue.
We have checked our DB's integrity and everything is ok.
It's not the first time we have a problem after deleting a configuration and each time we have to restart the server.
Here are the server logs with callstacks. Hope it'll help.
Looks like you are using MariaDB JDBC connection, which has some issues according to our supporting experience. If you are using MySQL, make sure to use the official MySQL jdbc driver.
That really look like to be an unhanded exception, or the SQL connection may be not closed properly into a finally block.
Indeed, the following exceptions are "A PooledConnection that has already signalled a Connection error is still in use!".
This mean that a connection in error can be used in all other calls, that produce mandatory server restart.
Seeing the stack trace, it should be around the Delete configuration methods.
Do you have bugfix around that topic in next versions ?
Here the QuickBuild server is at version at 8.0.20.
This error occured after a delete configuration action.
This feature might be very long to execute (several minutes and may be more).
Do you have improvement in next versions concerning that ?
QB closes connection after deleting the configuration. There might be some issues when the underlying c3p0 connection pool interacting with the JDBC drivers. As I mentioned in previous post, please switch to use MySQL official jdbc driver to see if the problem still exist if you are using MySQL database, as we've observed occasional database connection issues using MariaDB on some sites.
I want to support Robin's position - we are using MariaDB in our environment, but had what looked like data corruption.
Switching to use the MySQL dialect and drivers to talk to MariaDB resolved our issues.