I was trying to record screen (without sharing) many times. After stopping recording I had started it again immediately. One record was around 5-10 minutes. Suddenly I saw this repeated message in the log: "### Stream not yet written Thread Sleep - ...". Size of the cache file (.ser) was not changed, profiler showed that recording thread was doing nothing. It was happening around 20-30 minutes, after that I shutdown the server. It looks like that the queue was empty but "stop" method was not called for some unknown reason.
2013/1/31 [email protected] <[email protected]>: > Hi Artyom, > > thanks for providing more details but actually that is still not enough :) > What was the _exact_ use-case? > What revision are you exactly using? > How many participants have been in the conference room? > Did you start screensharing and recording or only screensharing? > What was the duration of the screensharing? > How did you stop the screensharing (by hitting the stop button, by closing > the screensharing window without hitting the stop button beforehand, by > leaving the conference room, by shutting down the client computer, by > disconnecting the network cable from the computer, ...)? > > > I doubt "stopRecordingShow" was not called. Actually the "endless" Loop is > already part of the logic that is called _after_ "stopRecordingShow" was > called. > The "endless" loop should simply not take "endless". It is normal that it > should loop, depending on the length of the video and the server spec, > maybe 1 minute per 10 minutes recording. Occassionally under high load the > "looping" might be longer. But at "some time" the stream should be > completely written to the disc so we can continue to produce the resulting > video from it. > > Maybe there is some misunderstanding in the way the stream is written to > the disk: The stream is written "async" to the disc. Otherwise it would > lock the entire server. So every stream-packet that the server "records" > from the stream will be copied in a separated Thread. This Thread queue's > the packets and writes them to disc. > The reason for doing that is that writing to disc is a CPU intensive thing > and it takes way longer then "real-time". So after you've recorded / hit > the stop button, there might be still some packets in the "queue" and the > post-processing will "loop" until it detects that the Thread that writes > packets to disc is finished. > > One of those Writer Threads is for example the > org.apache.openmeetings.data.flvrecord.listener.async.StreamVideoWriter > which extends the BaseStreamWriter > In BaseStreamWriter there is a attribute called > private final BlockingQueue<CachedEvent> queue = new > LinkedBlockingQueue<CachedEvent>(); > > This is the queue. All packets will be copied to this queue while you do a > recording. > > And if you look at the "run" method in BaseStreamWriter, the run method > will run as long as the queue is not empty. > Once the queue is empty "public void closeStream()" will be called. > And in StreamVideoWriter this abstract method "closeStream" is overwritten > and the flag "streamReaderThreadComplete" will be set to TRUE upon the end > of the recording. > > So what happens in FlvRecorderConverter.java line 96 is: > if (!flvRecordingMetaDataOfScreen.getStreamReaderThreadComplete()) //check > for that flag "streamReaderThreadComplete" > ... if "streamReaderThreadComplete" is not true Thread.sleep(100 > milliseconds) and try again. > Or in other words: The Post processing of the recording waits until all > stream packets from the recording are written to disc. > > So the question is: Why is your queue never empty? > How long did the loop run? > Did you check also the files in the streams folder, do they grow in since > still or what is their actual size? > > Sebastian > > > 2013/1/31 Artyom Horuzhenko <[email protected]> > >> If you start OM on very slow machine (I used Intel Atom 1.6 GHz) and >> begin to record high resolution video (1680x1050) you have a chance to >> reproduce this bug. There a lot of other interesting things appears >> sometimes. Hanged thread is just one of them. >> >> 2013/1/31 [email protected] <[email protected]>: >> > Sorry that is a vague pointer or doubt that you raise her. We can't fix >> > anything based on that. >> > Is there any way to reproduce it? >> > >> > Sebastian >> > Am 31.01.2013 18:49 schrieb "Artyom Horuzhenko" <[email protected]>: >> > >> >> There were no exceptions and no data to record to the disk. Please >> >> have a look at the "stopRecordAndSave" method in the >> >> "FLVRecordingService" class. Is it possible that "stopRecordingShow" >> >> didn't call because some of checks didn't pass? >> >> >> >> 2013/1/31 [email protected] <[email protected]>: >> >> > Or like Maxim said, an exception while recording. However I >> understood it >> >> > like you had no exception just the endless loop. >> >> > >> >> > Sebastian >> >> > >> >> > >> >> > 2013/1/31 [email protected] <[email protected]> >> >> > >> >> >> It means that the write to disk task is slower then the data stream >> >> input. >> >> >> There is a Thread.sleep in the processing of the recording that >> >> >> waits >> >> >> until all bytes are written to disk. >> >> >> I have occasionally seen issues with the detection of the end of >> >> >> the >> >> >> video-stream/recording but I never was able to reproduce it. >> >> >> Have you a stable way to reproduce that issue? >> >> >> >> >> >> Sebastian >> >> >> >> >> >> >> >> >> 2013/1/31 Artyom Horuzhenko <[email protected]> >> >> >> >> >> >>> Hello people! >> >> >>> I had a situation when BaseStreamWriter thread wasn't stopped on >> time >> >> >>> and did nothing, but a user already had stopped recording. Also I >> got >> >> >>> many messages to the log: "### Stream not yet written Thread Sleep >> >> >>> - >> >> >>> ...". Does anybody know the possible reason of this issue? >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Sebastian Wagner >> >> >> https://twitter.com/#!/dead_lock >> >> >> http://www.webbase-design.de >> >> >> http://www.wagner-sebastian.com >> >> >> [email protected] >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Sebastian Wagner >> >> > https://twitter.com/#!/dead_lock >> >> > http://www.webbase-design.de >> >> > http://www.wagner-sebastian.com >> >> > [email protected] >> >> >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected]
