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:[EMAIL PROTECTED]] Sent: vrijdag 10 augustus 2001 6:18 To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
