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