I completely agree that this violates the name pool design, however I was unaware of this during the design phase of the project, and it has turned out to be a core feature.

 

Another reason I opted for this over a name attribute was that we are storing the xml in SQL Server DB and querying it with their XQuery to pull out fragments. I found it very slow to get elements by an attribute value compared to the elements name. I guess then the attribute value becomes the infinite set.

 

Basically our application works with a servlet transforming a query string to a soap request, making the soap call, transforming the result to xhtml, and returning it. Eg

 

1) POSTED data from dynamic form. IE the user has designed their own form eg ‘company’ and ‘location’ in example below.

/user/create?name=mark&age=26&metadata:company=limehouse& metadata:location=London

 

2) create XML in java

<params xmlns=”http://limehousesoftware.co.uk”>

                <name>mark</name>

<age>26</age>

<metadata>

                <company>limehouse</company>

                <location>London</location>

                </metadata>

</params>

 

3) XSLT to a soap request

 

4) XSLT soap result to XHTML or XSL-FO

 

Etc

Etc

 

Firstly just to make sure that the problem is the dynamic fields, and not our already large(ish) element set (SOAP, XHTML, FO, XSLT, LHS) is there any way that I can dump the full names from the NamePool?

 

Performance so far has been good, is there a way that we could increase the NamePool size or for the NamePool to start recycling allocations for rarely used names?

 

Many thanks for your input.

 

Mark

 

 

From: Michael Kay [mailto:mike@saxonica.com]
Sent: 23 October 2007 18:00
To: 'Mailing list for SAXON XSLT queries'
Cc: Mark Gabriel
Subject: RE: [saxon] NamePoolLimitException

 

It looks as if the essence of the problem is this:

 

2) the system auto-generates new elements in the lhs namespace and is not, therefore, finite in size.

 

That is, it's nothing to do with the number of stylesheets, it's all to do with the fact that there's this infinite vocabulary. I'm afraid that violates the assumption behind the name pool design. I'd be interested to know more about the reasons you are doing things this way.

 

Does this infinite vocabulary exist in input documents or only in output documents?

 

Any solution based on recycling or partitioning the name pool is going to be very messy. I think you've suggested a way forward with the idea of generating <param name=”key”>value</param>. If you could generate this as the immediate output of your transformations, and then pipe this output through a SAX filter that converts it into <key>value</key>, then you would certainly have the task of rewriting your stylesheets, but downstream applications would be unaffected, and there should be no noticeable effect on performance (it would probably improve, because NamePool performance degrades long before it hits the limit).

 

I might be able to come up with other ideas if I knew more about your application, but this is the only approach I can think of from what you've described.

 

Michael Kay

http://www.saxonica.com/

 


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Mark Gabriel
Sent: 23 October 2007 16:42
To: saxon-help@lists.sourceforge.net
Subject: [saxon] NamePoolLimitException

Hi,

 

We have started to get a NamePoolLimitException in our java web application. I have read the posts from about a year ago and think that I understand what is happening with the NamePool reaching its 1024 limit. I cannot however seem to find a solution which is not a bit of a hack…

 

Our application is very large and revolves completely around XML and transformation. We currently have a static TransformerFactory which is used to create Templates that are cached in an LRU(last recently used) queue which stores up to 50 Templates. There are, at present, 700 different XSLT’s in the system but this is growing. The 50 size is going to be ‘tweeked’ to optimize performance later.

 

These XSLT’s deal with a mixture of soap, xhtml, fo and lhs (our own namespace). The main problems I am facing are:

 

1) the XSLT’s are very mixed in the content that they deal with and I cannot seem to find a way to divide them into groups, each having their own NamePool.

2) the system auto-generates new elements in the lhs namespace and is not, therefore, finite in size.

3) catching the NamePoolLimitException and setting a new NamePool means that I have to flush the Transformer cache (I am assuming this as the Templates would referee to the old NamePool), which will then have to be recreated which will slow things down.

 

Re-writing the application to use <param name=”key”>value</param> instead of <key>value</key> would get rid of the infinite names, but would be a MAJOR task and live customer data would have to be updates. I’m not sure this is an option.

 

 

Do you have any suggestions?

 

 

Best regards,

Mark G

 


Mark Gabriel
Development

-------------------------------
mgabriel@limehousesoftware.co.uk
Limehouse Software Ltd

DDI: (020) 7566 3336
Main: (020) 7566 3320
Fax: (020) 7566 3321

Limehouse Software Ltd
4th Floor
1 London Bridge
London
SE1 9BG

www.limehousesoftware.co.uk - Unifying Information                

The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments.

        

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.15.6/1086 - Release Date: 22/10/2007 19:57

 

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.15.6/1086 - Release Date: 22/10/2007 19:57


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.15.6/1086 - Release Date: 22/10/2007 19:57