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 :(
On Tue, Dec 4, 2012 at 3:03 PM, Mikael Kurula <alcar...@gmail.com> wrote: > Good morning! > > Very nice to see that this issue generates interest. 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? > > Friendly greetings, > Mikael > > > > On 3 December 2012 20:08, Mahmut TEKER <teker.mah...@gmail.com> wrote: > >> Hi, >> >> 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? >> >> Thanks, >> >> _Mahmut >> >> >> On 12/3/2012 2:25 PM, Mikael Kurula wrote: >> >>> Hi again! >>> >>> >>> Today I have another question. As I understand, it is recommended to >>> integrate OpenMeetings with MySQL. This I did, but it seems I 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 found rather conflicting information on the appropriateness of setting >>> autoReconnect=true when I googled. What is the recommended way of dealing >>> with this in OpenMeetings? >>> >>> >>> 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. >>> >>> >>> Id' be most grateful for any help! >>> >>> Mikael >>> >>> >>> >>> >> > -- WBR Maxim aka solomax
