|
|
You're in the
dotnet xml
group:Resource Leak from XslCompiledTransform
dotnet xml:
Hello there, Are there anybody who is using the XslCompiledTransform that comes with .net framework, which was said to be a replacement of the XslTransform class? I found that the class has some issues when the xsl file contains scripts. The XslCompiledTransform uses the CodeDom to compile the scripts within the xsl file into .net assembly and load them into the current AppDomain. Some temporary files would be generated during the compilation in the temp folder. This behavior leads to two issues. 1, The memory consumption of the current AppDomain, i.e. the working application keeps growing up if we compile more and more xsl files that contain scripts. We have no way to identify the assembly generated from the compiled scripts within the xsl files. Thus we can not release the resources associated with the xsl files. 2, The temporary assembly files can not be removed while the application is executing, since they are engaged by it. The TempFiles.Delete method always fails within the application, consequently. And after running the application for several times, the temp folder might be piled up with the those temporary files. Are there any approaches to solve these problems? -- Best Regards, W. Jordan
This might be what you are looking for:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=367635&SiteID=1 -- Stan Kitsis Program Manager, XML Technologies Microsoft Corporation This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm [quoted text, click to view] "W. Jordan" <wmjordan@163.com> wrote in message news:%23ZmoPEeaGHA.4236@TK2MSFTNGP05.phx.gbl... > > Hello there, > > Are there anybody who is using the XslCompiledTransform that comes > with .net framework, which was said to be a replacement of the > XslTransform class? > > I found that the class has some issues when the xsl file contains scripts. > > The XslCompiledTransform uses the CodeDom to compile the scripts > within the xsl file into .net assembly and load them into the current > AppDomain. Some temporary files would be generated during the > compilation in the temp folder. > > This behavior leads to two issues. > > 1, The memory consumption of the current AppDomain, i.e. the > working application keeps growing up if we compile more and more > xsl files that contain scripts. We have no way to identify the assembly > generated from the compiled scripts within the xsl files. Thus we can > not release the resources associated with the xsl files. > > 2, The temporary assembly files can not be removed while the > application is executing, since they are engaged by it. The > TempFiles.Delete > method always fails within the application, consequently. And after > running the application for several times, the temp folder might be > piled up with the those temporary files. > > Are there any approaches to solve these problems? > > > -- > > > Best Regards, > W. Jordan > > > > >
Hello,
Thanks for pointing out that. Actually I really suspect that whether the XslCompiledTransform should replace the old XslTransform class, which looks lightweight and easier to manipulate. If we cache the XslTransform objects into the memory, just as we (they did in the discussion in the forums) might do in our practices, once the XslTransform is loaded, it is there. And there won't be any trash files in the temp folder, nor will the memory consumption increase as we load (reload) more and more stylesheets--yes, in my ASP.net application, we have the application automatically reload the xsl files if they are modified during the runtime. The auto-reload, but non-memory- leak feature is quite important for ASP.net applications which are expected to run long. If we use the XslCompiledTransform class, this won't be a viable approach since every time we reload the stylesheet, the memory consumption increases and after several scores of reloading, the ASP.net application will hog a monstrous amount of memory, which is obviously neither desirable nor necessary. So, I personally will turn back and stick to the lagacy one, XslTransform class, for not having to clean up temp files, nor worrying about memory consumptions. -- Best Regards, W. Jordan [quoted text, click to view] "Stan Kitsis [MSFT]" <skits@microsoft.com> wrote in message news:4452737c$1@news.microsoft.com... > This might be what you are looking for: > http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=367635&SiteID=1 > > -- > Stan Kitsis > Program Manager, XML Technologies > Microsoft Corporation > > This posting is provided "AS IS" with no warranties, and confers no > rights. Use of included script samples are subject to the terms specified > at http://www.microsoft.com/info/cpyright.htm > > > "W. Jordan" <wmjordan@163.com> wrote in message > news:%23ZmoPEeaGHA.4236@TK2MSFTNGP05.phx.gbl... >> >> Hello there, >> >> Are there anybody who is using the XslCompiledTransform that comes >> with .net framework, which was said to be a replacement of the >> XslTransform class? >> >> I found that the class has some issues when the xsl file contains >> scripts. >> >> The XslCompiledTransform uses the CodeDom to compile the scripts >> within the xsl file into .net assembly and load them into the current >> AppDomain. Some temporary files would be generated during the >> compilation in the temp folder. >> >> This behavior leads to two issues. >> >> 1, The memory consumption of the current AppDomain, i.e. the >> working application keeps growing up if we compile more and more >> xsl files that contain scripts. We have no way to identify the assembly >> generated from the compiled scripts within the xsl files. Thus we can >> not release the resources associated with the xsl files. >> >> 2, The temporary assembly files can not be removed while the >> application is executing, since they are engaged by it. The >> TempFiles.Delete >> method always fails within the application, consequently. And after >> running the application for several times, the temp folder might be >> piled up with the those temporary files. >> >> Are there any approaches to solve these problems? >> >> >> -- >> >> >> Best Regards, >> W. Jordan >> >> >> >> >> > >
I agree with the last post. Stick to XsltTransform being cached in Memory using HttpRuntime.Cache, and having dependencies on the Xslt files.
See http://xsltfilter.tigris.org/ for an opensource project that does exactly this. The project is called XsltFilter and it has been in use on many sites for over 2 years. You can either use it as a Filter on an ASP.NET output stream, or simply call the XsltTransform Factory class to manage your XsltTransform class instances. woric
I don't think there is any difference between obsolete XslTransform and
XslCompiledTransform with regards to scripts. XslTransform leaks the same way, see http://support.microsoft.com/?id=316775. And this has nothing to do with XslCompiledTransform, you just cannot unload assembly in .NET. Use extension objects instead of scripts. -- Oleg Tkachenko [XML MVP, MCAD] http://www.XmlLab.Net | http://www.XLinq.Net | http://blog.tkachenko.com [quoted text, click to view] W. Jordan wrote:
> Hello, > > Thanks for pointing out that. > > Actually I really suspect that whether the XslCompiledTransform should > replace the old XslTransform class, which looks lightweight and easier to > manipulate. If we cache the XslTransform objects into the memory, > just as we (they did in the discussion in the forums) might do in our > practices, once the XslTransform is loaded, it is there. And there won't > be any trash files in the temp folder, nor will the memory consumption > increase as we load (reload) more and more stylesheets--yes, in my > ASP.net application, we have the application automatically reload the xsl > files if they are modified during the runtime. The auto-reload, but > non-memory- > leak feature is quite important for ASP.net applications which are expected > to run long. If we use the XslCompiledTransform class, this won't be a > viable approach since every time we reload the stylesheet, the memory > consumption increases and after several scores of reloading, the ASP.net > application will hog a monstrous amount of memory, which is obviously > neither desirable nor necessary. > > So, I personally will turn back and stick to the lagacy one, XslTransform > class, for not having to clean up temp files, nor worrying about memory > consumptions. >
[quoted text, click to view]
woric@woric.net wrote: > I agree with the last post. Stick to XsltTransform being cached in Memory using HttpRuntime.Cache, and having dependencies on the Xslt files. There should be really serious reason to stick with old buggy slow officially obsoleted piece of code. -- Oleg Tkachenko [XML MVP, MCAD]
Hello,
I set up a smaller environment and tested with two simple XSLT files. One had a small script inside and the other one did't. The consumption of memory goes up as you said and I observed that the Bytes of the Loader Heap of the process was increasing everytime I did trasformations with the XSLT file that has a script. The memory leaks in XSLT with scripts are not yet fixed in .net 2.0. And actually this is my real headache. I don't wanna compel others to use extension objects instead of scripts, yet the loaded script can not be unloaded as you have said. Perhaps a separated AppDomain is the way to go, if we are to have the application to survive a little longer and keep its memory consumption at a reasonable level. Thanks for all that has replied. -- Best Regards, W. Jordan [quoted text, click to view] "Oleg Tkachenko [MVP]" <some@body.com> wrote in message
news:Oq9997aeGHA.1272@TK2MSFTNGP03.phx.gbl... >I don't think there is any difference between obsolete XslTransform and >XslCompiledTransform with regards to scripts. XslTransform leaks the same >way, see http://support.microsoft.com/?id=316775. And this has nothing to >do with XslCompiledTransform, you just cannot unload assembly in .NET. > > Use extension objects instead of scripts. > > -- > Oleg Tkachenko [XML MVP, MCAD] > http://www.XmlLab.Net | http://www.XLinq.Net | http://blog.tkachenko.com > > W. Jordan wrote: >> Hello, >> >> Thanks for pointing out that. >> >> Actually I really suspect that whether the XslCompiledTransform should >> replace the old XslTransform class, which looks lightweight and easier to >> manipulate. If we cache the XslTransform objects into the memory, >> just as we (they did in the discussion in the forums) might do in our >> practices, once the XslTransform is loaded, it is there. And there won't >> be any trash files in the temp folder, nor will the memory consumption >> increase as we load (reload) more and more stylesheets--yes, in my >> ASP.net application, we have the application automatically reload the xsl >> files if they are modified during the runtime. The auto-reload, but >> non-memory- >> leak feature is quite important for ASP.net applications which are >> expected >> to run long. If we use the XslCompiledTransform class, this won't be a >> viable approach since every time we reload the stylesheet, the memory >> consumption increases and after several scores of reloading, the ASP.net >> application will hog a monstrous amount of memory, which is obviously >> neither desirable nor necessary. >> >> So, I personally will turn back and stick to the lagacy one, XslTransform >> class, for not having to clean up temp files, nor worrying about memory >> consumptions. >>
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |