First some history... before IIS 6 there was no notion of an IIS Application Pool.
This meant that if you had more than 1 IIS website that you wish to use SE ISAPI then you could not add the ServletExec ISAPI filter to more than 1 IIS website, because SE ISAPI runs in-process with IIS and a JVM cannot be loaded into the same process more than once. You could do that with SE AS (where the JVM runs out-of-process from IIS), but not with SE ISAPI.
The solution is to have the ServletExec ISAPI filter be added to IIS at the "global"/"master" level... instead of at the level of an individual website.
That way the filter is loaded only once for ALL of IIS. This is what the SE ISAPI (and AS) installers for IIS do.
Multiple IIS websites can make use of ServletExec by simply having a Virtual Directory (VD) with the right name, pointing to the right place, with the right permissions (see other FAQs at this site for more details about that VD, especially FAQ #54).
IIS 6 adds a new feature which Microsoft calls Application Pools.
Here are some details on that feature:
You should use the information above, together with an understanding of ServletExec architecture when deciding:
It is possible to assign IIS website 'A' to run inside IIS application pool 'A',
and IIS website 'B' to run inside IIS application pool 'B'.
Likewise for Virtual Directories (VD's) defined within a website... VD 'A' can be configured to
run inside app pool 'A', or app pool 'Z', or... etc...)
- It is also possible for IIS to be configured to shutdown an idle application pool after some period of time
(20 minutes by default, at the time of this writing).
- Whether to use SE ISAPI or SE AS
- Whether to use multiple IIS app pools or a single app pool
- Whether to have your IIS app pool(s) cycle themselves after set periods of time and/or inactivity
If using SE ISAPI, all IIS websites that use SE (by defining a Virtual Directory which points to the SE ISAPI DLL) must
be assigned to the same single IIS Application Pool and here is why:
It is possible to assign IIS website 'A' to IIS application pool 'A', and IIS website 'B' to IIS application pool 'B'.
If you did that there would be 2 distinct JVM instances each running SE ISAPI.
Each instance would startup when the first request to their host is received.
Note: The whole website must be assigned to the app pool, not just a VD within it, else you may get 403 Access Forbidden responses for servlet requests).
But just because it's possible, doesn't mean it should be done.
If this were done, only the first SE ISAPI instance that starts up will be able to write to any log files properly:
ServletExecNative.log ServletExec.log Servlet.log (for the default context)
This is because the 1st instance will open the files making them be locked to the 2nd instance (2 instances but one set of log files, config files, etc... for those instances). If one SE ISAPI can't read a configuration file due to it being locked by another SE ISAPI then it will startup in a default state. For example servletexec.xml contains the license key. If an SE ISAPI can't read the key that's in that file due to not being able to read that file at all, then it will startup in an unlicensed state.
Note that this situation could also cause odd problems with configuration files. Another example is if you had defined your own custom SE Virtual Servers (each handles requests that use a specific hostname). In that scenario you'd have more than 1 SE Admin UI Web App that you could access and use to define different settings (each SE VS defines its own set of webapps), but different "instances" of SE should not be writing to the same configuration files (for example application.xml which defines the set of webapps for an "instance" of ServletExec). Using the Admin UI for each of the various SE VS's when SE is "multi-loaded" in this invalid manner would result in configuration file "corruption", and seemingly "lost" settings (lost license key, webapps that mysteriously become undeployed, etc...).
This could also result in log file issues such as ServletExec.log not being rolled over, or rolling onto itself making it impossible to use those files successfully.
So, currently we don't support the use of multiple app pools with SE ISAPI.
For additional details about this, please see SE Interest List Posting #221073.
We strongly urge you to read that posting.
If you need to have some servlets running separately from others (meaning in a separate, isolated process from others) then consider using SE AS instead of SE ISAPI. The native component that hooks into IIS for SE AS does not write any log files so there should not be any conflict there. That native component could be loaded into 1 single IIS app pool (most efficient) or could even be loaded into more than 1 IIS app pool (probably uneccessary, see SE FAQ #259 for more details about the performance implications of doing that).
If IIS is configured to shutdown an idle application pool after some period of time (20 minutes by default) then SE will shutdown (as expected). It comes back up just fine the next time a request comes in.
If it's SE ISAPI that you have hooked into IIS, then be aware that shutting down SE means that the whole JVM will shutdown, and all webapp's that are deployed in SE, all servlets will have their destroy() methods called. Upon startup, everything will initialize again, a potentially costly process, and may not be exactly what you had hoped for.
If it's SE AS that you have hooked into IIS, then it's just the native adapter that gets shutdown and restarted when the app pool shuts down and restarts (since that's the only ServletExec component running in that app pool). Basically with SE AS, the portion that snaps into IIS is much more lightweight... the JVM runs in a separate process and the ASI runs inside that JVM, so your JVM and your ASI stay up and running, even after the IIS app pool has been shutdown.
More information about the architectural differences between SE ISAPI and SE AS can be found here, in addition to the ServletExec Installation Guide, and the ServletExec User Guide.
You may also find this Microsoft webpage to be of interest.
And here is another useful webpage.
SE Interest List Posting #221073 will also be of great interest if you have multiple Application Pools in your IIS 6 (or IIS 7 or newer) installation.
If for some reason, you must have multiple IIS Application Pools but must also use SE ISAPI and cannot use SE AS then here are some tips for configuring IIS to use SE ISAPI in a safe manner (however this path would not be our first recommendation... using SE AS would be best):
- By "safe", we mean... SE ISAPI only being loaded once... by one single IIS Application Pool.
- First you'd need to move the SE ISAPI Filter out of the "Global/Master" Level of IIS and place it at the level of the website with which you want to use SE ISAPI. You'd do this for each IIS website that needs to run Servlets or JSPs inside SE ISAPI. Normally this is a huge no-no. And if you just stopped here it still would be. So continue...
- This is the tricky part... you must Ensure that ALL areas of ALL websites that have the SE ISAPI Filter added at their level use either:
- NO IIS Application Pools at all
- The exact same single IIS Application Pool (i.e. A "common" App Pool)
- This way other websites could make use of other application pools and since the SE ISAPI filter would not be added to those websites and would no longer be added at the Global/Master level of IIS, the SE ISAPI DLL won't be loaded in those other app pools (and that's good).
- If you use IIS 7, and create a new website... each new site that you create will (by default) be setup to run inside its own separate application pool. So be aware of this. If your SE ISAPI Filter is at the global level of IIS then this would cause it to be loaded multiple times which will certainly cause problems. In that scenario you'd either need to move the filter down to the website level (as mentioned above) and/or access the properties of that website and remove its "Default Application" or configure it to use a common app pool.
- Also be aware that when you create any new Virtual Directory in any IIS website, it is very often not really a simple Virtual Directory but is rather an IIS .NET Application... meaning that it is configured to "execute" inside an IIS App Pool. Look at the properties of all your Virtual Directories to ensure that they are not actually applications configured to use distinct/different application pools. If they collectively make use of even just 2 different app pools AND the SE ISAPI Filter is at the global level of IIS then as soon as a request comes to each distinct App Pool you'll have SE ISAPI loaded twice inside IIS which is very bad.
- If you intend to make these configurations in order to run SE ISAPI on an IIS 6 or 7 that has multiple Application Pools, then please be aware: When you make manual changes to the ServletExec ISAPI Filter configuration in IIS [by moving it from the global level to the level of specific website(s)], the SE Uninstaller does not know that you did this. So if/when you or someone else later uninstalls SE ISAPI, the filter will not be removed from IIS. You or that person would have to manually go remove the SE ISAPI Filter from all the places it was manually added in that IIS. Otherwise IIS will keep trying to load that filter and will fail (since the ServletExec_ISAPI.dll file would have been removed). This could prevent IIS from serving any requests at all, essentially breaking IIS until the SE ISAPI Filter is manually removed as needed. So this is just one reason why we don't particularly recommend this path. We recommend using SE AS instead, when you need to use multiple Application Pools in your IIS.
NOTE: The same architectural limitation that prevents SE ISAPI from functioning properly in an IIS environment that uses Multiple Application Pools, would also exist in an IIS environment that uses Multiple Web Gardens. So ServletExec ISAPI does not support the use of Multiple IIS Web Gardens. The Web Garden value must be set to 1. No other value.