@jbrosenberg: the existing flush mechanism is meant pretty much just for unit tests (package protected method flush()). It has extra tooling to communicate from one thread over to the background thread. To implement a 10 second flush in the writer thread, there is no need to synchronize between threads and block the sender thread the way that SpeedTracerLogger.flush() does.
@tobyr: The flush is once every 10 seconds. If there is no data in the buffer, flush should be a no-op. Does that really sound burdensom? I don't think this flush is the same as an OS level sync to disk - its just pushing the buffered data out from the JVM buffers into the OS. void java.io.Writer.flush() throws IOException Flushes the stream. If the stream has saved any characters from the various write() methods in a buffer, write them immediately to their intended destination. Then, if that destination is another character or byte stream, flush it. Thus one flush() invocation will flush all the buffers in a chain of Writers and OutputStreams. If the intended destination of this stream is an abstraction provided by the underlying operating system, for example a file, then flushing the stream guarantees only that bytes previously written to the stream are passed to the operating system for writing;* it does not guarantee that they are actually written to a physical device such as a disk drive.* If we don't do this flush, you can't look at the log while the app is running - the data just stays buffered until enough data fills the buffer or the app closes. In my case, I wanted to look at DevMode while DevMode was still running. On Wed, Feb 23, 2011 at 1:16 PM, Toby Reyelts <[email protected]> wrote: > I'm concerned about how this might impact logging results. For example, even > if the results are written out on a separate thread (and assuming the box > has an entirely free processor to deal with it), you can still cause the > disk to be busy with I/O during the writes, slowing down the real time of > the even thread if it's also doing I/O. Basically, we already have enough > problems with reproducible results, so I hate the idea of adding even more > non-deterministic behavior to the mix. > > On Wed, Feb 23, 2011 at 11:30 AM, <[email protected]> wrote: >> >> Chris, the problem Eric is trying to address here is that you are not >> always guaranteed to get the shutdown sequence cleanly when you quit the >> app, so this helps insure that data will be written out. >> >> Although, I'm wondering if 10 seconds is too long, Eric, how about 5 >> seconds? >> >> >> >> http://gwt-code-reviews.appspot.com/1361801/diff/1/dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java >> File >> >> dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java >> (right): >> >> >> http://gwt-code-reviews.appspot.com/1361801/diff/1/dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java#newcode352 >> >> dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:352: >> public void run() { >> Might it be a bit cleaner, to use a java.util.Timer, and have it >> periodically call flush()? This way, there's no separation between the >> flush mechanism that's there, and this new auto-flush feature. (In >> looking at it, might need to make the flushLatch thread conscious, a >> separate issue here). >> >> http://gwt-code-reviews.appspot.com/1361801/ >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > > -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
