Content-Type: multipart/related; boundary="----_=_NextPart_002_01C7C65C.F778AFF1"; type="multipart/alternative" ------_=_NextPart_002_01C7C65C.F778AFF1 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C7C65C.F778AFF1" ------_=_NextPart_003_01C7C65C.F778AFF1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike, =20 Thanks for the reply.=20 =20 Now I have changed my XSL not to use any current function. But it may not fix my problem and I need to consider your suggestion to do partition, i.e. having multiple TransformerFactory or Configurations each for the type of input XML file (we have total 6 document types). =20 But I am doing my investigation on why it has failed with the new Saxon-8.9 (I know my XSL still has current function in it)? If I run this on a standalone program this is what I see in NamePool (Please look at attached NamePool_stack.txt) for a single run. I can see Saxon had generated 6 new local names in to the NamePool for each current function in my XSL file. =20 Fingerprint 0/244 local name =3D current1358189313 uri code =3D 3 Fingerprint 0/277 local name =3D current-2068589611 uri code =3D 3 Fingerprint 0/369 local name =3D current-1417755902 uri code =3D 3 Fingerprint 0/411 local name =3D current-1429450828 uri code =3D 3 Fingerprint 0/741 local name =3D current1868763253 uri code =3D 3 Fingerprint 0/997 local name =3D current2025214189 uri code =3D 3 =20 If this is TRUE then, if I run this program in a loop of say 20,000 times Saxon will generate 20,000x6 =3D 120,000 new element names in to = the NamePool. How long or how many elements do this NamePool can accommodate before it say "NamePool is full"? I know it also depends on number of elements in my input XML files. =20 Thanks for all your help. =20 Regards, Srini =20 =20 ________________________________ From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Michael Kay Sent: Saturday, July 14, 2007 5:35 AM To: 'Mailing list for SAXON XSLT queries' Subject: Re: [saxon] Any thoughts about this Exception 'Saxon namepoolisfull'?? =20 The problem with current() will be fixed in 9.0, but it's not fixed in 8.9. =20 I think the method to dump the namePool still works in 8.9, but by default Saxon no longer uses a static NamePool, it uses one per Configuration, so you will have to connect to the Configuration to select the namepool it is using before you can use this method. =20 If you can partition your workload so that it uses multiple NamePools then this is probably still worth doing. Using a new Configuration/NamePool for each transformation, however, is probably going a bit too far the other way. =20 Michael Kay Saxonica =20 =09 ________________________________ From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Kusunam, Srinivas Sent: 14 July 2007 00:14 To: Mailing list for SAXON XSLT queries Subject: Re: [saxon] Any thoughts about this Exception 'Saxon namepool isfull'?? Mike, =20 If you remember previous conversations you said this "NamePool" issue is fixed is latest Saxon-8.9. We did not change our XSL the way you suggested as we put it on hold for next release. We thought this new Saxon implementation should fix it but we got this problem again after 3 months in production. =20 1) Is this current() function in XSL is still a problem with Saxon-8.9? As you know it was generating following entries in Saxon-8.0 =20 Fingerprint 7/1021 local name =3D current-2066122411 uri code =3D 3 Fingerprint 8/1021 local name =3D current1856704867 uri code =3D 3 Fingerprint 9/1021 local name =3D current1858944729 uri code =3D 3 Fingerprint 10/1021 local name =3D current1855126447 uri code =3D 3 Fingerprint 11/1021 local name =3D current1359914837 uri code =3D 3 Fingerprint 12/1021 =20 2) How can I print these FingerPrint statements in Saxon-8.9? As you know in Saxon-8.0 if you say "NamePool.getDefaultNamePool().diagnosticDump()" it will print actual contents of the NamePool (above statements) but in Saxon-8.9 it is not printing these contents? =20 3) Do you still suggest on using my own NamePool instead of default one for every transformation? =20 Thanks for your time. =20 Thanks, Srinivas Kusunam =20 248-991-1044 www.rlpt.com =20 =20 =20 Michael Kay wrote:=20 From: "Michael Kay" To: "'Kunnummal Naheed Madathummal'" Subject: RE: [saxon] Any thoughts about this Exception 'Saxon namepoolisfull'?? Date: Fri, 23 Mar 2007 12:37:13 -0000 Sorry about the delay in responding to this. I think the performance difference is because on line 31 you replaced=20 =20 =20 with =20 =20 whereas the correct replacement is =20 =20 As the element in question has no element children, there's a substantial difference between finding the namespace nodes for this element and finding those for every element in the document. In fact, because the element has no element descendants (and if if it did, I doubt you would be interested in their namespaces) the expression could just be written =20 Could I make a few other comments about your code? =20 Line 21 =20 =20 =20 would be better written as =20 =20 It's never a good idea to create a result tree fragment when you only need a string. =20 Line 25: =20 =20 I don't think you need to copy the transactionNode, you only need a reference to it. Replace by =20 =20 More generally, I wonder why you are doing all the processing in a template for match=3D"xdd:RecordSequenceNumber" when the focus of the processing seems to be its parent element vr:DCNRegistration? Why go down further than you need to and then step back up again? =20 Line 48, again =20 > =20 is much less efficient than =20 > =20 (although Saxon tries very hard to optimize it) =20 There are other bits of the code I don't understand, presumably because there's stuff in your real data files that isn't in these samples. =20 Regards, =20 Michael Kay Saxonica Limited =20 =20 =09 ***************************************************************** This message has originated from RLPTechnologies,=20 34405 W 12 Mile Road, Suite 343, Farmington Hills, MI 48331. =20 If you do not wish to receive further e-mails regarding=20 RLPTechnologies, please forward this e-mail to Do_Not_Send@rlpt.com=20 with the word "remove" in the subject line. =20 This e-mail message and any files transmitted with it are=20 confidential and intended solely for the individual or entity to whom they are addressed. If you have received this message in=20 error, please delete this message and notify the RLPTechnologies System Administrator at postmaster@rlpt.com. =09 ***************************************************************** =20 ------_=_NextPart_003_01C7C65C.F778AFF1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,

