Re: [xsl] Windows 2003 Server + MSXML

Subject: Re: [xsl] Windows 2003 Server + MSXML
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Sat, 14 Jan 2006 17:19:16 -0700
Without going into deep detail of the various causes of a stack
overflow, there are differences between running a process when it is
called from within an ASP script and when it is invoked from the
command line.  Because ASP is a web based technology your running with
a different set of permissions and constraints than you would from the
command line where you're, more than likely (assuming you are logged
into an account which has administrative privileges), running with
full permissions and therefore access to more system resources without
first being required to increase the resources allocated.

Please don't take the above to mean that you need to set your scripts
to run with higher permissions.  Access to system level resources is
rarely required from within an ASP script so giving any script that
type of access is asking for trouble.  Creating a security hole isn't
going to help solve your resource allocation problem.  Instead you
need to take a look at the application pool that the site is running
under and increase the available resources for that application pool. 
You may also want to create a new application pool that is designated
for that particular site if you are running on a server in which has
several sites that run against that same application pool.  You can
fine tune things even further by separating the script that that is
running your transformations into its own directory, creating a new
virtual directory for the site, pointing the virtual directory to the
directory containing the script, and then changing the application
pool setting to the application pool you've created just for this
script.  Doing so will insure that under heavy loads, that particular
script will still have enough resources made available to it at any
given time to run the transformations successfully.

The above obviously doesn't give you any extended understanding of
what changes need to be made to an application pool to ensure a
certain level of resources are available, this type of information is
readily available on MSDN and/or inthe platform SDK documentation.  If
you are unsure of what needs to be done in regards to any of the above
I would start at one of these resources and start digging into
anything that fall's under the "Applications Pools" category, or a
full text search for the same.

Best of luck!

On 1/13/06, Neil Hunter <HunterN@xxxxxxx> wrote:
> MSXML3, MSXML4 SP2, Windows 2003 Server, IIS 6.0
>
> Hi,
>
> I'm running script on an active server page running on Windows 2003 to
> perform an XSL transformation. This works fine for nearly all my
> documents but for just a few it fails with:
>
> "The XSL processor stack has overflowed - probable cause is infinite
> template recursion"
>
> Now, if instead I use the MSXSL.exe command line utility on the same
> server to transform the same documents with the same XSL it works fine,
> whether I specify MSXML3 or MSXML4. If I run the same transformation
> from script/ASP from any other machine it also works fine.
>
> I am under the impression that the MSXSL.exe command line is just a
> wrapper for the MSXSL Dlls so I don't understand why its working when
> the asp page doesn't.
>
> Is this some sort of Windows 2003 bug?
>
> I'm getting pretty fed up with the MSXML parsers. Every time I change
> versions or move servers I seem to get some subtle change in behaviour
> that can take forever to resolve.
>
> Regards,
>
> Neil Hunter
>
>
> DISCLAIMER:
>
> This communication (including any attachments) is intended for the use of the addressee only and may contain confidential, privileged or copyright material. It may not be relied upon or disclosed to any other person without the consent of the RSC. If you have received it in error, please contact us immediately. Any advice given by the RSC has been carefully formulated but is necessarily based on the information available, and the RSC cannot be held responsible for accuracy or completeness. In this respect, the RSC owes no duty of care and shall not be liable for any resulting damage or loss. The RSC acknowledges that a disclaimer cannot restrict liability at law for personal injury or death arising through a finding of negligence. The RSC does not warrant that its emails or attachments are Virus-free: Please rely on your own screening.
>
>



--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

Current Thread