Re: [C2] Profiling, compiled XSLT & database SELECT caching; was: serverpages doesn't like auto-generated xsp?

[Stuart Roebuck <st...@adolos.co.uk>]

Any hints from anyone on a good strategy for working out which pipeline 
stages are slowing things down.  I've tried to use the profiler but haven'
t got anywhere.  Trying to do code profiling on Cocoon just overloads my 
system!

Is XSLT precompiled nowadays - I don't see an option for it that there 
used to be, and I don't see any compiled code in the caches.

Finally, is there any option for delaying the frequency of actual database 
SELECTs so that repeated calls for the same information also return from 
cache?  One option that could be really useful in many cases would be to 
return from cache unless an UPDATE had been issued from Cocoon in the 
interim.  Clearly many databases will be updated from other sources but 
ours aren't!

Stuart.

On Sunday, July 22, 2001, at 02:21  pm, Berin Loritsch wrote:

> I get this as well with Tomcat 3.3m2
>
> I think that there is a problem where the classloader
> is not letting go of the class that was loaded.  I
> have
> experienced problems with it myself.
>
> Everything looks like it should work though...
>
> --- giacomo <gi...@apache.org> wrote:
>> On Sat, 21 Jul 2001, Stuart Roebuck wrote:
>>
>>> giacomo,
>>>
>>> Thanks,
>>>
>>> I've been wondering what the {../1} terminology
>> was all about recently and
>>> now I know! :-)
>>>
>>> I discovered that the problem was a combination of
>> that, and the fact that
>>> the xslt generator was removing spaces that turned
>> out to be critical for
>>> the xsp to work. A slight change to the xslt
>> solved that one.
>>>
>>> However, based purely on a general sense of
>> sluggishness, it looks to me
>>> that the caching mechanisms are not preventing the
>> re-compiling of the xsp
>>> each time through the loop.  Perhaps this is a
>> known limitation at the
>>> moment, or maybe I've not switched the right thing
>> on!
>>
>> I don't get this. Do you like to say that all xsp
>> you're requesting gets
>> recompiled every time? I don't have this behaviour
>> (and I havn't change
>> anything).
>>
>> Giacomo
>>
>>>
>>> Cheers,
>>>
>>> Stuart.
>>>
>>> On Saturday, July 21, 2001, at 09:40  am, giacomo
>> wrote:
>>>
>>>> On Fri, 20 Jul 2001, Stuart Roebuck wrote:
>>>>
>>>>> I've been trying to produce a sitemap where the
>> XSP for serverpages is
>>>>> generated by an XSLT transformer on an XML
>> input file.  I want to
>>>>> generate
>>>>> an ESQL query tailored to the fields of a
>> number of different database
>>>>> tables.
>>>>>
>>>>> In other words, if you request
>> "select-test.xml" it should return the
>>>>> content of the 'test' table, by generating ESQL
>> to query the database
>>>>> (obtained from 'select-test.xsp') and
>> processing it with the serverpages
>>>>> generator.
>>>>>
>>>>> Here's a mock up of the code:
>>>>>
>>>>>      <map:match pattern="select-*.xml">
>>>>>        <map:act type="request">
>>>>>          <map:parameter name="parameters"
>> value="true" />
>>>>>          <map:generate type="serverpages"
>> src="cocoon:/select-{1}.xsp">
>>>>
>>>> Should this be:
>>>>
>>>>        <map:generate type="serverpages"
>> src="cocoon:/select-{../1}.xsp">
>>>>
>>>> to reference the matchers match?
>>>>
>>>> Giacomo
>>>>
>>>>>            <map:parameter name="id"
>> value="{table}" />
>>>>>          </map:generate>
>>>>>        </map:act>
>>>>>        <map:serialize type="xml" />
>>>>>      </map:match>
>>>>>
>>>>> 	<map:match pattern="select-*.xsp">
>>>>> 	  <map:generate
>> src="data/database_descriptions.xml" />
>>>>> 	  <map:transform
>> src="transform/create_select_xsp.xslt">
>>>>> 	    <map:parameter name="table" value="{1}" />
>>>>>        </map:transform>
>>>>>        <map:serialize type="xml" />
>>>>>      </map:match>
>>>>>
>>>>> I tried this out and the XSLT appeared to
>> generate the correct XSP, but
>>>>> the result of the "select-text.xml" request was
>> incorrect.  If I took the
>>>>> result of a request for "select-test.xsp" and
>> saved it to a file, then
>>>>> changed the first match to take the fixed file
>> as the serverpages source,
>>>>> everything worked fine.  I can only imagine
>> that the problem lies in the
>>>>> passing of the SAX stream between the
>> components.  Could the "cocoon:/"
>>>>> protocol be loosing or getting confused by
>> namespaces?
>>>>>
>>>>> Stuart.
>>>

-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                           <http://www.adolos.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org