=

 

     &nbs= p;          Thanks for the reply.

 

Now I have changed my XSL not to = use any current function. But it may not fix my problem and I need to consider = your suggestion to do partition, i.e. having multiple TransformerFactory or Configurations each for the type of input XML file (we have total 6 = document types).

 

But I am doing my investigation = on why it has failed with the new Saxon-8.9 (I know my XSL still has current = function in it)? If I run this on a standalone program this is what I see in = NamePool (Please look at attached NamePool_stack.txt) for a single run. I can see = Saxon had generated 6 new local names in to the NamePool for each current = function in my XSL file.

 

Fingerprint = 0/244

  local name =3D = current1358189313 uri code =3D 3

Fingerprint = 0/277

  local name =3D = current-2068589611 uri code =3D 3

Fingerprint = 0/369

  local name =3D = current-1417755902 uri code =3D 3

Fingerprint = 0/411

  local name =3D = current-1429450828 uri code =3D 3

Fingerprint = 0/741

  local name =3D = current1868763253 uri code =3D 3

Fingerprint = 0/997

  local name =3D = current2025214189 uri code =3D 3

 

If this is TRUE then, if I run = this program in a loop of say 20,000 times Saxon will generate 20,000x6 =3D = 120,000 new element names in to the NamePool. How long or how many elements do = this NamePool can accommodate before it say “NamePool is full”? I = know it also depends on number of elements in my input XML = files.

 

Thanks for all your = help.

 

Regards,<= /p>

Srini

=

 

 


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Michael Kay
Sent: Saturday, July 14, = 2007 5:35 AM
To: 'Mailing list for SAXON XSLT queries'
Subject: Re: [saxon] Any = thoughts about this Exception 'Saxon = namepoolisfull'??

 

