Re: [IMP] Releasing 2.1.7 on Tuesday

[Carsten Ziegeler]

Sylvain Wallez wrote:
> 
> Who did some extensive tests on the candidate release?
> 
> So far, nobody provided some feedback on either successful or 
> unsuccessful testing and IMO we should not make a release unless we have 
> a reasonable number of positive tests being reported.
> 
Don't we all test? Isn't no negative news good news? :)

As always, I will start a quick vote on monday, if we want to release
the current svn. And if someone is against it, we will not release. It's
that simple. So in fact, the vote can be compared with positive/negative
tests. But if you have any suggestions to improve the process, feel free
to do what you think is right.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [IMP] Releasing 2.1.7 on Tuesday

[Reinhard Poetz]

Bertrand Delacretaz wrote:
Le 17 mars 05, à 23:18, Sylvain Wallez a écrit :
...Who did some extensive tests on the candidate release?

I did run the automated tests (both junit and anteater) successfully on 
macosx / JDK 1.4.2, all successful (except the flowscript-reload test 
which sometimes passes and sometimes fails on macosx, I've seen this 
before but haven't investigated deeper).
While developing with a 3 weeks old SVN version, I noticed similar problems with 
flowscript reload. I'm working with win2k and jdk 1.4.2. I don't have 
investigated this deeper either.

--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: [IMP] Releasing 2.1.7 on Tuesday

[Bertrand Delacretaz]

Le 17 mars 05, à 23:18, Sylvain Wallez a écrit :
...Who did some extensive tests on the candidate release?
I did run the automated tests (both junit and anteater) successfully on 
macosx / JDK 1.4.2, all successful (except the flowscript-reload test 
which sometimes passes and sometimes fails on macosx, I've seen this 
before but haven't investigated deeper).

I also checked the samples of some blocks: fop, jfor, slop, itext, 
forms, tour, chaperon, profiler, in the same environment.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: building docs in 2.2.0

[David Crossley]

Reinhard Poetz wrote:
> Upayavira wrote:
> >David Crossley wrote:
> >>Upayavira wrote:
> >>>Bertrand Delacretaz wrote:
> Jeremy Quinn a ?crit :
> 
> >Do you know if there will continue to be xml docs in the build?
> 
> AFAIK it's still being discussed, see the recent "automatically 
> generating docs" thread.
> >>>
> >>>I would be reluctant to see the online docs go. It would be a shame, 
> >>>as it does demonstrate one particular use case for Cocoon, and as 
> >>>Jeremy says, it is useful in places, e.g. in testing or demonstrating 
> >>>the CLI.
> >>>
> >>>However, the docs are changing shape quite a bit, and for there to be 
> >>>a Cocoon based dynamically generated docs within the distribution, I 
> >>>take it someone would have to in some senses rewrite Forrest! Or at 
> >>>least put together some simple sitemaps to make the content as it is 
> >>>structured show up as sensible HTML.
> >>
> >>I cannot understand what you are saying there. Rewrite Forrest?
> >
> >Well, kinda yes.
> >
> >Basically, if we're going to have dynamic docs within Cocoon, we need 
> >"something" that can display the source documents that we have. And I 
> >don't know what that "something" is. Otherwise, we'll have to start 
> >distributing a static version of the site with our distributions.
> 
> Rewriting Forrest sounds like a big waste of time. Why can't we integrate 
> Forrest? AFAIK the Lenya project wants to go this way - this should work 
> for us as well.

So that sounds like a Cocoon Block for Forrest. Mmmm, i cannot
get my head around that one. We would be pleased to have you
clever dudes help.

The excellent plugins infrastructure that Ross has been spearheading
is very quickly reducing the Forrest core. We have the plugins
deployed at apache.org and users can automatically download just the
bits that they require. Looking good.

--David

Re: [IMP] Releasing 2.1.7 on Tuesday

[Sylvain Wallez]

Carsten Ziegeler wrote:
Hi,
due to the infraton over the weekend where svn etc. will not be
available for some time, I'm planning to delay the release of 2.1.7 for
one day and release on tuesday instead of monday.
So we have the whole monday to do final work - if required.
 

Who did some extensive tests on the candidate release?
So far, nobody provided some feedback on either successful or 
unsuccessful testing and IMO we should not make a release unless we have 
a reasonable number of positive tests being reported.

Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled

[Sylvain Wallez]

Linden H van der (MI) wrote:
Ok. He can add whatever attribute to his styling, the stylesheets are 
   

True.
 

built for this, but I don't want to see this "readonly" attribute 
handled in the stylesheets, as we have other mechanisms for 
this, namely widget states.
   

Agree, however, "readonly" is part of the HTML textarea specification.
IIRC there is a slight difference between "disabled" and "readonly". The
first one is addressed by widget states, the latter is not.
 

Reading the HTML spec [1], the difference between disabled and readonly are:
- readonly is only available on  and . disabled is 
available on all controls
- readonly sends back the value to the server, which is of no use if the 
widget is not active
- readonly inputs receive focus and are includes in tab navigation. 
What's the purpose of this is the value can't be changed?

The HTML disabled state seems to me to match closely with the CForms 
disabled state, as it applies to a wider range of controls and doesn't 
send back the value to the server.

Now if people want to use HTML readonly, they can do it on active 
widgets (which won't loose their value because it's sent back) by adding 
a . This works because the stylesheets 
copy verbatim their unknown attributes to the produced HTML element.

Now from a security POV, using HTML readonly is risky as nothing 
prevents the value to be modified before being sent back, either by some 
injected javascript (very hyped nowadays to hack gmail and google maps) 
or some forged request.

Sylvain
[1] http://www.w3.org/TR/html401/interact/forms.html#h-17.12
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: Cocoon Performance Woes, Is it flow? I don't know!

[Jorg Heymans]

Eric E. Meyer wrote:
Also, for curiosity, I re-ran the tests with the embedded form in the 
search results page removed. That had a positive impact on performance:

A while ago i had performance problems using the bindings. My post at 
[1] contains a few things to watch out for when combining CForms with 
database retrieval code.

MTH
Jorg
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109603234405613&w=2

DO NOT REPLY [Bug 25102] - RawRequestParameterModule don't work correctly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25102





--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 22:57 ---
My solution was to create a parameter encoding module, I won't contribute it
because it is only a partial implementation.  More discussion on this issue can
be found here: http://marc.theaimsgroup.com/?t=10700291361&r=1&w=4

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

Re: Accessors (was Re: Adding cocoon.suicide() to the FOM API.)

[Daniel Fagerstrom]

Ralph Goers wrote:
Daniel Fagerstrom wrote:
Ralph Goers wrote:

Is this what I hope it means?  If it is, then I hope to see classes 
like Request, Session, Context, etc. be modified to implement the 
interface.  To me, this would mean that they implement a static get 
method that returns the appropriate instance of the object.  Perhaps 
a better name for this would be Accessible.  I guess your plan is to 
implement a separate Accessor class to do this instead?
I'm not geting what your aim at, could you tell a little bit about how 
you want to use the accessores so that I can understand why you prefer 
such a solution compared to the component based approach that we have 
discussed.
Actually, a couple approaches have been mentioned.  As I understand 
them, they are:
1.   Have a global "component object model" that everything is anchored 
in and accessed through.
Like FOM which in turn is modeled after the browser object model in web 
browsers. Part of the idea IIRC was that it should be natural to used 
for people who had used JS in browsers.

Frankly, I see this as a bad idea that needs 
to go away - at least the accessing part.  There are so many reasons why 
this is awful that I don't even want to start listing them. But just for 
a start, it is hardly object oriented as it makes the component object 
model have to know way too much.
It data oriented rather than object oriented. If that is good or bad 
depends on your perspective. For accessing the kind of data that we have 
in FOM it is OK for me. So I guess that you have to list some of your 
agruments anyway if you want me to understand why its awful.

2.  Have an Accessor interface, presumably with a class that implements 
it for each type of object to be accessed, such as RequestAccessor, 
SessionAccessor, etc.  In and of itself, this isn't a bad idea.  It just 
isn't necessary, in my opinion.

When I was working on my last portal enhancements, I was frustrated that 
I couldn't get ahold of some of the objects I needed.  The "right way" 
would have required that I make some of the classes implement Avalon 
interfaces which, of course, meant adding more definitions to 
cocoon.xconf.  This is frustrating when all you want is to the reference 
to some other object, but to get it you have to have a Context or a 
service manager.  It would be much more convenient for a lot of objects, 
as well as many flow applications, to be able to just do:
Object.getInstance();
Ok, if your webapps contains a lot of custom Java code I can understand 
that the Avalon way can be frustrating. The webapps that we build where 
I work contains very small amounts of custom Java code. For us having 
things configurable is an advantage rather than the opposite.

This places the burden for locating the correct object instance on the 
object itself which, in my opinion, is where it belongs.  It also allows 
the object to use any number of techniques to locate the correct 
instance; it can retrieve it from the object model, from the component 
manager, or whatever.
I don't know, IOC component managers where IIUC invented because some 
people had bad experiences with the scalability for direct object 
access. I have used that paradigm for so long that I don't remember what 
problems I might have had before ;) But I think Cocoon is easier to use 
and maintain if we follow the same design patterns everywhere.

Don't you think some of the problems that you describe above becomes 
smaller if we introduce the possibility to use modern containers like 
Spring and Hivemind in application code, like Carsten proposed?

I don't see the accessors as a general way to integrate business objects 
in Cocoon but just as a evolution of the input/output module concept 
that is better adapted to the needs in templates and flow and not only 
to the needs for the sitemap.

Furthermore, it allows one to write something 
like ${Request} in a template or flowscript and have that be replaced 
with a reference to the correct object instance.
How does the template know in what package to find the Request object? 
And how does it know if it should use the http or command line variant?

I get the feeling that one have to rebuild quite a lot of the 
architecture that we already have from Avalon if we follow the 
X.getInstance() way.

Is that clearer?
It is. But to me it seem like we are attacking different problem areas, 
and I'm not certain that they should be solved with the same tool.

/Daniel

Re: Cocoon Performance Woes, Is it flow? I don't know!

[Eric E. Meyer]

Reinhard Poetz wrote:
Eric E. Meyer wrote:
Cocoon Performance Woes, Is it flow? I don't know!

CForms, Javascript flow, mix of JX template generators, XInclude
transformer and custom generator transformers. Core application
components implemented in Java. Hibernate persistence.

Do you use jxmacros in your cforms templates? I remember of some 
performance tests a few months ago that revealed problems when 
jxmacros are used. As I've never used jxmacros in production, I'm not 
sure if this was a problem in my tests or if it is a real existing 
problem.

No, we are not using jxmacros. The JX is really just to parameterize 
xincludes into our top-level page template.

Ralph Goers wrote:
Also, that seems like a high number of users for such a little amount 
of memory.  You may just be garbage collecting a lot. 
On Linux, with 1G physical, 512M mx,ms and verbose:gc, I did not see any 
excessively long garbage collection cycles. On Windows, with mx256M, I'm 
generally seeing short incremental GC cycles around 50ms, but I did see 
one 11 second full GC during my last run.  But the deployment machine is 
much beefier (and the VM memory allocation twice the size). I'll 
re-verify on the Linux server.

Also, for curiosity, I re-ran the tests with the embedded form in the 
search results page removed. That had a positive impact on performance:

With refine-search form:
users overall home  search1 search2 search3  detail  total
 avg ms  page   num reqs
10  486208  637588 644 355500
20 1704378 2684   18372875 745500
30 3725682 5987   462662701059450
4019461   141136021  23089   347262059600
5072942   3213   130482  90993  1316668356500
Without refine-search form:
10 645 518  646725 711 627500
20 800 266 11169631024 629500
302539 634 4451   30033908 698450
4047161430 6936   482980402347600
507978132813063   8669   141222710500
Regards,
Eric Meyer

Re: Cocoon Performance Woes, Is it flow? I don't know!

[Antonio Gallardo]

Hi Eric:

I have no time now to read all the answer you got. Some points:

1. java 1.4.2_06 is buggy -> update to 1.4.2_07
2. Flow is slow is FUD. I recently read a comparision between diferent
scripting languages and rhino is the fastest one. The performance is very
good. So I don't think Flow can be a bottleneck.
3. Maybe this could help, but not sure: Yesterday I compiled a new version
of xalan. I also put the target of all the code to java 1.3 innstead of
the default (java 1.1) and just replacing the lib seems like the same
application is noticeable faster. I want to update cocoon with this newer
xalan version but cannot update right now (freeze time before release).

Maybe later today I can find more time to see to the problem closer and
perhaps give you some more advices.

Please give my greetings to JP. ;-)

