Mit freundlichen Grüssen / With best regards Uwe Feil
Jetsam Service Management GmbH Telefon +49 (0) 941 89849 628 Mobile: +49 (0) 151 151 92 782 Fax: +49 (0) 84 42/92 71 - 6807 Web: http://www.jetsam-services.de eMail: uwe.f...@jetsam-services.de Geschäftsführer: Josef Raith, Uwe Feil Amtsgericht Ingolstadt, HRB 6014 USt-IdNr.: DE278228824 Impressum: http://www.rts-services.de/impressum/jetsam.php -----Ursprüngliche Nachricht----- Von: Mikael Kurula [mailto:alcar...@gmail.com] Gesendet: Montag, 10. Dezember 2012 13:57 An: openmeetings-user@incubator.apache.org Betreff: Re: Dealing with MySQL timeouts Hi again! Now I had no problems with recordings and mysql timeouts, even if I don't think the OM server has been used for days. Anyway, since poor reliability was the only reason for me to switch away from the previous web conference software I was using, I'm not happy with the prospect of losing OM-recordings because of mysql timeouts. Therefore I now ask: why is mysql recommended? What are the drawbacks of using the default derby persistence? Another question: I find it a bit difficult to follow the discussions here in the mailing list. Besides, this seems to be a clear bug, not an issue about how to use OM. Should I file a bug report in the issue tracker? Also, after some testing I might have a few other bugs and feature requests to report. Friendly greetings, Mikael On 2012.4.12, at 10:44, Mikael Kurula wrote: > That's unfortunate... 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 > > Mikael > > > On 4 December 2012 10:16, Maxim Solodovnik <solomax...@gmail.com> wrote: > 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-tomca > t-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 >