The problem with current() will be = fixed in 9.0, but it's not fixed in 8.9.

 

I think the method to dump the = namePool still works in 8.9, but by default Saxon no longer uses a static = NamePool, it uses one per Configuration, so you will have to connect to the = Configuration to select the namepool it is using before you can use this = method.

 

If you can partition your workload = so that it uses multiple NamePools then this is probably still worth doing. = Using a new Configuration/NamePool for each transformation, however, is probably = going a bit too far the other way.

 

Michael = Kay

Saxonica

=

 


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Kusunam, Srinivas
Sent: 14 July 2007 = 00:14
To: Mailing list for SAXON XSLT queries
Subject: Re: [saxon] Any = thoughts about this Exception 'Saxon namepool = isfull'??

Mike,

 

         If = you remember previous conversations you said this “NamePool” = issue is fixed is latest Saxon-8.9. We did not change our XSL the way you = suggested as we put it on hold for next release. We thought this new Saxon = implementation should fix it but we got this problem again after 3 months in = production.

 

1) Is this current() function in XSL is still a problem with Saxon-8.9? As you know it was generating following entries in Saxon-8.0

 

Fingerprint = 7/1021

local name =3D current-2066122411 = uri code =3D 3

Fingerprint = 8/1021

local name =3D current1856704867 = uri code =3D 3

Fingerprint = 9/1021

local name =3D current1858944729 = uri code =3D 3

Fingerprint = 10/1021

local name =3D current1855126447 = uri code =3D 3

Fingerprint = 11/1021

local name =3D current1359914837 = uri code =3D 3

Fingerprint = 12/1021

 

2) How can I print these FingerPrint statements in Saxon-8.9? As you know in Saxon-8.0 if you say “NamePool.getDefaultNamePool().diagnosticDump()= ” it will print actual contents of the NamePool (above statements) but in Saxon-8.9 it is not printing these = contents?

 

3) Do you still suggest on using my own NamePool = instead of default one for every transformation?

 

Thanks for your time.

 

Thanks,

Srinivas Kusunam

248-991-1044

www.rlpt.com

 

 

Michael = Kay <mike@saxonica.com> wrote:

From: = "Michael Kay" <mike@saxonica.com>
To: "'Kunnummal Naheed Madathummal'" <naheedmk@yahoo.com>
Subject: RE: [saxon] Any thoughts about this Exception 'Saxon = namepoolisfull'??
Date: Fri, 23 Mar 2007 12:37:13 -0000

Sorry about the delay in responding = to this. I think the performance difference is because on line 31 you = replaced

 

  <xsl:copy-of select=3D"current()//namespace::*"/>

 

with

 

  <xsl:copy-of select=3D"//namespace::*"/>

 

whereas the correct replacement = is

 

  <xsl:copy-of = select=3D".//namespace::*"/>

 

As the element in question has no = element children, there's a substantial difference between finding the namespace = nodes for this element and finding those for every element in the document. In = fact, because the element has no element descendants (and if if it did, I = doubt you would be interested in their namespaces) the expression could just be = written <xsl:copy-of = select=3D"namespace::*"/>

 

Could I make a few other comments = about your code?

 

Line = 21

 

 <xsl:variable name=3D"transactionNodeName">
  <xsl:value-of select=3D"../name()"/>
 </xsl:variable>

 

would be better written = as

 

 <xsl:variable name=3D"transactionNodeName = select=3D"name(..)"/>

 

It's never a good idea to create a = result tree fragment when you only need a string.

 

Line = 25:

 

 <xsl:variable name=3D"transactionNode">
  <xsl:copy-of select=3D"./.."/>
 </xsl:variable>

I don't think you need to copy the transactionNode, you only need a reference to it. Replace = by

 

 <xsl:variable name=3D"transactionNode" = select=3D".."/>

 