Best Regards,

Antonio Gallardo.



On Jue, 17 de Marzo de 2005, 11:30, Eric E. Meyer dijo:
> Cocoon Performance Woes, Is it flow? I don't know!
>
> Hello all,
>
> My team developed and deployed a web application for a client which is
> built on top of Cocoon (www.fivestaralliance.com).
>
> I have spent over two weeks now attempting to improve the
> performance and scalability of the application – with some real
> improvements. However, I continue to feel like I'm flying blind –
> because the apparent bottlenecks are somewhere outside of my code. I
> have read a number of previous debates about javascript flow being slow,
> and we are using CForms with Javascript flow, but my main concern is
> that I cannot determine where the bottlenecks are.
>
> Even when the application is bogging down, the components that my team
> wrote are performing their tasks (generation, transformation,
> flowscripting) at very fast rates (as seen by tracing/logging), but
> something else in the framework/process is bogging down the requests.
> The analysis tools don't show any obvious resource limitation even at
> the highest loading levels.
>
> Some pages in the site scale quite well, while one in particular does
> not scale well at all. While I know that I'm close to having a system
> that runs blindingly fast, I'm currently faced with a situation where I
> cannot effectively argue that the architecture isn't "fundamentally
> flawed" and I'm unable to address a major scalability concern for my
> client. I would welcome any concrete suggestions on how to better
> determine my bottlenecks and any additional tuning advice.
>
> Brief description of the application architecture
>
> CForms, Javascript flow, mix of JX template generators, XInclude
> transformer and custom generator transformers. Core application
> components implemented in Java. Hibernate persistence.
>
> Profiling and Monitoring
>
> My biggest problem is that I've only been able to determine where the
> problem isn't at this point. I've used a variety of tools to attempt to
> see what's going on, and why the application is bogging down, but I
> cannot seem to get a comprehensive picture of what delays/bottlenecks
> there are within Cocoon.
>
> Specifically, it would be extremely helpful to monitor the number of
> generators/transformers/other pooled components in use, allocated, freed
> while under load. Additionally, it would be useful to see the time taken
> up by each of the steps in the process of servicing a request – not just
> the set-up and generation/transform times as shown by the Cocoon profiler.
>
> These are the tools/approaches that I have used:
>
> Multi-thread load test with JMeter.
> Profiling of application code using JProbe (CPU and memory analysis).
> Profiling of Cocoon components using Cocoon pipeline profiler.
> Monitoring of Cocoon components using the Cocoon instrumentation client.
> Monitoring of Cocoon server using Status generator.
> Monitored Linux system activity with SAR, iostat, mpstat and vmstat
> during load-testing.
> Profiling of custom generators, transformers and flowscript using
> Jakarata Commons StopWatch and log statements.
>
> Tweaks made thus far
>
> Adjusted Java virtual machine parameters
>   -server -Xms512M -Xmx512M
> Adjust logging levels - turned down logging
> Adjusted thread pool sizes in Tomcat
>   150 -> 350 max
> Adjusted database connection pool size up to 50
> Adjusted sitemap component pool sizes up
> Optimized some Java code based upon JProbe profiling
> Added additional objects to the in-memory cache to reduce database queries
> Turned off reloading of sitemaps and javascript files
> Replaced default Cocoon JCS cache with Whirlycache
> Replaced default Cocoon Xalan XSL transformer with faster Saxon XSL
> transformer
> Configured Cocoon to reuse XML parsers
> Removed Cocoon store janitor
> Preloading key OO javascript flowscript at server startup
>
> Observations
>
> Windows XP
> Pentium 4 1.8Ghz
> JDK 1.4.2_06
> Tomcat 5.0.28
> Cocoon 2.1.5.1
> 512MB physical RAM
> JVM -server -Xms256M -Xmx256M
>
> Load test with num users threads each making 5 successive request in a
> loop with approxim

