Board index » delphi » SOAP issues with threading and ISAPI

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
 
 

Re:SOAP issues with threading and ISAPI

J. Zwart writes:
Quote
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.
Are you using the ISAPIThreadPool? Check out
shenoyatwork.blogspot.com/2004/06/soap-insanity-expecting-textxml
.html to see if you're using the correct order (ISAPIThreadPool must
come AFTER ISAPIApp)
Quote
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 DLLs.
That's incorrect: It *is* perfectly safe to use threadvars in DLLs. A
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.
Quote
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.
This is something I have never come across - we've run performance
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.
Quote
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.
Maybe there is a solution in D2005 - source code hasn't changed very
much but can you let me know which exact code you refer to? Maybe we
can fit it in somewhere.
Quote
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.
WSDL doesn't handle inheritance very well, and Delphi omits WSDL
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