You must use SE AS.
As of February 2009, using SE ISAPI with IIS 6 or higher is no longer supported or recommended. The reasons why are given below.
Microsoft introduced some architectural features beginning with IIS 6 which have forced us to recommend using SE AS *instead of* SE ISAPI when using IIS version 6 (or greater).
To better grasp the remainder of this FAQ, it is important that you first get a basic understanding of the architectural differences between SE ISAPI & SE AS.
For that you should read and study the SE configurations page.
So with SE ISAPI, the JVM (and thus SE and all the servlets & JSPs that you deploy inside SE) run inside the IIS process.
So it (i.e. the JVM) is at the "mercy" of IIS and windows.
With SE AS, the JVM runs in its own separate / isolated process... apart from the webserver's process.
So it has a bit more "freedom".
SE AS can often allow a person to side-step several potential limitations that IIS/Windows impose.
SE AS has more moving parts yes... but the tradeoff (in our opinion) is a more flexible, stable setup (when using IIS 6 or higher).
Here are a few specific reasons why we recommend using SE AS over SE ISAPI (when using IIS 6 or higher):
- IIS 6 (and higher) has Application Pool(s) which cycle themselves at pre-configured intervals.
For SE ISAPI this means the entire JVM gets shutdown and does not come up again until
a request comes in, which makes that request "run" slowly.
For more details read SE FAQ #270
specifically beginning where it says:
If IIS is configured to shutdown an idle application pool after some period of time ...
- This is a large point.
Summary:
Sometimes people want to have more than 1 IIS website, where each website is configured
to run inside its own IIS Application Pool (i.e. Multiple Application Pools).
SE ISAPI can't be used with Multiple Application Pools.
See SE FAQ #270 for more details.
SE AS however could be run from Multiple Application Pools.
Having more than 1 IIS website may or may not be your situation.
The main issue is with having more than 1 IIS Application Pool... even if you have only 1 IIS Website. And it may also be important to understand that some software that you or someone else installs on your IIS box may in fact create additional IIS Application Pools (possibly without you even realizing it). Microsoft Sharepoint is one example as it creates it own Application Pool within IIS.
Details:
The Application Pools Feature of IIS 6 (and newer) can very easily (often
without your knowledge) be utilized in a manner that is unsafe for SE ISAPI.
For gritty details about that please see this SE Interest List Posting #221073
This condition can be worked around when using SE ISAPI, but it can be a bit tricky to do properly,
and if others can administer your IIS then it would be very easy for the problem to be re-introduced
by someone who does not understand the nuances (especially with IIS 7).
SE AS would still be effected by this condition, but it would not create an unsafe/unstable condition.
In other words... SE AS would be far less effected by this condition, and would in fact run just fine.
- 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. So the ability to configure the Web Garden setting presents a threat to SE ISAPI stability.
-
As of February 2009 it has been realized that because of how IIS manages even just 1 single Application Pool, that SE ISAPI cannot be used with 100% reliability with IIS 6 or higher. Consider an IIS installation that has only 1 single App Pool (and also whose Web Garden setting is exactly 1)... If/When IIS decides to cycle that App Pool it will first start up a new App Pool to take it's place. That new App Pool will begin to handle new incoming requests while the "old" App Pool actually remains in existence for an unspecified amount of time (while it finishes processing "old" requests). This is how IIS manages a single Application Pool cycling. It may be thought of as a sort of failover or "hand-off". This presents a problem for SE ISAPI (but not for SE AS) since it means that 2 Application Pools (and thus 2 SE ISAPI JVMs) are up and running at the same time (albeit a very brief time). SE ISAPI simply cannot run reliably when it is loaded more than once on the same machine. For this reason the use of SE ISAPI with IIS 6 is absolutely no longer recommended for any reason. Period. Configuring IIS 6 to not cycle its one App Pool, or to run in "IIS 5 Process isolation mode" may be the only ways to use SE ISAPI with IIS 6 reliably. But we do not recommend these options as they represent configurations that may easily be undone, and are not the "natural" (or preferred) way to run IIS 6.
- When you use SE ISAPI, IIS/Windows will restrict the amount of RAM you can give to your JVM.
For more details, see SE FAQ #317.
- By using AS, you side-step this common issue that often occurs when using ISAPI.
and also side-step less common issues such as the one described by SE FAQ #356
and you can also avoid being impacted by some JVM 1.5.0 bugs that are described by SE FAQ #338
and you also avoid having to configure your IIS 6 to run in IIS 5 Isolation Mode.
This point is fairly uncommon, but using SE AS ensures it won't happen to you.
For more info please see SE Interest List Posting #217844.
- If your Windows OS is a 64-bit version, then so is your IIS installation. If you wish
to have your SE 5.x instance use a 64-bit JVM (that would be the sensible thing to do on such a machine)
then for SE 5.x, using SE ISAPI would not be an option. This is because with SE 5.x ISAPI, SE's native
DLL that hooks into IIS is only available in a 32-bit build (unless your CPU is Itanium which is rarely the
case for anyone... most folks 64-bit machines are using AMD or Intel Xeon chips). A 64-bit IIS can be configured
to load a 32-bit DLL (ServletExec_ISAPI.dll), however a 32-bit DLL cannot load a 64-bit process (i.e. a 64-bit
JVM). So in this scenario, the only way to have your ServletExec 5.x run with a 64-bit JVM is if you use SE AS.
For more details, please see SE FAQ #302
And also see SE Interest List Posting #188033.
Note that beginning with SE 6.0, this point is less of an issue since SE 6.0 (both ISAPI and AS)
supports both 32-bit & 64-bit IIS 6 & 7... natively.
ArcIMS Users
If you are wanting to use ArcIMS with SE AS & IIS, then before you run the ArcIMS Post-Installer
please read SE FAQ #346, and also consider the fact that certain advanced ArcIMS setups are only possible with
SE AS (not with SE ISAPI). By this we are referring to the setup described in the PDF
"Deploying ArcIMS Within a Corporate Firewall" whitepaper linked on this page. |
products
