cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Homeijer <M.Homei...@devote.nl>
Subject RE: IT BREAKS !!! (production workaround)
Date Mon, 13 Aug 2001 07:13:21 GMT
I think the production workaround you mention should be standard available
in Cocoon. Now that we can precompile xsp pages (?), it should not be to
difficult to implement a "precompiled" generator (besides the "serverpages"
generator). All it has to do is map the request onto the precompiled
generator class. That way it will be easier to switch between precompiled
pages and normal pages and we don't need a production war generator.
 
Maybe it will also help to determine were the xsp problem is?
 
Michael Homeijer
 

-----Original Message-----
From: Berin Loritsch [mailto:bloritsch@apache.org]
Sent: vrijdag 10 augustus 2001 6:18
To: cocoon-dev@xml.apache.org
Subject: Re: IT BREAKS !!!


Michael Hartle wrote:
> 
> Hello all,
> 
> I do not want to spoil the party, but today I had a real nightmare
> regarding exactly this topic at a customer's site. On a P3/550 with 128
> MB RAM running a Windows 2000 Server plus MS SQL-Server 8(?), I tried
> every combination of elements from the following categories to get a
> rock stable system setup, without any chance.

I have found that certain things work without hitch (after today's
updates)
and others do not.  I would place Batik at an experimental stage for the
server side.  The reason being is that Batik itself is reliant on the
server's
graphic system--the complexities involved rank this a bad performer and
not suitable for repeated access.  I would recommend serializing the png
or jpg that Batik produces to a file, and serve that up in a production
environment.

I have also found (today) that the XSP system is in serious need of
refactoring.  Again, it is a very complex beast with many moving parts.
There is a memory "leak" in there somewhere, and I am trying to narrow
it
down, but I haven't been able to do that yet.

In order to bypass these issues, I suggest generating the XSP classes
using the command line approach.  Then JAR the resulting classes and
place them in the libs directory.  The painful part is what comes next:
everyplace you use a serverpages generator, you have to replace that
generator with the one created by Cocoon for you.  For example:


<map:generators>
<!-- Remove this:  <map:generator name="serverpages"
class="org.apache.cocoon.generators.ServerPagesGenerator"/> -->
  <map:generator name="specific"
class="org.apache.cocoon.www.file_c_.webapp.cocoon.Specific_xsp"/>
</map:generators>

<!-- skip -->

<map:match pattern="specific.html">
  <map:generator type="specific"/>
  <map:serializer/>
</map:match>


This bypasses the entire XSP system at runtime.  Normal Generators,
Transformers,
Serializers, and Readers all function well under load.  With XML file
generation
through transformation and serialization, I was able to sustain 200
users slamming
my system without problem.  The Batik and XSP subsystems are apparently
fragile though.


Hopefully the XSP system will be able to be repaired and work flawlessly
again soon.
Until then we might need a system to generate a "production" war from a
development
war.  (I.e. makes all the XSP conversions and Batik conversions for
you).

---------------------------------------------------------------------
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


Mime
View raw message