You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Enke Michael <Mi...@wincor-nixdorf.com> on 2002/01/17 15:45:48 UTC
Improved the feeled performance!
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.
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.
I hope this helps.
I prepared AbstractTextSerializer to get the time in milliseconds
from cocoon.xconf, the name is "flush-time", default is 500, values below 100 are set to 100,
value of 0 means no flushing.
But I have no idea how to setup, what to put in cocoon.xconf.
Do I have to put AbstractTextSerializer into cocoon.roles???
Attached the diff and a new class for cocoon/serialization
Regards,
Michael
Re: Improved the feeled performance!
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>
> Stefano Mazzocchi wrote:
>
> > Thanks for the patch, but now I wonder: should we make this a more
> > general component?
> >
> > I mean, sort of a 'heartbeat' thread in background does all sort of
> > time-dependent things (cleaning up the cache, flush buffers, and so on)
> >
> > What do you people think?
>
> I am working on that in Excalibur. This is the whole push for asynchronous
> management I have been trying to sell everyone on. I already have some
> Queues set up that are very efficient, the next part is writing the code
> that manages the CommandQueue using a ThreadPool. The implementation will
> allow for 3 types of "Commands" to be run:
>
> 1) Run now commands--add the callback to the queue and at the next oportunity
> we execute the command (run only once).
> 2) Delayed run-once commands--add the callback to the queue and after a
> specified period of time we execute it.
> 3) Repeated delayed commands--add the callback to the queue and after a
> specified period of time we execute it. After that we place it back
> in the queue with the new delay.
>
> Commands in case 1 would be like asynchronous initialization code. It is
>
> feasible to have a finite number of threads initializing all the components
> asynchronously. This would speed the overall setup time for Cocoon. Some
> Components are quick to set up, while others are more expensive.
>
> Commands in case 2 would be for cache management, or automatically expiring
> a resource after a certain period of time.
>
> Commands in case 3 would be for routine maintenance of pools, etc.
>
> This is also part of a generic Container implementation that I am creating
> that takes advantage of all this power--and makes it easier to create
> new Containers.
Way Cool.
Please, let us know when you are finished and how to use it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Improved the feeled performance!
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> Thanks for the patch, but now I wonder: should we make this a more
> general component?
>
> I mean, sort of a 'heartbeat' thread in background does all sort of
> time-dependent things (cleaning up the cache, flush buffers, and so on)
>
> What do you people think?
I am working on that in Excalibur. This is the whole push for asynchronous
management I have been trying to sell everyone on. I already have some
Queues set up that are very efficient, the next part is writing the code
that manages the CommandQueue using a ThreadPool. The implementation will
allow for 3 types of "Commands" to be run:
1) Run now commands--add the callback to the queue and at the next oportunity
we execute the command (run only once).
2) Delayed run-once commands--add the callback to the queue and after a
specified period of time we execute it.
3) Repeated delayed commands--add the callback to the queue and after a
specified period of time we execute it. After that we place it back
in the queue with the new delay.
Commands in case 1 would be like asynchronous initialization code. It is
feasible to have a finite number of threads initializing all the components
asynchronously. This would speed the overall setup time for Cocoon. Some
Components are quick to set up, while others are more expensive.
Commands in case 2 would be for cache management, or automatically expiring
a resource after a certain period of time.
Commands in case 3 would be for routine maintenance of pools, etc.
This is also part of a generic Container implementation that I am creating
that takes advantage of all this power--and makes it easier to create
new Containers.
--
"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
Re: Improved the feeled performance!
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerhard Froehlich wrote:
>
> >-----Original Message-----
> >From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >Sent: Thursday, January 17, 2002 6:28 PM
> >To: cocoon-dev@xml.apache.org
> >Subject: Re: Improved the feeled performance!
> >
> >
> >Enke Michael wrote:
> >>
> >> 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.
> >
> >Uh, yeah, didn't know we had such a big buffer....hmmmm...
> >
> >> 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.
> >> I hope this helps.
> >> I prepared AbstractTextSerializer to get the time in milliseconds
> >> from cocoon.xconf, the name is "flush-time", default is 500, values below 100 are set to 100,
> >> value of 0 means no flushing.
> >> But I have no idea how to setup, what to put in cocoon.xconf.
> >> Do I have to put AbstractTextSerializer into cocoon.roles???
> >>
> >> Attached the diff and a new class for cocoon/serialization
> >
> >Thanks for the patch, but now I wonder: should we make this a more
> >general component?
> >
> >I mean, sort of a 'heartbeat' thread in background does all sort of
> >time-dependent things (cleaning up the cache, flush buffers, and so on)
> >
> >What do you people think?
>
> How about using the StoreJanitor Thread? You can configure the interval in
> cocoon.xconf file. So we don't have to add a new Thread.
I was proposing exactly this: unifying all 'clock-depending' events into
a single 'hardbeat' thread where components can register to have their
own 'interrupt' executed.
It's for sure more elegant than what we have today.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Improved the feeled performance!
Posted by Gerhard Froehlich <g-...@gmx.de>.
>-----Original Message-----
>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>Sent: Thursday, January 17, 2002 6:28 PM
>To: cocoon-dev@xml.apache.org
>Subject: Re: Improved the feeled performance!
>
>
>Enke Michael wrote:
>>
>> 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.
>
>Uh, yeah, didn't know we had such a big buffer....hmmmm...
>
>> 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.
>> I hope this helps.
>> I prepared AbstractTextSerializer to get the time in milliseconds
>> from cocoon.xconf, the name is "flush-time", default is 500, values below 100 are set to 100,
>> value of 0 means no flushing.
>> But I have no idea how to setup, what to put in cocoon.xconf.
>> Do I have to put AbstractTextSerializer into cocoon.roles???
>>
>> Attached the diff and a new class for cocoon/serialization
>
>Thanks for the patch, but now I wonder: should we make this a more
>general component?
>
>I mean, sort of a 'heartbeat' thread in background does all sort of
>time-dependent things (cleaning up the cache, flush buffers, and so on)
>
>What do you people think?
How about using the StoreJanitor Thread? You can configure the interval in
cocoon.xconf file. So we don't have to add a new Thread.
Gerhard
--------------------------
Hey! It compiles! Ship it!
--------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Improved the feeled performance!
Posted by Stefano Mazzocchi <st...@apache.org>.
Enke Michael wrote:
>
> 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.
Uh, yeah, didn't know we had such a big buffer....hmmmm...
> 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.
> I hope this helps.
> I prepared AbstractTextSerializer to get the time in milliseconds
> from cocoon.xconf, the name is "flush-time", default is 500, values below 100 are set to 100,
> value of 0 means no flushing.
> But I have no idea how to setup, what to put in cocoon.xconf.
> Do I have to put AbstractTextSerializer into cocoon.roles???
>
> Attached the diff and a new class for cocoon/serialization
Thanks for the patch, but now I wonder: should we make this a more
general component?
I mean, sort of a 'heartbeat' thread in background does all sort of
time-dependent things (cleaning up the cache, flush buffers, and so on)
What do you people think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Improved the feeled performance!
Posted by Enke Michael <Mi...@wincor-nixdorf.com>.
Berin Loritsch wrote:
>
> Enke Michael wrote:
>
> > Vadim Gritsenko wrote:
> >
> >>Hi Enke,
> >>
> >>
> >>>From: Enke Michael [mailto:Michael.Enke@wincor-nixdorf.com]
> >>>
> >>>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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Improved the feeled performance!
Posted by Vadim Gritsenko <va...@verizon.net>.
> 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
Re: Improved the feeled performance!
Posted by Berin Loritsch <bl...@apache.org>.
Enke Michael wrote:
> Vadim Gritsenko wrote:
>
>>Hi Enke,
>>
>>
>>>From: Enke Michael [mailto:Michael.Enke@wincor-nixdorf.com]
>>>
>>>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.
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Improved the feeled performance!
Posted by Enke Michael <Mi...@wincor-nixdorf.com>.
Vadim Gritsenko wrote:
>
> Hi Enke,
>
> > From: Enke Michael [mailto:Michael.Enke@wincor-nixdorf.com]
> >
> > 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."
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.
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>
> ...
Regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Improved the feeled performance!
Posted by Vadim Gritsenko <va...@verizon.net>.
Hi Enke,
> From: Enke Michael [mailto:Michael.Enke@wincor-nixdorf.com]
>
> 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.
> 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.
> I hope this helps.
> I prepared AbstractTextSerializer to get the time in milliseconds
> from cocoon.xconf, the name is "flush-time", default is 500, values
below 100
> are set to 100, value of 0 means no flushing.
> But I have no idea how to setup, what to put in cocoon.xconf.
Take a look at the AbstractTextSerializer's configure() method, and
follow the code for the buffer-size parameter.
> Do I have to put AbstractTextSerializer into cocoon.roles???
No, there is no need.
Regards,
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org