You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <Gi...@pwr.ch> on 2000/07/07 21:46:46 UTC
Sitemap class generation
Hi all
I want to show the layout of the currently generated sitemap class for
discussion.
Some notes: a Pipeline in the context below is a object which holds a
generator, maybe several transformers and a serializer. This object has
a process method to produce the resource requested.
class GeneratedSitemap {
for each sitemap-component {
define a variable to hold a reference to the sitemap-component
object
}
for each <mount> tag {
define a variable to hold a reference to the sub-sitemap object
}
method setConfiguration (from interface Configurable) {
for each sitemap-component {
collect configuration tags to build a Configuration object for
the component
store an instance of the component into the variable generated
above
provide the Configuration at the setConfiguration method of the
component
}
for each <mount> tag {
store an instance of the sub-sitemap object into the variable
generated above
provide the Configuration at the setConfiguration method of the
sub-sitemap
}
}
for each <resource> tag {
define a method with the process signature from interface
Processor {
generate code to build a Pipeline which represents this resource
[see the process method how such code is generated
}
}
process method (from interface Processor) {
for each <pipeline> tag {
try {
generate the code to build a Pipeline object
[This is straight forward code generation using <match> and
<choose> to
[build if-else trees. The returned Maps of the matchers will
be pushed onto a Stack
[and a resolver method uses this Stack of Maps to resolve
URIs that contains xpath
[references.
[At a <serializer> tag we should have a complete Pipeline
object constructed
[which can be processed and control can be returned.
[At a <mount> tag processing is delegate to the sub sitemap.
[At a <redirect-to> with a uri attribute the uri of the
request is modified and
[the this process method is called again
[At a <redirect-to> with a resource attribute the
corresponding method generated above
[is called
[At a <read> tag a utility method is called to produce the
resource requested
[without processing a Pipeline
} catch {
build a Pipeline object from the <handle-errors> fragment
[this uses a special generator which produces SAX from a
Exception
}
}
}
}
I still have no idea (or not reflected sufficently) how views and labels
can be incorporated into this class. I hope someone can help me here.
Any comments and suggestions as very welcome.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: Sitemap class generation
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Sun, Jul 09, 2000 at 01:58:13PM +1000, Rob Parker wrote:
> May I ask what the motivation/advantage is of a generated sitemap class over
> a generic
> class consisting of say hashtables which reads the configuration file?
There is no advantage concerning "read the configuration file".
Reading the configuration could be done like you mentioned and
was realized in the early Cocoon 2 version.
But mainly it is performance advantages at resource generation
time compared to a interpretative version, don't you think?
And personaly, it was curiosity how this could be done.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: Sitemap class generation
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Sun, Jul 09, 2000 at 05:35:28PM +0000, Jon Lancelle wrote:
> Is the sitemap class available in the latest cvs distribution? I'd like to
> check out the progress. Sounds interesting.
I think you missed my mail with this Subject. Go check the mail archive for the first mail with this Subject.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: Sitemap class generation
Posted by Jon Lancelle <jk...@knosys.com>.
Is the sitemap class available in the latest cvs distribution? I'd like to
check out the progress. Sounds interesting.
Jon Lancelle
Stefano Mazzocchi wrote:
> Rob Parker wrote:
> >
> > May I ask what the motivation/advantage is of a generated sitemap
> > class over a generic class consisting of say hashtables which reads
> > the configuration file?
>
> Of course, you may :)
>
> Reminds me of the good old "do you know what time is it? yes, I do." :)
>
> Seriously, there are mainly two reasons:
>
> 1) removed interpretation overhead: a compiled sitemap is "executed"
> rather than interpreted. There may be cases where the sitemap may be
> compiled into some interpreting code to take advantage of hotspot
> facilities, but these are future optimizations. In general, given the
> overall complexity a sitemap can achieve, a run-time interpretation may
> add significant overhead for resource creations and invalidate the whole
> point of context separation.
>
> 2) reduced development effort: a sitemap logicsheet is not easy to
> write, but a lot easier than XML interpreting code, as XSP teaches. But
> the real advantage is code maintenance: adding a new sitemap schema is
> equivalent to creating an XSLT stylesheet between the new schema and the
> old sitemap logicsheet. Having such architecture in place allows more
> flexibility without loosing any performance nor increased coding
> complexity.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
Re: load related problem
Posted by Stefano Mazzocchi <st...@apache.org>.
Mark Washeim wrote:
>
> on 10/7/00 6:52 pm, Mark Washeim at esalon@canuck.com wrote:
>
> > on 10/7/00 5:31 am, Donald Ball at balld@webslingerZ.com wrote:
> >
> >>> Mark Washeim wrote:
> >>>
> >>>> I've been load testing an xsp application (one of the eurofootball apps)
> >>>> and
> >>>> am having difficulty determining the origin of this exception:
> >>>>
> >>>> java.lang.NullPointerException
> >>>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
> >>>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
> >>>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
> >>>> at org.apache.cocoon.processor.xsp.XSPPage.xspExpr(Compiled Code)
> >>>> at
> >>>> _opt._IBMHTTPD._htdocs._en_US._editorial._gb_home.populateDocument(Compiled
> >>>> Code)
> >>>>
> >>>> it only occurs when I bring the load up to about 40 to 50 concurrent
> >>>> requests (per second).
> >>>
> >>> Interesting thorughput :o)
> >>>
> >>>> I'm wondering if it's because the method within the xsp:expr isn't
> >>>> returning
> >>>> (which shouldn't happen and doesn't under less load) or whether it's
> >>>> something else?
> >>>>
> >>>> Any ideas ?
> >>>
> >>> One might wonder if some OutOfMemoryError has been caught and ignored...
> >>
> >> one might also check and see if the library method being invoked by
> >> xsp:expr is the cause of the null pointer by simply forking 40-50 threads
> >> and repeatedly call it from them. my gut says that xsp is the problem, but
> >> it'd be good to eliminate the external possibilities first. other likely
> >> candidate is the jvm.
> >>
> >> - donald
> >>
> >
>
> For those of you who are macintosh fans, you'll be pleased with this:
>
> I can't reproduce the outOfMemory error related problems I get when testing
> on Solaris (an Enterprise 250 machine with 2 processors and 1 GB of RAM) . .
> . It's amazing.
>
> The mac I tested on is a G4 with 256 mb of ram. Tomcat 3.1 used as the
> servlet engine (and webserver).
>
> Even running 30 or 40 concurrent threads, XSPUtil.cloneNode kept on
> churning.
>
> It's so wierd that a deficient virtual memory scheme like the mac's could
> deal with this.
I told you, it's a GC problem: try IBM 1.3 on Linux.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: load related problem
Posted by Mark Washeim <es...@canuck.com>.
on 10/7/00 6:52 pm, Mark Washeim at esalon@canuck.com wrote:
> on 10/7/00 5:31 am, Donald Ball at balld@webslingerZ.com wrote:
>
>>> Mark Washeim wrote:
>>>
>>>> I've been load testing an xsp application (one of the eurofootball apps)
>>>> and
>>>> am having difficulty determining the origin of this exception:
>>>>
>>>> java.lang.NullPointerException
>>>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
>>>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
>>>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
>>>> at org.apache.cocoon.processor.xsp.XSPPage.xspExpr(Compiled Code)
>>>> at
>>>> _opt._IBMHTTPD._htdocs._en_US._editorial._gb_home.populateDocument(Compiled
>>>> Code)
>>>>
>>>> it only occurs when I bring the load up to about 40 to 50 concurrent
>>>> requests (per second).
>>>
>>> Interesting thorughput :o)
>>>
>>>> I'm wondering if it's because the method within the xsp:expr isn't
>>>> returning
>>>> (which shouldn't happen and doesn't under less load) or whether it's
>>>> something else?
>>>>
>>>> Any ideas ?
>>>
>>> One might wonder if some OutOfMemoryError has been caught and ignored...
>>
>> one might also check and see if the library method being invoked by
>> xsp:expr is the cause of the null pointer by simply forking 40-50 threads
>> and repeatedly call it from them. my gut says that xsp is the problem, but
>> it'd be good to eliminate the external possibilities first. other likely
>> candidate is the jvm.
>>
>> - donald
>>
>
For those of you who are macintosh fans, you'll be pleased with this:
I can't reproduce the outOfMemory error related problems I get when testing
on Solaris (an Enterprise 250 machine with 2 processors and 1 GB of RAM) . .
. It's amazing.
The mac I tested on is a G4 with 256 mb of ram. Tomcat 3.1 used as the
servlet engine (and webserver).
Even running 30 or 40 concurrent threads, XSPUtil.cloneNode kept on
churning.
It's so wierd that a deficient virtual memory scheme like the mac's could
deal with this.
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: load related problem
Posted by Mark Washeim <es...@canuck.com>.
on 10/7/00 5:31 am, Donald Ball at balld@webslingerZ.com wrote:
>> Mark Washeim wrote:
>>
>>> I've been load testing an xsp application (one of the eurofootball apps) and
>>> am having difficulty determining the origin of this exception:
>>>
>>> java.lang.NullPointerException
>>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
>>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
>>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
>>> at org.apache.cocoon.processor.xsp.XSPPage.xspExpr(Compiled Code)
>>> at
>>> _opt._IBMHTTPD._htdocs._en_US._editorial._gb_home.populateDocument(Compiled
>>> Code)
>>>
>>> it only occurs when I bring the load up to about 40 to 50 concurrent
>>> requests (per second).
>>
>> Interesting thorughput :o)
>>
>>> I'm wondering if it's because the method within the xsp:expr isn't returning
>>> (which shouldn't happen and doesn't under less load) or whether it's
>>> something else?
>>>
>>> Any ideas ?
>>
>> One might wonder if some OutOfMemoryError has been caught and ignored...
>
> one might also check and see if the library method being invoked by
> xsp:expr is the cause of the null pointer by simply forking 40-50 threads
> and repeatedly call it from them. my gut says that xsp is the problem, but
> it'd be good to eliminate the external possibilities first. other likely
> candidate is the jvm.
>
> - donald
>
Ok. It's not xsp per se. It's the number of objects created during
XSPUtil.cloneNode() operations, performed recursively over 4 to 5 times.
I'm just toying with the jvm
-oss
and
-ss
options to see if allocating more stack RAM (in the 10s of mb) will make a
difference...
Otherwise, I'll have to remove one dom-wise operation and add some
application structure to deal with the issue (sigh) . . .
Can't believe this is an issue. Bloody jvm. :(
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: load related problem
Posted by Donald Ball <ba...@webslingerZ.com>.
> Mark Washeim wrote:
>
> > I've been load testing an xsp application (one of the eurofootball apps) and
> > am having difficulty determining the origin of this exception:
> >
> > java.lang.NullPointerException
> > at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
> > at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
> > at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
> > at org.apache.cocoon.processor.xsp.XSPPage.xspExpr(Compiled Code)
> > at
> > _opt._IBMHTTPD._htdocs._en_US._editorial._gb_home.populateDocument(Compiled
> > Code)
> >
> > it only occurs when I bring the load up to about 40 to 50 concurrent
> > requests (per second).
>
> Interesting thorughput :o)
>
> > I'm wondering if it's because the method within the xsp:expr isn't returning
> > (which shouldn't happen and doesn't under less load) or whether it's
> > something else?
> >
> > Any ideas ?
>
> One might wonder if some OutOfMemoryError has been caught and ignored...
one might also check and see if the library method being invoked by
xsp:expr is the cause of the null pointer by simply forking 40-50 threads
and repeatedly call it from them. my gut says that xsp is the problem, but
it'd be good to eliminate the external possibilities first. other likely
candidate is the jvm.
- donald
Re: load related problem
Posted by Mark Washeim <es...@canuck.com>.
on 10/7/00 5:02 am, Niclas Hedhman at niclas@localbar.com wrote:
> Mark Washeim wrote:
>
>> I've been load testing an xsp application (one of the eurofootball apps) and
>> am having difficulty determining the origin of this exception:
>>
>> java.lang.NullPointerException
>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
>> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
>> at org.apache.cocoon.processor.xsp.XSPPage.xspExpr(Compiled Code)
>> at
>> _opt._IBMHTTPD._htdocs._en_US._editorial._gb_home.populateDocument(Compiled
>> Code)
>>
>> it only occurs when I bring the load up to about 40 to 50 concurrent
>> requests (per second).
>
> Interesting thorughput :o)
>
>> I'm wondering if it's because the method within the xsp:expr isn't returning
>> (which shouldn't happen and doesn't under less load) or whether it's
>> something else?
>>
>> Any ideas ?
>
> One might wonder if some OutOfMemoryError has been caught and ignored...
>
> Niclas
>
Turns out that this is the case. I was unable to see it while running under
Websphere. When running with the same jvm and settings ( -ms 512m -mx768m )
under solaris (7x) with tomcat, I can see the out of memory error being
generated, whereupon, xsp stops producing that page...
Ok, any ideas for a fix (this has been stalling me for more than a week now,
sigh) . . .
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: load related problem
Posted by Niclas Hedhman <ni...@localbar.com>.
Mark Washeim wrote:
> I've been load testing an xsp application (one of the eurofootball apps) and
> am having difficulty determining the origin of this exception:
>
> java.lang.NullPointerException
> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
> at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
> at org.apache.cocoon.processor.xsp.XSPPage.xspExpr(Compiled Code)
> at
> _opt._IBMHTTPD._htdocs._en_US._editorial._gb_home.populateDocument(Compiled
> Code)
>
> it only occurs when I bring the load up to about 40 to 50 concurrent
> requests (per second).
Interesting thorughput :o)
> I'm wondering if it's because the method within the xsp:expr isn't returning
> (which shouldn't happen and doesn't under less load) or whether it's
> something else?
>
> Any ideas ?
One might wonder if some OutOfMemoryError has been caught and ignored...
Niclas
load related problem
Posted by Mark Washeim <es...@canuck.com>.
I've been load testing an xsp application (one of the eurofootball apps) and
am having difficulty determining the origin of this exception:
java.lang.NullPointerException
at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
at org.apache.cocoon.processor.xsp.XSPUtil.cloneNode(Compiled Code)
at org.apache.cocoon.processor.xsp.XSPPage.xspExpr(Compiled Code)
at
_opt._IBMHTTPD._htdocs._en_US._editorial._gb_home.populateDocument(Compiled
Code)
it only occurs when I bring the load up to about 40 to 50 concurrent
requests (per second).
I'm wondering if it's because the method within the xsp:expr isn't returning
(which shouldn't happen and doesn't under less load) or whether it's
something else?
Any ideas ?
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: Sitemap class generation
Posted by Stefano Mazzocchi <st...@apache.org>.
Rob Parker wrote:
>
> May I ask what the motivation/advantage is of a generated sitemap
> class over a generic class consisting of say hashtables which reads
> the configuration file?
Of course, you may :)
Reminds me of the good old "do you know what time is it? yes, I do." :)
Seriously, there are mainly two reasons:
1) removed interpretation overhead: a compiled sitemap is "executed"
rather than interpreted. There may be cases where the sitemap may be
compiled into some interpreting code to take advantage of hotspot
facilities, but these are future optimizations. In general, given the
overall complexity a sitemap can achieve, a run-time interpretation may
add significant overhead for resource creations and invalidate the whole
point of context separation.
2) reduced development effort: a sitemap logicsheet is not easy to
write, but a lot easier than XML interpreting code, as XSP teaches. But
the real advantage is code maintenance: adding a new sitemap schema is
equivalent to creating an XSLT stylesheet between the new schema and the
old sitemap logicsheet. Having such architecture in place allows more
flexibility without loosing any performance nor increased coding
complexity.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Sitemap class generation
Posted by Rob Parker <ro...@webcybernetics.com>.
May I ask what the motivation/advantage is of a generated sitemap class over
a generic
class consisting of say hashtables which reads the configuration file?
regards
Rob