Re: Cocoon Performance Woes, Is it flow? I don't know!

[Bertrand Delacretaz]

Le 17 mars 05, à 18:30, Eric E. Meyer a écrit :
...Some pages in the site scale quite well, while one in particular 
does
not scale well at all..
Did you try to run tests on just that page, many same requests, and try 
removing components from the page generation path, one after the other?

This should help you isolate the component that causes the problem, to 
narrow your search.

You could also create a request-specific logger, one for each request, 
store it in the request context and use it to log times at various 
stages, with a unique request ID. This would help find worst case 
times.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: building docs in 2.2.0

[Reinhard Poetz]

Upayavira wrote:
David Crossley wrote:
Upayavira wrote:
Bertrand Delacretaz wrote:
Jeremy Quinn a ?crit :

Do you know if there will continue to be xml docs in the build?

AFAIK it's still being discussed, see the recent "automatically 
generating docs" thread.

I would be reluctant to see the online docs go. It would be a shame, 
as it does demonstrate one particular use case for Cocoon, and as 
Jeremy says, it is useful in places, e.g. in testing or demonstrating 
the CLI.

However, the docs are changing shape quite a bit, and for there to be 
a Cocoon based dynamically generated docs within the distribution, I 
take it someone would have to in some senses rewrite Forrest! Or at 
least put together some simple sitemaps to make the content as it is 
structured show up as sensible HTML.

