[
https://issues.apache.org/jira/browse/OPENMEETINGS-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528818#comment-13528818
]
SebastianWagner commented on OPENMEETINGS-488:
----------------------------------------------
Hi Mikael,
that sounds wired indeed, however there is no timeout issue with OpenMeetings.
I have server running for months where customers just don't use it and there is
no such timeout as well as high frequent servers that also run for months
without restarting anything and there is no such issue.
So there must be something special about your setup or database configuration.
And apart from you there is no such report, while there are a lot of
installations online.
There is also nothing from our side that we can do to change this, all
configuration values are actually in the persistence.xml.
OpenMeetings is a pretty standard Spring + OpenJPA application, so you could
also write a Jira issue to OpenJPA "MySQL timeout xyz" ... actually they might
even able to help you more then we can as your issue is all about db
configuration. Or you could use the MySQL forums.
After all there is no issue here that needs a bug report. If you want to
discuss further use the mailing list.
Sebastian
> MySQL timeouts
> --------------
>
> Key: OPENMEETINGS-488
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-488
> Project: Openmeetings
> Issue Type: Bug
> Affects Versions: 2.0 Apache Incubator Release
> Reporter: Mikael Kurula
>
> I sometimes run into problems with MySQL timeouts because of inactivity
> overnight, getting the following error message in the openmeetings.log:
> Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last
> packet successfully received from the server was 90,881,924 milliseconds ago.
> The last packet sent successfully to the server was 90,881,924 milliseconds
> ago. 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 values for client
> timeouts, or using the Connector/J connection property 'autoReconnect=true'
> to avoid this problem.
> I don't know if it is related or not, but these errors showed up when I
> finished a test recording. Then when I tried to go and watch the recording, I
> only get "The recording is not yet ready for watching" and it seems the
> recording didn't consume any disk space.
> I posted this to the openmeetings-user list, and got the following response
> from another user: "There is a connection between this error (or info) and
> recording and sharing of the OM (or I guess like that). I have the same
> problem on recordings and I am taking same response about com.mysql.jdbc...
> kind of reports from the system. I have also checked that
> "autoReconnect=true" option is already given on the connection string and
> also checked the permission or the connection of mysql server but could not
> find a proper solution. Is there a bit more specific information about error
> message?"
> By googling I found these discussions:
> http://wiki.pentaho.com/display/ServerDoc2x/Configuring+for+MySQL
> http://www.coderanch.com/t/564390/Tomcat/CommunicationsException-tomcat-mysql
> I would assume this is the problem. Can the solution outlined in the first
> link solve the problem for OM as well?
> After a while Solomax chimed in with: "We are using OpenJPA (not Hibernate)
> and already have "TestOnBorrow=true" and DB connection pool :(
> not sure what else can be done ... Never saw such exception on my machines :("
> If it's of any help, then I'm using a CentOS 6 server with the following
> version of mysql:
> mysql Ver 14.14 Distrib 5.1.66, for redhat-linux-gnu (x86_64) using readline
> 5.1
> My version of openmeetings is this:
> apache-openmeetings-incubating-2.0.0.r1361497-14-07-2012_1108.tar.gz
> ... and the version of the J connector is mysql-connector-java-5.1.22.tar.gz.
> For the time being I'll try to work around this by switching back to Derby. I
> don't expect a very heavy load and I don't need to query the database while
> OM is running.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
