I can't help you with your PHP issues. That sounds strange to me as I don't think that such loops and heavy processing is implemented in our plugin.
To reduce logging output you have to change the settings in the file "logback-config.xml" it is situated in webapps/openmeetings/WEB-INF/classes/ comparable to: https://svn.apache.org/repos/asf/incubator/openmeetings/trunk/singlewebapp/WebContent/openmeetings/WEB-INF/classes/logback-config.xml Change: <root> <level value="DEBUG"/> <appender-ref ref="FLOG2"/> <appender-ref ref="CONSOLE2"/> </root> To: <root> <level value="WARNING"/> <!--- or ERROR --> <appender-ref ref="FLOG2"/> <appender-ref ref="CONSOLE2"/> </root> Sebastian 2012/8/20 Luke Ledgerd <[email protected]>: > > OM list: > > If you search for an existing meeting when creating a new meeting, it > can cause a race condition that takes down the webserver... At least in > my case. > > Humm.. that's not right. SugarCRM seems to run fine with everything > else. I don't use a php opcache, because I know it doesn't play nice > with the threaded php model I'm using (at least in the short term - and > besides it performs well). > > "GET > /sugar/cache/jsLanguage/openmeetings/en_us.js?v=iMjYhjAUH0YotcqG1cZeKw > HTTP/1.1" 200 711 > > Result: Webserver only goes out to lunch. Session dead. > > PID USER NR NI VIRT RES SHR S CPU MEM TIME COMMAND > 3217 apache 20 0 783m 156m 8912 S 99.7 10.5 8:31.31 apache2 > > What do you think the culprit could be. My webserver or some kind of php > endless loop? Scripts can run for up to 5-10 mins in my configuration > (due to SugarCRM upgrades / installs / large queries / batch jobs etc), > so I'm expecting it to unlock itself in another 10 mins or so. > > Cheers, > > Luke > > The new openmeetings nightly build works great however. I just would > like to know how to dial-down the debugging a little bit and then we are > ready for production ;) > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
