Board index » delphi » SOAP issues with threading and ISAPI

2006-03-15 04:03:43 PM
delphi75
Hi all,
I experienced some problems with Delphi 2005's built-in SOAP and ISAPI DLL's in a threaded environment.
1. The performance drops when making more than one concurrent connection. For example: the handling of one concurrent requests takes 200 ms, two concurrent requests take 400 ms per(!) request and so on. It looks that there is some major locking going in the SOAP components.
2. The SOAP components are using threadvars for some variables, more specifically for the variable which holds a pointer to the current instance of the webmodule (retrievable with GetSoapWebModule()) even when the documentation of threadvars states the following:
“The threadvar section can only be used for global variables. Pointer and Function variables can not be thread variables. Types that use copy-on-write semantics, such as long strings don't work as thread variables either.?
I am not sure, but IIRC a DLL is a copy-on-write environment *and* a previous version of the documentation makes an explicit note that it is not safe to use threadvars in DLL’s.
The problem is that we need some variables of the webmodule, but sometimes a webmodule is retrieved from a different thread by GetSoapWebModule() so our data is mixed up.
3a. Some minor problems like a limit on the size of a request being 48 KB. I found references to this in newsgroups with solutions that work for Delphi 7, but the source code has changed since that version so we cannot use that solution.
3b. Also there seems a problem with registering objects with RemClassRegistry.RegisterXSClass() and inheritance. Base classes are not published in the WSDL. Only after using a dummy method which has the base class as a parameter, the classes are published. I also had a look at RemObjects, but it has the same problem with inheritance.
Greets,
Joris
 

J. Zwart writes:
shenoyatwork.blogspot.com/2004/06/soap-insanity-expecting-textxml
.html to see if you're using the correct order (ISAPIThreadPool must
come AFTER ISAPIApp)
thread var means the variable is assigned in the Thread's local
storage, meaning there will be a copy for every thread created.
DLLs can spawn any number of threads they like and therefore threadvars
will retain validity in DLLs.
tests on soap ISAPIs with 100 or more simultaneous threads, but we've
never had cross thread instances seen. Having gone through the code, I
can say that unless there's some kind of memory corruption this should
never happen.
much but can you let me know which exact code you refer to? Maybe we
can fit it in somewhere.
definition of base classes if they're not directly used. You can change
it by changing Delphi's WSDL emitting method, but I haven't done this
myself to be sure...
--
Deepak Shenoy (TeamB)
shenoyatwork.blogspot.com