Re: BaseStreamWriter thread didn't stop

["seba.wagner@gmail.com" <se...@gmail.com>]

Okay,

thanks for the details Artyom. We will have to look at it more detailed and
try to reproduce it.
Did the error also happen if you completely shut down the screensharing
client and goto the recordings UI and watch the recording (so you make sure
that one recording is produced completely before you start the next one).
Otherwise this sounds for me like the possible bug in our code.

Sebastian


2013/1/31 Artyom Horuzhenko <ak...@gmail.com>

> 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.wagner@gmail.com <se...@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<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 <ak...@gmail.com>
> >
> >> 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.wagner@gmail.com <se...@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" <ak...@gmail.com>:
> >> >
> >> >> 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.wagner@gmail.com <se...@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.wagner@gmail.com <se...@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 <ak...@gmail.com>
> >> >> >>
> >> >> >>> 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.wagner@gmail.com
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Sebastian Wagner
> >> >> > https://twitter.com/#!/dead_lock
> >> >> > http://www.webbase-design.de
> >> >> > http://www.wagner-sebastian.com
> >> >> > seba.wagner@gmail.com
> >> >>
> >>
> >
> >
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com