Hi Patrik,
Thanks for the help so far. The hint with the classpath for the
mysql-connector.jar solved one problem.
Good.
There's another one causing headakes: Although I use "autoReconnect=true" for
the mysql-connector, backends get disabled after a while (~ within 24 hours)
because of lost connections:
You should avoid the use of the autoReconnect feature (it does not work
with transactions anyway).
Two solutions to your problem:
- increase the wait_timeout value in your MySQL server configuration so
that connections do not expire
- set your minimum pool size (in your ConnectionManager definition) to 0
with an idleTimeout < MySQL(wait_timeout) so that idle connections in
the pool are closed before they timeout.
Let me know if that solves your problem,
Emmanuel
2009-03-25 07:58:43,005 DEBUG backend.DatabaseBackend.node02 Task
KillThreadTask completed
2009-03-25 07:58:43,005 DEBUG backend.DatabaseBackend.node02 arpviewer -
BackendWorkerThread for backend 'node02' with RAIDb level:1 is term
inated
2009-03-25 07:58:43,005 DEBUG backend.DatabaseBackend.node02 Request 'UPDATE usertable SET name = ...' failed on backend node02
but 1 succeeded (com.mysql.jdbc.CommunicationsException: The last packet successfully received from the server was61128 milliseconds ago.The
last packet sent successfully to the server was 61128 milliseconds ago, which
is longer than the server configured value of 'wait_timeout'
. You should consider either expiring and/or testing connection validity before
use in your application, increasing the server configured va
lues for client timeouts, or using the Connector/J connection property
'autoReconnect=true' to avoid this problem.)
com.mysql.jdbc.CommunicationsException: The last packet successfully received
from the server was61128 milliseconds ago.The last packet sent
successfully to the server was 61128 milliseconds ago, which is longer than
the server configured value of 'wait_timeout'. You should cons
ider either expiring and/or testing connection validity before use in your
application, increasing the server configured values for client t
imeouts, or using the Connector/J connection property 'autoReconnect=true' to
avoid this problem.
at
com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1070)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3270)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1932)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2548)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1605)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1524)
at
org.continuent.sequoia.controller.loadbalancer.AbstractLoadBalancer.executeStatementExecuteUpdateOnBackend(AbstractLoadBalancer.j
ava:985)
at
org.continuent.sequoia.controller.loadbalancer.tasks.StatementExecuteUpdateTask.executeInAutoCommit(StatementExecuteUpdateTask.ja
va:224)
at
org.continuent.sequoia.controller.loadbalancer.tasks.StatementExecuteUpdateTask.executeTask(StatementExecuteUpdateTask.java:116)
at
org.continuent.sequoia.controller.loadbalancer.tasks.AbstractTask.execute(AbstractTask.java:141)
at
org.continuent.sequoia.controller.loadbalancer.BackendWorkerThread.run(BackendWorkerThread.java:192)
Caused by: java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3251)
... 10 more
2009-03-25 07:58:43,012 WARN backend.DatabaseBackend.node02 Task execution
failed (java.sql.SQLException: Request 'UPDATE usertable SET name = ...' failed
on backend node02 but 1 succeeded (com.mysql.jdbc.CommunicationsException:
Where should I tune to get rid of this problem?
Patrik
Emmanuel Cecchet wrote:
Patrik,
The controller that has generated the error does not have the MySQL
driver in its classpath.
What is confusing is that Sequoia will automatically scan the
directories in the classpath to find the jars (and you probably have
your MySQL dirver jar file in the drivers/ directory) but JGroups does
not use the Sequoia classloader and it will fail to load a driver class
file if it is not explicitely in the classpath.
You have to explicitly put '/path_to_drivers/mysql-connector-xxx.jar in
the controller classpath to solve that problem.
Hope this helps,
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: m...@frogthinker.org
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
Sequoia@lists.forge.continuent.org
https://forge.continuent.org/mailman/listinfo/sequoia
