cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: Improved the feeled performance!
Date Tue, 05 Feb 2002 14:26:21 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 
> Enke Michael wrote:
> 
> > Vadim Gritsenko wrote:
> >
> >>Hi Enke,
> >>
> >>>From: Enke Michael [mailto:Michael.Enke@wincor-nixdorf.com]
> >>>
> >>>Therefore I introduced an "OutputFlusher" which flushes the
> >>>BufferedOutputStream
> >>>per default every 500 ms. Now the pageheader is shown immediately,
> >>>independent
> >>>of how long it takes to fill 8192 byte.
> >>>
> >>There is one issue with solution you are proposing: It uses one
thread
> >>per serializer in the system. It is not very efficient; better
solution
> >>is to use just one thread to manage all buffers. Such manager is
already
> >>implemented in the Avalon, class ActiveMonitor, and can be applied
to
> >>the monitoring multiple output streams. See avalon.excalibur.monitor
> >>package. And this monitor already declared in the cocoon.xconf - so
it
> >>is ready to use.
> >>
> >
> > As I read the documentation for excalibur.monitor.StreamResource,
there is
> > written:
> > "It can notify the change as soon as the Writer or OutputStream has
been
> > closed."

It can notify when the Resource has been changed. Resource can be pretty
much anything, up to "time when buffer was last flushed", and this
"resource" can return "modified" as soon as some time interval passes.
But this would be incorrect usage of the the monitor, so my suggestion
is wrong. Actually, I messed up some things; it is much better to use
not monitor, but command infrastructure which is not finished in
Excalibur yet. Take a look at the excalibur.command.DelayedCommand in
the scratchpad of the excalibur. This class is exactly what is required
to perform buffer flushing.


> Here is how monitoring works:
> 
> There is 1 thread (read one, 1, uno, aik, I, un) for *ALL* resources
that the
> ActiveMonitor
> checks.  There does not need to be any more than that.  The
PassiveMonitor
> does not even
> issue that many threads.  The difference is that the ActiveMonitor can
detect
> if the resource
> has been changed by an outside system (imagine that!).
> 
> The idea behind a Resource is that the read function does not change
until the
> write is finished.
> Once the resource has been changed, it notifies anything that is
listening to
> its notifications.
> That means that the XSLT Component can use it to mark if the source
XSL
> stylesheets have been
> modified, allowing it to generate a new Templates object for the
source.  That
> way we can come
> up with an efficient means of getting the latest Template without
constantly
> looking for it.
> 
> 
> 
> > But that is the point: I want to push the bytes to the browser (or
the next
> > component
> > in the pipeline) even if the OutputStream is still open.
> 
> That is not what the OutputStream is for.  That particular
OutputStream on the
> StreamResource is
> so you can change the contents of the resource.  Period.  It is not
for
> serializing to the browser.
> That is what the Serializer does, and the Resource was never meant to
take
> that responsibility away.
> 
> > Another Question would be: How to configure. Like This:
> >    <monitor>
> >      <thread priority="5" frequency="10000"/>
> >      <init-resources>
> >        <resource key="...<.W.H.A.T. .H.E.R.E.?>..."
> class="org.apache.avalon.excalibur.monitor.StreamResource"/>
> >      </init-resources>
> >    </monitor>
 
Initial resources - as stated below - have limited usage. You should
register resources dynamically with the monitor. But - as I said above -
it is not required for the subject we are discussing (flushing output
stream).

Vadim

> Initial resources have limited use.  The main reason is that they have
no
> listeners attached to them.
> The key is the same value you would place to look up the resource with
the
> Monitor.  Whatever that is.
> The real use is when you add new resources at runtime or register
listeners
> for a resource at runtime.
> Those listeners are notified at the right time.
> 
> 
> 
> --
> 
> "They that give up essential liberty to obtain a little temporary
safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message