More generally, I wonder why you = are doing all the processing in a template for = match=3D"xdd:RecordSequenceNumber" when the focus of the processing seems to be its parent element vr:DCNRegistration? Why go down further than you need to and then step = back up again?

 

Line 48, = again

 

   <xsl:variable name=3D"serviceName">
    <xsl:value-of select=3D"../../@svc:Name"/>
   </xsl:variable>

 

is much less efficient = than

 

   <xsl:variable name=3D"serviceName" select=3D"../../@svc:Name"/>

 

(although Saxon tries very hard to optimize it)

 

There are other bits of the code I = don't understand, presumably because there's stuff in your real data files = that isn't in these samples.

 

Regards,

 

Michael = Kay

Saxonica = Limited

 

 

**********************************************=
*******************
This =
message has originated from RLPTechnologies, =
34405 W 12 Mile Road, Suite =
343, Farmington Hills, MI  48331.  =
If you do =
not wish to receive further e-mails regarding =
RLPTechnologies, please forward this e-mail =
to Do_Not_Send@rlpt.com 
with the =
word "remove" in the subject =
line.
 
This =
e-mail message and any files transmitted with it are =
confidential and intended solely for the =
individual or entity to 
whom they =
are addressed.  If you have received this message in =
error, =
please delete this message and notify the RLPTechnologies =
System =
Administrator at =
postmaster@rlpt.com.
**********************************************=
*******************
 
