Berin Loritsch wrote:
> 
> Enke Michael wrote:
> 
> > Vadim Gritsenko wrote:
> >
> >>Hi Enke,
> >>
> >>
> >>>From: Enke Michael [mailto:[EMAIL PROTECTED]]
> >>>
> >>>Hi people,
> >>>as we have a default Buffer of 8192 byte in the AbstractTextSerializer
> >>>sometimes it takes very long until any result is visible in the
> >>>
> >>browser.
> >>
> >>It is configurable in the sitemap.xmap (or cocoon.xconf in latest CVS).
> >>Use
> >> <buffer-size>512</buffer-size>
> >>parameter to specify buffer size you want.
> >>
> >
> > ok
> >
> >
> >>>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."
> 
> 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.



So the guy(s) who proposed to use the ActiveMonitor didn't understand what I wanted to 
say.
I don't care about Resources, I want to have the top of the html page early in the 
browser
even if the buffer is not filled up and some DB-querys need a long time to give their 
results.
And this is important not only for serialization to html but for all other steps in 
the pipeline too.

Does that mean that the OutputFlusher has no alternative?




> 
> > 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 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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to