I cannot understand what you are saying there. Rewrite Forrest?

Well, kinda yes.
Basically, if we're going to have dynamic docs within Cocoon, we need 
"something" that can display the source documents that we have. And I 
don't know what that "something" is. Otherwise, we'll have to start 
distributing a static version of the site with our distributions.
Rewriting Forrest sounds like a big waste of time. Why can't we integrate 
Forrest? AFAIK the Lenya project wants to go this way - this should work for us 
as well.

--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Cocoon Performance Woes, Is it flow? I don't know!

[Reinhard Poetz]

Eric E. Meyer wrote:
Cocoon Performance Woes, Is it flow? I don't know!

CForms, Javascript flow, mix of JX template generators, XInclude
transformer and custom generator transformers. Core application
components implemented in Java. Hibernate persistence.
Do you use jxmacros in your cforms templates? I remember of some performance 
tests a few months ago that revealed problems when jxmacros are used. As I've 
never used jxmacros in production, I'm not sure if this was a problem in my 
tests or if it is a real existing problem.

--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: building docs in 2.2.0

[Upayavira]

David Crossley wrote:
Upayavira wrote:
Bertrand Delacretaz wrote:
Jeremy Quinn a ?crit :

Do you know if there will continue to be xml docs in the build?
AFAIK it's still being discussed, see the recent "automatically 
generating docs" thread.
I would be reluctant to see the online docs go. It would be a shame, as 
it does demonstrate one particular use case for Cocoon, and as Jeremy 
says, it is useful in places, e.g. in testing or demonstrating the CLI.