------_=_NextPart_003_01C7C65C.F778AFF1-- ------_=_NextPart_002_01C7C65C.F778AFF1 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODdhlgAUAHcAACH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACwAAAAAlgAUAIeUhHuc jHuUjHuclIyclIScjIScjIylnIytnJSllISllIylnJStnIy1pZytpZy1rZytpZS1raW9ta29ra29 raW9vbW9taW1ta29va21taXGvbXGta3Gvb3OvbXOvb3Gva3GtbXOxr3OxrXWzr3Gxr3GxrXOzr3W zsbe3tbe1s7Oxsbe1tbOzsbW1s7ezs7Wzs7e3t73CBjvABDvCBjvEBjvECH3ECnvCCH3ECH3CCHv ECnvGDH3GCn3GDHvGCn3ITH3ITnvKTnvITH3MTn3KTn+ITH3OUr3MULvMUL3KUL3SlL3QlL3Slr3 QkrvQlL+SlL3UmP+UmP3Wmv3a3P3c3v3a3v+a3v3c4T+c4T3e4T+e4z3e4z+lJz3jJT+nJz+hIz3 nJz3jJz+hJT+jJT3nKX+nKX+lKX+pbX+tb3+pa3+rbX+rb3n3tbn3t7+xs7+1t7v3t7+3t7+ztb+ 1tb+1s7+xtb+zs7+3ufn597v597+/v7+9/f39/fv7+fv5+f39+/v7+/n5+f+/vf+5+f+7+/37+/+ 5+/+7/cBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMI/wD1CBxIsKDBgwgTKlzIsKFDgXvw8NFzogEbPX00nHjI saPHjyBDNvQTAYWeFA7a6GkzQILAP3tEypxJsyZDFCoESiz4ZwUePSgOPLBJtKjRh38AYfTTcAUA CBOPSp16NFAfjn/Y/KTKtaagozFD3rmCZZBMJUvQql2yhAkXQnoGQWmixMiZgmiMqHXyhC2Ut3oi THhAIULhww22cmSBoALRPhAi/AnpJoaMNzJraLZx48YMHDVwzIAS9wfoGV0KkslRw0aNHDNY65jx BM6BAAkIKEiggECCAgVaeAwRIALRNgoUTAb5hgmTOzJ/7PhRI0oZL0t49KAeh9ARH9S5FP9MY+OH DyBTvkDpweNHDjAVLERwoACBAggU5F/Vw+frwT2ChKWHCAS4JFBUBgmCIEETCahHIPctp4cgCiJU IUP9LThQhgZN50MOqenhRg09+KCDHIQE4YMPOIRRUBk27MCDEGbpgQQPO+CQxUAbJKeAcQIVogEC CBzggAZhCXICBAgs4AAHMYVQgAQuOOCkBJPh8UAHbERwQGR5DIRCBBAcgIADG62UAAMT9SGBA2ZC oMF+erzQwAIINNCGBhbg8ccFEhQiEEpEIhDBRQK18ECRhvbhBwsqhPDDdjVgEUccV2jHgxJxDdEe DmaMV8MPPBAxhx5vfEedFgNpQIB9Fhz/6EABEbyQQgQENPCVqxCokAICtOoRggIHLLCBBgskYBwK yS0QgQf0HTDRCQMoIMEJGhxQwAd6+JEABHsAkiyaITgQgANKtZDctdn25kcfChQwmZQIhICCBwcQ sIIeKxiAwAsoUFCAAnisoIIDPmhnnnk8NMyEIXEFwYOJIQ4EI3g7tHUEiSyqMVAFvP0o0AgBNICg AwS84AcBB5i00gILFHJCAS0LxOwBgOChmwYvLZCyHvnyPKi2gUC4wB+8hgUIBAV4oAcEBAhNEc19 FJLcH3z0lsJA1DqgBwYJOCAoHxyQEAh/f/ygNg9AEAGEDkBs90VcqtYgHkFp6GBeETTA/8YDDjhM QZAGCdhnYAT3SWAYBQgEoFHYBFUYgrID/WFfzgccICCuKfiRnFIDNaDAC30Q4EAfESSQpkAhEEBB H5mrJBAg9hXSh3184KHAAoXJ9wDLPemmQAMUhMDUQD70kCMVg9Ahxag1EHFIiivacLfFE09cxRZa ZCEGGgX1mByQuDoggQQWSHDsCzMPZRBxBurxB7F95PGqgPSdULoCdOrRQAEv0B0C+oCy1emBBQGY QCAQQACX6QEQB1CAHwCRnEK04VUUON/5NACCyQSMPgRgGQwGMin3iEEgasDBdHjQnSS0hwdMsAIV qlCFOqhhVD4gQhwU4irDCaQEBACSQP8qxKyYvURxfFBBAigwkEIUqRB4KBZBIhAcPjCAAKvzQwTZ QEEICMl1U1SAY+gTgbBooIKwU8AerDaA473kKys4AVP4wAamrU4HPNBBDnakBzu0hkVrIAQQQMOD GsRgBpZJQxpwYIOJYSYhEhAekChYIDwEYnIJ2NesHoAHPFhAAAjgA3EmULnk+EFnbBoI03LiKgWw AAUtYKDX8JAAzcEgXhJYAQoyoJuf3LJwGHAABBbAv0L4RimRRMAK/FDHIOrhAQFAQBsAsYLeCEcg RyDCEXYwBoEMwgja/EEZ9mCEIGRzCNokwg/UgIYfJCEIRthhQkKwACZJjSQRjGADXnDJIAnYJ4IW uEoIDhC/PzgAAVBEAAQIIoEDXJMEEOBN4SQwES0+YCIrQFxvGGCRymngARAIAR4cMIBCLC2VeuAA AgYQQQRQFCMN+Gd9OECQQRBiEIYQkCEMgdNDxIWnQB2EUPWwB6EOVSF8SGpSC9KHNkzTQQ/EQxsE taGC8CEsS93QHgTEBz+gAA9UPdCCCqGV/qUgBLJbSXKuktUDBQIGgQDdQPqABxT4QUNdyateWReA A7DgrAdIQPz2StjCfkQF/+tNA0xQlIAAADs= ------_=_NextPart_002_01C7C65C.F778AFF1--