Friday, December 16, 2005
Then yesterday evening I finally got around to giving it a try. Needless to say, I was very disappointed when I couldn't install it right away. I had the following problems:
First, I got InstallShield error saying something like "Failed to extract file 'Dll_.ini' from the binary table".
I googled for the error message and came up with a solution: run DCOM configuration utility (dcomcnfg.exe) and grant the necessary user(s) and/or group(s) the default launch permissions.
Initially, I only included the local Administrators group (which my interactive user account is a member of) and also specifically my interactive user account (which was probably unnecessary). This solved the above problem but the installation still failed a bit later... with a message roughly like "Installation interrupted, nothing installed". I checked my running processes and noticed that Windows installer (msiexec.exe) is running under local SYSTEM account. So I granted the default launch permissions to this account, too.
That solved the problem and I have now successfully installed Delphi 2006!
W00t! It feels like Christmas already! ;-)
Wednesday, September 14, 2005
You can register your DataSnap appserver as stateless by calling
RegisterPooled in the overriden
UpdateRegistry class method of your remote data module.The problem with the way httpsrvr.dll manages stateless objects is that, ehm, it's stateful. ;-) More precisely, it's stateless only within a single IIS session.
TWebConnection) and the server (httpsrvr), in case of stateless/pooled appservers:
- The client sends
asCreateObjectrequest with the appserver's CLSID to the server. (see
- The server checks its list of CLSIDs (creating a new item if it does not exist) and return its index within the list back to the client. No instance of the class is created at this point.
- The client stores the returned integer value which is used to identify the class in subsequent
asInvoke(method call) requests.
- The client sends a
asInvokerequest to execute a method remotely on the appserver. (The communication between a
TProvideralso works via remote method calls, the relevant methods are defined in the
IAppServerinterface which is implemented by all
- The server checks its list of CLSIDs, finds the entry and checks its instance pool for any unlocked (ie. not currently processing a request) instance. In case no idle instance can be found at the moment, it will create a new one, up to the maximum size of the pool you specified in your
RegisterPooledcall. (In case all instances are locked and the pool is already at its maximum size, the server will return a "Server is busy" error.)
- The client may send additional
asInvokerequests as needed. The server dispatches the calls to any currently idle instance in the appropriate pool. Hence, your appserver logic must be stateless, ie. it cannot assume that any context is preserved between the calls since they may be executed by different instances.
- Cleanup on the server is performed by a separate garbage collector thread which releases any unused instances after a specified timeout. Even if no instance is any longer active (the pool size drops to zero), the item in the list of CLSIDs remains unchanged so clients may issue additional requests; these will be served by instances created on demand.
- When the client is finished with the appserver, it will send an
TDataDispatch.Destroywhich is called due to reference counting). If the appserver has been registered as stateless, the server does not release any instance at this point - rather, the instances are kept in the pool, ready to serve additional requests or eventually be released by the garbage collector.
But what happens if you restart IIS anywhere after step 3? Sure, upon receiving another HTTP request with a relevant URL, IIS will load and run httpsrvr.dll again, but the Object Manager's list of CLSIDs is empty after a fresh start; the integer value sent by the client makes no sense since it cannot be resolved to a CLSID. This is the case when the server sends the "Could not find server in ObjectManager list" error back to the client. In an even worse case, if other clients have sent requests in the meantime, the list indexes may be different so the call will be dispatched to an instance of a different class, which will probably result in some COM exception because of the (very probable) typeinfo mismatch. (In a yet worse scenario, think about what happens when the method dispatch IDs and signatures of the two different appservers match by coincidence. ;-)) In either case, from the client's point of view, important state information (the association between the CLSID and its token) is lost.
So how can this problem be solved? I can imagine two options:
- Modify the DataSnap code so it never uses the tokens. Let the client pack the CLSID with every call. The disadvantages of this approach are:
- GUIDs take 16 bytes, as opposed to 4 bytes for an integer.
- All your client executables out there will become obsolete/incompatible with your appservers; you'll have to recompile and redistribute them.
- Modify httpsrvr.dll so it ensures that the token values don't change from one IIS session to another. This can be done by preloading the list in the initialization and not on demand so the index values are not dependent on the order in which clients send requests.
I have chosen the latter option. To preload the list of registered appservers, I use the (slightly modified)
GetMIDASAppServerList procedure from the
MConnect unit. The thousands of already distributed client applications will continue working as before; in addition, I can restart my web server between their calls without interrupting their work.
Saturday, August 13, 2005
Petr Vones has written a hack (a patch for rtlxx.bpl) to turn off duplicate unit checking which will improve Delphi IDE start-up speed. If you're going to use the patch, be careful - make sure that the packages which you load into your Delphi IDE do not contain duplicate units.