Re: BaseStreamWriter thread didn't stop
The reason is endless loop because of exception while recording of something like that. We should investigate it and get rid of endless loop On Thu, Jan 31, 2013 at 12:31 PM, Artyom Horuzhenko wrote: > 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? > -- WBR Maxim aka solomax
Re: BaseStreamWriter thread didn't stop
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 seba.wag...@gmail.com : > 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 seba.wag...@gmail.com > >> 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 >> >>> 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 >> seba.wag...@gmail.com >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > seba.wag...@gmail.com
Re: BaseStreamWriter thread didn't stop
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" : > 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 seba.wag...@gmail.com : > > 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 seba.wag...@gmail.com > > > >> 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 > >> > >>> 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 > >> seba.wag...@gmail.com > >> > > > > > > > > -- > > Sebastian Wagner > > https://twitter.com/#!/dead_lock > > http://www.webbase-design.de > > http://www.wagner-sebastian.com > > seba.wag...@gmail.com >
Re: BaseStreamWriter thread didn't stop
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 seba.wag...@gmail.com : > 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" : > >> 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 seba.wag...@gmail.com : >> > 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 seba.wag...@gmail.com >> > >> >> 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 >> >> >> >>> 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 >> >> seba.wag...@gmail.com >> >> >> > >> > >> > >> > -- >> > Sebastian Wagner >> > https://twitter.com/#!/dead_lock >> > http://www.webbase-design.de >> > http://www.wagner-sebastian.com >> > seba.wag...@gmail.com >>
Re: BaseStreamWriter thread didn't stop
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 seba.wag...@gmail.com : > 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 queue = new > LinkedBlockingQueue(); > > 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 > >> 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 seba.wag...@gmail.com : >> > 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" : >> > >> >> 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 seba.wag...@gmail.com : >> >> > 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 seba.wag...@gmail.com >> >> > >> >> >> It means that the write to disk task is slower then the data stream >> >> input. >> >> >> There is a Thread.sl