However, the docs are changing shape quite a bit, and for there to be a 
Cocoon based dynamically generated docs within the distribution, I take 
it someone would have to in some senses rewrite Forrest! Or at least put 
together some simple sitemaps to make the content as it is structured 
show up as sensible HTML.

I cannot understand what you are saying there. Rewrite Forrest?
Well, kinda yes.
Basically, if we're going to have dynamic docs within Cocoon, we need 
"something" that can display the source documents that we have. And I 
don't know what that "something" is. Otherwise, we'll have to start 
distributing a static version of the site with our distributions.

Regards, Upayavira

Re: Cocoon Performance Woes, Is it flow? I don't know!

[Colin Paul Adams]

Rhyme error:

this should be:

"Cocoon Performance Woe, Is it flow? I don't know!"

:-)
-- 
Colin Paul Adams
Preston Lancashire

Re: Cocoon Performance Woes, Is it flow? I don't know!

[Ralph Goers]

Also, that seems like a high number of users for such a little amount of 
memory.  You may just be garbage collecting a lot.

Eric E. Meyer wrote:
Observations
Windows XP
Pentium 4 1.8Ghz
JDK 1.4.2_06
Tomcat 5.0.28
Cocoon 2.1.5.1
512MB physical RAM
JVM -server -Xms256M -Xmx256M
Load test with num users threads each making 5 successive request in a
loop with approximately 3 second think time between requests. No derived
resources – only the main page.
users overall home  search1 search2 search3  detail  total
  avg ms  page   num reqs
