ISAPI Filter and Delphi String Handling
Well, my last three weeks have been stressfull. For one thing, the Borland Developer Studio 2006 German version is in full development and all strings have to be checked - as far as this is possible. But it would not be a normal human life, if there would be only one thing to do at the time.
No, at the same time my company is preparing the release of Content ACE v4 Release 3 and I had to hunt down one bug, which was crashing any newer webserver in a matter of minutes. Well, as you can imagine, this would not be a good feature for a milestone release and our customers would be rather angry. While older, slower servers, wouldn't ever surface that particular problem, some high end machines would. So we did need to get one into our offices - and have just done that.
The next two weeks I was stripping down and rebuilding that particular component, just to realise that I could not really get down to the reason of those crashes. The whole deal proved harder, as there was no special one way to reproduce a crash. It just happened at some point, but usually within 10 minutes of rebooting the server.
Short for the technology: to get to the problem, you have to create an ISAPI Filter, which has to be installed into any particular website running on Microsoft IIS on Windows 2003 Server (or XP Professional for testing). A Filter running on Windows 2000 Server or earlier will not have those problems, as those IIS versions use a different threading model.
Well, MS IIS does not promise you do give request submitted to you ISAPI Filter always the same thread, not even for the same basic request. It took some time to narrow down the problem. It is the normal Delphi string handling that causes this trouble. I don't really know why, but somehow those reference counters seems not to be threadsafe when IIS comes accessing those with more than one (or make it ten for easier reproduction) thread at once.
At some point I got the idea to simply include the unit ShareMem into the ISAPI Filters unit clause and redistribute the borlandmm.dll along with it. Now remember, IIS does not know about ShareMem and will not even use it. However, since the problem has vanished and never resurfaced again. The server is running stable since almost 20 hours!
Interesting thought. So I think I'll try to draw up a good test case and let the engineers at Borland work it out :-)
FYI: In this special product, we are using Borland Delphi 7 as development platform, though we will move to Borland Developer Studio 2006 in January 2006! First tests here look very promising in respect to the overall performance of our system with the new memory manger!
No, at the same time my company is preparing the release of Content ACE v4 Release 3 and I had to hunt down one bug, which was crashing any newer webserver in a matter of minutes. Well, as you can imagine, this would not be a good feature for a milestone release and our customers would be rather angry. While older, slower servers, wouldn't ever surface that particular problem, some high end machines would. So we did need to get one into our offices - and have just done that.
The next two weeks I was stripping down and rebuilding that particular component, just to realise that I could not really get down to the reason of those crashes. The whole deal proved harder, as there was no special one way to reproduce a crash. It just happened at some point, but usually within 10 minutes of rebooting the server.
Short for the technology: to get to the problem, you have to create an ISAPI Filter, which has to be installed into any particular website running on Microsoft IIS on Windows 2003 Server (or XP Professional for testing). A Filter running on Windows 2000 Server or earlier will not have those problems, as those IIS versions use a different threading model.
Well, MS IIS does not promise you do give request submitted to you ISAPI Filter always the same thread, not even for the same basic request. It took some time to narrow down the problem. It is the normal Delphi string handling that causes this trouble. I don't really know why, but somehow those reference counters seems not to be threadsafe when IIS comes accessing those with more than one (or make it ten for easier reproduction) thread at once.
At some point I got the idea to simply include the unit ShareMem into the ISAPI Filters unit clause and redistribute the borlandmm.dll along with it. Now remember, IIS does not know about ShareMem and will not even use it. However, since the problem has vanished and never resurfaced again. The server is running stable since almost 20 hours!
Interesting thought. So I think I'll try to draw up a good test case and let the engineers at Borland work it out :-)
FYI: In this special product, we are using Borland Delphi 7 as development platform, though we will move to Borland Developer Studio 2006 in January 2006! First tests here look very promising in respect to the overall performance of our system with the new memory manger!
posted by Daniel "sakura" Wischnewski at 11:56 AM
3 Comments:
the sharemem library is called: borlndmm.dll and not borlandmm.dll
greetings generic
Oh well ;-) Thanks, you are right.
I realise this thread is about a year old but I have had the same problem and ever since I used the borlndmm.dll the server doesn't crash any more util about 4 or five seconds after an IIS 6 worker process is recycled, either through stopping the application in the IIS aplplication pool or just letting an ASP session expire.
Post a Comment
<< Home