[ 
https://issues.apache.org/jira/browse/OPENMEETINGS-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509787#comment-13509787
 ] 

Clifton Kazocha commented on OPENMEETINGS-270:
----------------------------------------------

Hi Sebastian,

I am also experiencing this problem. One of our users is able to get this to 
happen reliably. They are using Sun Java 7 on Windows Vista. I set up a VM that 
matched this users computer and wasn't able to get OM2 stuck in the loop. I set 
up a remote session with this users to see that they weren't doing anything 
unusual to cause the issue. It could be a red herring but it seemed like I only 
got the loop when making a recording while screen sharing was turned on. I 
killed all processes on the users system that weren't essential to windows and 
after that I could successfully make recordings.

The cause seems to be something on the client side but I haven't been able to 
cause this issue on any other computer. I've tested in Linux, OS X, Win XP, Win 
Vista, and Win 7.

I had Openmeetings 2.0 installed on Ubuntu 10.04 but after a successful 
upgraded to 12.04 the issue persists. FFmpeg was compiled from the latest 
source.

I hope this info helps!

Thanks,
Clif
                
> MemoryLeak / Dead-Lock in FlvRecorderConverter
> ----------------------------------------------
>
>                 Key: OPENMEETINGS-270
>                 URL: https://issues.apache.org/jira/browse/OPENMEETINGS-270
>             Project: Openmeetings
>          Issue Type: Bug
>    Affects Versions: 2.0 Apache Incubator Release
>            Reporter: SebastianWagner
>            Assignee: SebastianWagner
>            Priority: Critical
>             Fix For: 2.1 Apache Incubator Release
>
>
> DEBUG 05-15 16:08:19.955 FlvRecorderConverter.java 113480470 96 
> org.openmeetings.app.data.flvrecord.converter.FlvRecorderConverter 
> [taskExecutor-4] - ### Stream not yet written Thread Sleep -
> => The Thread does sleep endlessly. We need to find out what causes that 
> error and how we can prevent it.
> First of all a more detailed trace is needed to identify those recording_Ids 
> that are broken to try to find out what happened and how long the Converter 
> hands in the loop.
> It can be criticial if it turns out that there is a general issue with the 
> recording there.

--
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

Reply via email to