10  486208  637588 644 355500
20 1704378 2684   18372875 745500
30 3725682 5987   462662701059450
4019461   141136021  23089   347262059600
5072942   3213   130482  90993  1316668356500
home page: /
search1: /luxury_hotels/europe__france__paris/index.html
search2: /luxury_hotels/bahamas_%26_the_caribbean/beach_resort/index.html
search3:
/luxury_hotels/europe__france__paris/city_centre_location/index.html
detail: /luxury_hotel/new_york,_ny/the_carlyle
Platform:
Development
Windows XP
JDK 1.4.2_06
Tomcat 5.0.28
Cocoon 2.1.5.1
Deployment
Linux 2.6.x
We see similar degradation on Linux as on Windows.
The home page has no flowscript or cforms, but does have jxtemplate
generation, xinclude, xslt, and a custom generator.
The search and detail pages include a cform, and are therefore driven
with flowscript at the top-level matching (and create continuations in
the process of displaying their forms). These pages use jxtemplate
generation, xinclude, xslt, custom generation, custom transformation,
and internal-only sub pipelines. When looking at the pipeline times with
a profiling pipeline, the total times (while under load) are much higher
that the displayed times for the setup and generation steps -- so where
is the time going?
Regards,
Eric Meyer

Re: Cocoon Performance Woes, Is it flow? I don't know!

[Ralph Goers]

JProbe doesn't give you an indication as to what methods most of the 
time is spent in?  That should be extremely helpful.

Eric E. Meyer wrote:
These are the tools/approaches that I have used:
Multi-thread load test with JMeter.
Profiling of application code using JProbe (CPU and memory analysis).
Profiling of Cocoon components using Cocoon pipeline profiler.
Monitoring of Cocoon components using the Cocoon instrumentation client.
Monitoring of Cocoon server using Status generator.
Monitored Linux system activity with SAR, iostat, mpstat and vmstat
during load-testing.
Profiling of custom generators, transformers and flowscript using
Jakarata Commons StopWatch and log statements.
Regards,
Eric Meyer

Cocoon Performance Woes, Is it flow? I don't know!

[Eric E. Meyer]

Cocoon Performance Woes, Is it flow? I don't know!
Hello all,
My team developed and deployed a web application for a client which is 
built on top of Cocoon (www.fivestaralliance.com).

