WkHtmlToXSharp
WkHtmlToXSharp copied to clipboard
pruiz
Asp.net/IIS Support
In issues #30 and #10, its stated that this project does not support IIS/ASP.net. This is because of of incompatibilities with the app pool recycling and the releasing of resources in non-managed code.
Is it feasible to update how those resources are managed in order to fix this issue? I'm willing to put in the effort to try and make this project compatible with the app pool recycling if I could be pointed in the direction of where these non-managed code resources are at.
Replacing IntPtr usage in the P/Invoke calls with SafeHandle implementations may go a long way in ensuring that unmanaged resources are released on shutdown of AppDomains.
Not really, as the one who releases this memory is nothing related to .Net. But internal memory management at wkhtmltox.
But we are open to accepting patches/prototypes.
Regards
On Fri, Feb 3, 2017 at 9:20 PM, Gerke Geurts [email protected] wrote:
Replacing IntPtr usage in the P/Invoke calls with SafeHandle implementations may go a long way in ensuring that unmanaged resources are released on shutdown of AppDomain s
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pruiz/WkHtmlToXSharp/issues/42#issuecomment-277352007, or mute the thread https://github.com/notifications/unsubscribe-auth/AALq-S5_QZ9TbgcI6DUkEucRWS2XCBtnks5rY4wBgaJpZM4LjQ4O .
@pruiz, so to make this project directly usable in an IIS project, the C++ project would have to be updated? There isn't anything on the C# end that can clean up the resources?
@nicholasguyett It is not (just) an issue with regards to cleaning up resources. There's also the way each process (IIS AppPool vs wkhtmltox) work (compete) with it's internal threads management code, IIS AppPool recycling, etc.
As an example, of one of the worst cases take this one: when wkhtmltox receives some pointers to callback functions it will be invoking as conversion progresses. We can make such pointers/methods safe from collection, however, we cannot control IIS AppPool recycling (more than disabling it, which is not a great idea). So you can end up with native (wkhtmltox) code, trying to invoke a managed funcion/method, no longer existing in memory, as IIS has dumped/re-created the managed application while wkhtmltox was still working on conversion..
Just to confirm, this project is wrapping a different wrapper (wkhtmltox)?
Top google result for this is wkhtmltox which is a nodejs project, which seems an odd choice. I did also find wkhtmltoxdotnet but that project seems barely used. Are you using one of those or a different library entirely?
The previous commit solved the issue for me as well. I was having trouble with the garbage collection of the callbacks and after updating the nuget packages from 1.2.4 to 1.2.7 (which I'm guessing includes this commit) it solved it for me.
So, should the next commit be the removal of the following text from Readme.md or are there any other issues with IIS?
Text to remove:
No ASP.NET/IIS Support: This has to do with the way IIS manages underlaying threads, and application pools. IIS instantiates & re-cycles pools and AppDomains from time to time, and this causes non-managed resources used by this library to not be released properly.
What was fixed was an issue with GC collecting non-managed pointers, affecting everybody. :)
The IIS/AspNetPool issues, still apply. As there's no (that I now) way to handle/force restarting of non-managed (memory) stuff when IIS performs it's automatic managed AspNetPool recycling. :(
On Thu, May 18, 2017 at 1:32 PM, João Antunes [email protected] wrote:
The previous commit solved the issue for me as well. I was having trouble with the garbage collection of the callbacks and after updating the nuget packages from 1.2.4 to 1.2.7 (which I'm guessing includes this commit) it solved it for me.
So, should the next commit be the removal of the following text from Readme.md or are there any other issues with IIS?
Text to remove:
No ASP.NET/IIS Support: This has to do with the way IIS manages underlaying threads, and application pools. IIS instantiates & re-cycles pools and AppDomains from time to time, and this causes non-managed resources used by this library to not be released properly.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pruiz/WkHtmlToXSharp/issues/42#issuecomment-302378368, or mute the thread https://github.com/notifications/unsubscribe-auth/AALq-Wjk7EWM4b3J1o33C_K2tD45gadTks5r7CxogaJpZM4LjQ4O .
Would implementing IRegisteredObject (more) for pre-.net core and ApplicationStopping for .net core help with this? This would allow for notification of when the app pool intends to reset and gives a chance to clean up and potentially block if a conversion is in progress.
@Rfvgyhn If there was a way to 'completely' cleanup wkhtml resources, probably yes. But the thing is, trying to dispose/stop/shutdown and then re-intialize wkhtml engine under a single running program has never worked fine in my experience, and most of the time it wont re-initialize ok, or the process will end up crashing.
only if it run under IIS.
On Fri, Aug 24, 2018 at 5:02 PM Jeremy Nicoll [email protected] wrote:
Does this also apply to the .Net Core/Kestrel setup?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pruiz/WkHtmlToXSharp/issues/42#issuecomment-415786250, or mute the thread https://github.com/notifications/unsubscribe-auth/AALq-dP0E7BwnE7iuuXz29lcGViwolMwks5uUBWagaJpZM4LjQ4O .