I have spent over two weeks now attempting to improve the
performance and scalability of the application – with some real
improvements. However, I continue to feel like I'm flying blind –
because the apparent bottlenecks are somewhere outside of my code. I
have read a number of previous debates about javascript flow being slow,
and we are using CForms with Javascript flow, but my main concern is
that I cannot determine where the bottlenecks are.
Even when the application is bogging down, the components that my team
wrote are performing their tasks (generation, transformation,
flowscripting) at very fast rates (as seen by tracing/logging), but
something else in the framework/process is bogging down the requests.
The analysis tools don't show any obvious resource limitation even at
the highest loading levels.
Some pages in the site scale quite well, while one in particular does
not scale well at all. While I know that I'm close to having a system
that runs blindingly fast, I'm currently faced with a situation where I
cannot effectively argue that the architecture isn't "fundamentally
flawed" and I'm unable to address a major scalability concern for my
client. I would welcome any concrete suggestions on how to better
determine my bottlenecks and any additional tuning advice.
Brief description of the application architecture
CForms, Javascript flow, mix of JX template generators, XInclude
transformer and custom generator transformers. Core application
components implemented in Java. Hibernate persistence.
Profiling and Monitoring
My biggest problem is that I've only been able to determine where the
problem isn't at this point. I've used a variety of tools to attempt to
see what's going on, and why the application is bogging down, but I
cannot seem to get a comprehensive picture of what delays/bottlenecks
there are within Cocoon.
Specifically, it would be extremely helpful to monitor the number of
generators/transformers/other pooled components in use, allocated, freed
while under load. Additionally, it would be useful to see the time taken
up by each of the steps in the process of servicing a request – not just
the set-up and generation/transform times as shown by the Cocoon profiler.
These are the tools/approaches that I have used:
Multi-thread load test with JMeter.
Profiling of application code using JProbe (CPU and memory analysis).
Profiling of Cocoon components using Cocoon pipeline profiler.
Monitoring of Cocoon components using the Cocoon instrumentation client.
Monitoring of Cocoon server using Status generator.
Monitored Linux system activity with SAR, iostat, mpstat and vmstat
during load-testing.
Profiling of custom generators, transformers and flowscript using
Jakarata Commons StopWatch and log statements.
Tweaks made thus far
Adjusted Java virtual machine parameters
-server -Xms512M -Xmx512M
Adjust logging levels - turned down logging
Adjusted thread pool sizes in Tomcat
150 -> 350 max
Adjusted database connection pool size up to 50
Adjusted sitemap component pool sizes up
Optimized some Java code based upon JProbe profiling
Added additional objects to the in-memory cache to reduce database queries
Turned off reloading of sitemaps and javascript files
Replaced default Cocoon JCS cache with Whirlycache
Replaced default Cocoon Xalan XSL transformer with faster Saxon XSL
transformer
Configured Cocoon to reuse XML parsers
Removed Cocoon store janitor
Preloading key OO javascript flowscript at server startup
Observations
Windows XP
Pentium 4 1.8Ghz
JDK 1.4.2_06
Tomcat 5.0.28
Cocoon 2.1.5.1
512MB physical RAM
JVM -server -Xms256M -Xmx256M
Load test with num users threads each making 5 successive request in a
loop with approximately 3 second think time between requests. No derived
resources – only the main page.
users overall home  search1 search2 search3  detail  total
  avg ms  page   num reqs
10  486208  637588 644 355500
20 1704378 2684   18372875 745500
30 3725682 5987   462662701059450
4019461   141136021  23089   347262059600
5072942   3213   130482  90993  1316668356500
home page: /
search1: /luxury_hotels/europe__france__paris/index.html
search2: /luxury_hotels/bahamas_%26_the_caribbean/beach_resort/index.html
search3:
/luxury_hotels/europe__france__paris/city_centre_location/index.html
detail: /luxury_hotel/new_york,_ny/the_carlyle
Platform:
Development
Windows XP
JDK 1.4.2_06
Tomcat 5.0.28
Cocoon 2.1.5.1
Deployment
Linux 2.6.x
We see similar degradation on Linux as on Windows.
The home page has no flowscript or cforms, but does have jxtemplate
generation, xinclude, xslt, and a custom generator.
The search and detail pages include a cform, and are therefore 

Re: Accessors (was Re: Adding cocoon.suicide() to the FOM API.)

[Ralph Goers]

Daniel Fagerstrom wrote:
Ralph Goers wrote:
Sylvain Wallez wrote:
Oh yes, sure. I totally agree with the concept. It's not a factory 
and it's not an object holder as depending on the implementation it 
can be either or even something else. So accessor is fine!
Did this accessor thing evolve from another discussion?  It seemed to 
pop up out of thin air in this thread.
It did, I had thought a little bit more about what to call them and 
wanted to tell, Sylvain decreased the confussion by changing the 
thread name.

Is this what I hope it means?  If it is, then I hope to see classes 
like Request, Session, Context, etc. be modified to implement the 
interface.  To me, this would mean that they implement a static get 
method that returns the appropriate instance of the object.  Perhaps 
a better name for this would be Accessible.  I guess your plan is to 
implement a separate Accessor class to do this instead?

I'm not geting what your aim at, could you tell a little bit about how 
you want to use the accessores so that I can understand why you prefer 
such a solution compared to the component based approach that we have 
discussed.
Actually, a couple approaches have been mentioned.  As I understand 
them, they are:
1.   Have a global "component object model" that everything is anchored 
in and accessed through.  Frankly, I see this as a bad idea that needs 
to go away - at least the accessing part.  There are so many reasons why 
this is awful that I don't even want to start listing them. But just for 
a start, it is hardly object oriented as it makes the component object 
model have to know way too much.
2.  Have an Accessor interface, presumably with a class that implements 
it for each type of object to be accessed, such as RequestAccessor, 
SessionAccessor, etc.  In and of itself, this isn't a bad idea.  It just 
isn't necessary, in my opinion.

When I was working on my last portal enhancements, I was frustrated that 
I couldn't get ahold of some of the objects I needed.  The "right way" 
would have required that I make some of the classes implement Avalon 
interfaces which, of course, meant adding more definitions to 
cocoon.xconf.  This is frustrating when all you want is to the reference 
to some other object, but to get it you have to have a Context or a 
service manager.  It would be much more convenient for a lot of objects, 
as well as many flow applications, to be able to just do:
   Object.getInstance();

This places the burden for locating the correct object instance on the 
object itself which, in my opinion, is where it belongs.  It also allows 
the object to use any number of techniques to locate the correct 
instance; it can retrieve it from the object model, from the component 
manager, or whatever.  Furthermore, it allows one to write something 
like ${Request} in a template or flowscript and have that be replaced 
with a reference to the correct object instance.

Is that clearer?
Ralph

Re: Supported and unsupported blocks

[Reinhard Poetz]

Vadim Gritsenko wrote:
Reinhard Poetz wrote:
If nobody stops me, I will put all blocks into 
/cocoon/blocks/[block-name]/trunk/ and create a block.xml for each. It 
will contain an element indicating the community status

+1

and for now *all* blocks get the status "committed".

What's "committed"? Do you mean "contributed", or "supported"?
meant "contributed", thanks Vadim
--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Supported and unsupported blocks

[Vadim Gritsenko]

Reinhard Poetz wrote:
If nobody stops me, I will put all blocks into 
/cocoon/blocks/[block-name]/trunk/ and create a block.xml for each. It 
will contain an element indicating the community status
+1

and for now 
*all* blocks get the status "committed".
What's "committed"? Do you mean "contributed", or "supported"?
Vadim

If somebody wants to see a 
block somewhere else, he needs to start a vote (and for this voting the 
wiki page will be very helpful ...)

So hopefully we can move on to some more productive work ;-)

accessing Request from SessionListener

[Grzegorz Tańczyk]

Hello Devs,

  I'm sorry that this question is not directly connected to Cocoon,
  but I need quick solution for this problem. I need to know how to
  access HTTPRequest in
  public void sessionCreated(HttpSessionEvent arg0)

  Thanks in advance.

-- 
Best regards,
 Grzegorz  mailto:[EMAIL PROTECTED]

RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled

[Linden H van der (MI)]

> Ok. He can add whatever attribute to his styling, the stylesheets are 

True.

> built for this, but I don't want to see this "readonly" attribute 
> handled in the stylesheets, as we have other mechanisms for 
> this, namely widget states.

Agree, however, "readonly" is part of the HTML textarea specification.
IIRC there is a slight difference between "disabled" and "readonly". The
first one is addressed by widget states, the latter is not. 

> It's important to use widget states for this not only for 
> consistency, 
> but also because non-active (i.e. disabled/output/hidden) 
> widget states 
> instruct the widget not to read its value from the request, 
> which would otherwise reset their value.

Agree.

> I am still missing something?

Well... Reading the HTML textarea specs on "readonly" I get the
impression that it is not covered by any widget state. Of course there
is the "artistic freedom" to define your own states, but I think that
CForm widgets should at least be able to result in all possible HTML
state variations as they are defined.
Even more so when the general idea of CForms is to overcome the limits
of HTML form fields.

Just my 2 cents.

Bye, Helma

DO NOT REPLY [Bug 27802] - EncodeURLTransformer encodes off site links

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27802


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 27802] - EncodeURLTransformer encodes off site links

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27802


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 11:53 ---
The current transformer already provides a mechanism for excluding external 
links:
img/@src|a/@href=*http://

So, I will close this bug as fixed; if someone things that a more advanced 
feature is necessary please open a new bug.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33662] - o.a.c.transformation.EncodeURLTransformer doesn't work

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33662





--- Additional Comments From [EMAIL PROTECTED]  2005-03-17 11:34 ---
The encodeURL transformer encodes only if a session exists. Are you sure, that 
you have a session created before? The encodeURL transformer does not create it.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.