iPlanet Application Server 6.0 FAQ

By Kevin Boone
Last updated October 2000.

Disclaimer
The author is a certified iPlanet instructor, but not a member of the iPlanet organization. Please bear in mind that the following notes are based on my own experiences, and those of other people working with iPlanet Application Server in the field. They do not constitute official policy of the iPlanet organization. Statements like `...has been found to work in practice' mean exactly that: at least one person has reported success. They should not be taken as a recommendation to follow a particular course of action.
Scope and purpose of this document
This document provides answers to questions that I am often asked by students attending courses on iPlanet Application Server administration. It does not address issues related to application development (a different document is available for this), although some development issues are covered where relevant.
General information
Q Is there an `official' FAQ supported by iPlanet ?
A Not yet. There is an FAQ for version 4.0 (NAS 4.0), available at the same place as the manuals (see below).
Q What is the current version of iAS ?
A At the time of writing, the most recent version is 6.0, service pack 1, release B. Most of this document applies to the earlier (pre-SP1) version as well; indication is given where this is not the case.
Q Where can I get online versions of iAS manuals ?
A From the iPlanet Web site: docs.iplanet.com/docs/manuals/ias.html.
Q Why do the terms `Kiva', `NAS' and `GX' appear in the names of iAS components ?
A KivaSoft is the name of the corporation that developed the first version of the application that eventually became Netscape Application Server (NAS). GX (Global eXchange) was the system it used for embedded dynamically-generated data into Web pages.
Q Who is in charge of iAS development now ?
A When Netscape was bought by AOL, NAS became part of the AOL product line. AOL and Sun Microsystems have entered into a joint venture to develop e-commerce support tools. This venture is called iPlanet, and NAS has become part of the iPlanet product range. iPlanet is funded equally by Sun and AOL, with profits also being divided equally. iPlanet is not a separate business, but has a degree of autonomy within its parent corporations. Therefore the future development of iAS is in the charge of the iPlanet engineering group.

System requirements
Q What platforms does iAS support ?
A The following table shows the configurations that are supported by iPlanet, and others that have been found to work in practice. Of course, using an unsupported configuration in a production environment is not something to embark upon lightly.

System Versions

Solaris¹ 2.6², 2.8

Windows NT 4.0 SP5³

HP-UX 11.0

AIX 4.3.3

¹ Solaris 2.7 is widely reported to work also.
² Solaris 2.6 requires kernel patches.
³ Windows 2000 also works, but see notes below.

Q Will iAS run under Windows 2000 ?
A It has been reported to work by a number of people, although it is not officially supported. There are a number of complications with using it in a non-networked development system, (e.g., a laptop) all relating to the fact that iAS needs a real IP number to communicate between processes on (i.e., not localhost). Windows 2000 does not activate network interfaces if there is not a `real' network connection. You can get around this problem by installing the `loopback' network device that is supplied with Windows 2000. This can be assigned any IP number you want, and iAS will accept this as a valid IP number. You should do this before installing iAS, because the only way to fix it afterwards is to fiddle with the registry. And the IP number appears in over 20 different places in the registry...
Q Will iAS run under Solaris 2.7 ?
A May people have reported success, but it is not supported.
Q What Solaris versions does iAS support without kernel patches ?
A All versions of Solaris 2.8 will run iAS without patches.
Q How much memory (RAM) does iAS require ?
A iPlanet's official recommended minimum is 256 Mb. You will find that if you plan to run development tools like iAB on the same server, plus a database engine, plus a Web server, you will need a lot more memory than this. There are reports that it will work with less, but not very effectively. I have found that the memory requirements for the application server are larger by about 50% under extremes of load.
Q What databases are supported ?
A The following table shows the configurations that are supported by iPlanet, and others that have been found to work in practice. Of course, using an unsupported configuration in a production environment is not something to embark upon lightly. This table assumes the use of drivers supplied by iPlanet; see notes below about third-party driver support.

Server NT client Unix client

Oracle¹ 8.0.5, 8i, 7.3.4 Oracle 8.1.5 Oracle 8.1.5²

Sybase 11.9.2, 12 Sybase 11.1.1 Sybase 11.1.1

Informix 7.3³ Informix 2.10 Informix 2.10

DB2 5.2, 6.1 DB2 5.2 DB2 5.2

MS SQL 7 MDAC 2.1 SP2 Not supported

¹Oracle 8.1.5 server also works; note that on Solaris this server requires kernel configuration changes (although they are well-documented)
² Oracle 8.0.5 client also works, and is widely used. 8.0.5 client does not work on Solaris.
² At the time of writing, Informix server does not support global transactions via the XA protocol, and therefore cannot be used with global transactions in iAS.
Q Can I use third-party JDBC drivers with iAS (and how) ?
A As of the SP1 release, iAS allows access to databases using any JDBC type-2 driver. This has been tested using drivers supplied by Oracle, Merant and Sybase, but others should work. However, although these drivers should allow the use of container-managed connections (connection pooling, etc), global transactions are not yet supported. The third-party drivers must be registered during installation, or using the db_setup program, just as for iPlanet drivers.
Q What Java versions does iAS support ?
A iAS is only certified to work with JDK1.2.2, a full installation of which is supplied with the product. JDK1.2.1 will compile iAS applications, but they won't work when deployed. iPlanet does not recommend that other JDK versions -- even those compatible with JDK1.2.2 -- be used with iAS. In particular, the use of JDK1.3 is not supported.

General administration
Q How do I start and stop iAS ?
A A complete iAS server group consists of the application server itself, an LDAP server, and (optionally) a Web server. You can start and stop all of these independently, and in any order, with the exception that the application server won't start up without the LDAP server running.
      On a Unix system, the start commands are as follows.

Service Command

LDAP server [appserver_base-directory]/slapd-[hostname]/start-slapd &

Web server [webserver_base_directory]/https-albert.sunedu.co.uk/start &
Note that the Web server can take some time to come up on a Solaris system (more than 30 seconds is not unusual)

Application server [appserver_base_directory]/ias/bin/KIVAes.sh start & (pre-SP1)
[appserver_base_directory]/ias/bin/iascontrol start & (SP1)

The `stop' commands should be obvious; note, however, that KIVAes.sh stop is not recommended because it does not give the failover mechanism time to work (see below).
      On a Windows system you can use the `Services' section of the Control Panel to start and stop the components. You can also use the net start [servicename] command to do the same thing from the command line.
      Note that by default iAS starts at boot time on a Windows system, but not on a Unix system. If you install iAB at the same time on a Windows system, it behaves like the Unix version, in that the iAS processes do not start at boot time. This is to allow the iAB tool to start and stop the processes itself.
      The admin tool (ksvradmin) can also be used to start and stop the application server, but only if it is initially running. At least the kas process has to be running for the admin tool to work. Under SP1, the iascontrol script takes the place of KIVAes.sh, This script can be used to initiate a graceful shutdown or an immediate kill.
Q Does the iAS server have to run as root ?
A No, and probably it should not. The iAS installation procedure gives the opportunity to have the program files owned by a non-root account, and if this is done then there should be no problems running the server under this account. On my development system, I have iAS owned by my normal login account, which makes it easy to copy files manually into the APPS tree.
      There may be problems running the LDAP server under a non-root account, because its default port (389) is privileged. However, this port number can be changed during installation if required.
Q Is it possible to run multiple iAS servers on one computer ?
A This has been reported to work, at least on Unix systems, but is only officially supported for SP1 or later. It will be necessary to allocate new port numbers to all the engines. The reason it doesn't work on Windows systems is that a common registry key is used to store the local configuration data.
Q Why does running KIVAes.sh stop not work ?
A This script uses the environment variable `LOGNAME'. If LOGNAME is not set to the owner of the iAS processes, it won't work. This sometimes happens when using su to change to root authority, rather than logging in as root. The solution is to execute the command export LOGNAME=root first.
Q Can I `uninstall' an application ?
A As of the SP1 release, you can unregister an application using
j2eeappreg -remove [EAR_file]
but this does not remove the application files themselves. Note that you need the original EAR file to be able to carry out this job. Prior to SP1, you would need to edit the registry manually to get this effect.
Q What constitutes a successful `engine restart', and how many times will iAS attempt to restart an engine ?
A An engine (kxs, kjs, etc.) is considered to have been successfully restarted if it gets to the state where it can process requests. Even if it crashes two seconds later, that's still considered to be a successful restart. iAS will restart an engine a number of times that is configurable using the admin tool (default 10) before giving up. If it does give up, it can dispatch an event to that effect.
      There is no built-in mechanism to detect the specific condition where an engine starts, works for a short time until overcome by load, and then crashes. Of course you can get an event to the effect that an engine has gone down, but iAS does not provide a `severity' mechanism that distinguishes repeated crashes from occasional ones (apart from the frequency of the events, of course). It is possible to have the event handling mechanism call a script, which checks the time that has elapsed since the last instance of that event, and acts according to whether the events appear uncomfortably frequent.
Q What is the significance of `server shutdown time' ?
A It is always possible to stop an iAS engine by killing it at the operating system level. However, in a production environment this may cause it to go down while still holding requests in its queue. The failover mechanism in an iAS cluster will dispatch requests to any server that is working, and competent to answer the request, but it can't extract requests from a dead server's queue. Shutting a server or engine down using the admin tool gives the process a chance to clear its queue before going down, but without accepting any new requests. The failover mechanism should transparently divert its load to another server. If the process does not signal that it is going down within the specified shutdown time, then the admin tool sends it a signal to shutdown immediately.
Q Does iAS support SNMP ?
A Yes, to a limited extent, but it is not enabled by default.
Q Can iAS servers share an LDAP server for configuration information ?
A Yes, this can be set up at installation time, provided the shared LDAP server is already available. While servers in a production environment will almost certainly want to share an LDAP server for application-level authentication, it is less obvious that they will want to do so for configuration. An alternative approach is to have a local LDAP server for each iAS server for configuration, and a shared LDAP for application-level authentication.
      If you do share an LDAP for configuration, two issues require some thought. First, will you use a common directory entry for configuration, or separate entries? If common, then all configuration for all servers is identical. This has the advantage of allowing a single point of configuration for a group of servers, but the disadvantage that the servers must be absolutely identical in configuration. Clearly, application partitioning will be impossible. Second, what arrangements will you make to protect against failure of the shared LDAP server? Clearly this server is crucial to the success of the system, and must be replicated in some way.
Q What does `disabling' a process do ?
A It continues to run, but does not accept any new requests.

Operating principles
Q What are the iAS server processes ?
A

Process Purpose

kas Administration server; start and stops kxs, kjs and kcs processes; communicates with the admin tool; reports errors

kxs Executive server; accepts requests from Web connector and dispatches to appropriate kjs or kcs, or perhaps to another kxs if load balancing is in use; Synchronizes session data between cluster members; collates load-balancing information

kjs Java server; executes Java servlets and JSP pages

kcs C server; executes NAS `AppLogics'

cxs CORBA-iAS bridge; supports IIOP clients

Q What does iAS used LDAP for?
A Nearly everything. Most configuration information is stored in an LDAP directory, as is user and group authentication information. This authentication includes system-level authentication (e.g., which users are permitted to deploy applications on the server) and application-level authentication. Of course, the application developer can have the application use any kind of authentication system; however, the iAS forms-based authentication mechanism uses LDAP, so it makes sense for the developer to use LDAP for user and group information as well.
      iAS can be configured to use two different LDAP servers: one for application-level authentication, and one for system configuration.
Q Where does non-LDAP configuration information go?
A On Unix systems, this information goes into a plain text file called reg.dat. On Windows systems, it is integrated into the Windows registry.
Q What protocols are used for communication between iAS components ?
A The protocols are proprietary and undocumented: `KCP' (Kiva Communications Protocol) and `GXCONN'. In some cases the KIVA message may form only a wrapper around another protocol; for example, the communication between the Web connector and kxs is standard HTTP (or HTTPS) wrapped up in a KCP packet.
Q What is `request flow control' ?
A An iAS engine will attempt to allocate new threads to incoming requests (up to a specified number), and queue any requests that cannot be handled immediately by an existing thread. Queuing is only used when the maximum number of threads is exceeded. The administrator can enable `request flow control' to limit the number of requests that are queued. When the maximum queue size is reached (`high-water mark') no further requests are accepted. The engine remains in this state until it has cleared enough requests for the queue to reach the `low-water mark'.
      If flow control is disabled, there is no restriction on the size of an engine's request queue (apart from system resources, of course). Enabling flow control is usually only helpful if there are other servers available to accept the requests that would otherwise not be handled. By default, flow control is enabled, but the high and low water marks are both set to zero, which has the same effect as disabling it.
Q Is it possible to run servlets and JSPs on a different server to EJBs?
A There are two motivations for doing this. First, it can be argued that servlet and EJB loads scale differently when the user base increases. Some users wish to be able to scale the resources for handling these components differently. Second, EJBs are likely to be more tightly-coupled to a database than is the case for servlets. It can be argued that they have different security requirements.
      Whatever the motivation, it is possible, in principle, to deploy EJBs on one iAS server and servlets/JSPs on another. However, this is not a mode of operation that iAS was designed to support, and setting it up is likely to be fiddly. I would recommend treating this as an `application partitioning' exercise; install all components on all servers, and then selectively disable components on the server on which they should not be executed.

Clustering
Q Do I need to set up a cluster to get load balancing ?
A In principle, no. In iAS terms, a `cluster' is a group of servers that maintain synchronized application sessions (`DSync'). This has nothing to do with load balancing. iAS will load-balance across a group of servers that are not cluster members. However, clustering and load balancing do seem intended to go together, and some forms of load balancing appear to work better in a cluster.
Q What is an `abnormal' cluster?
A According to the iAS documentation, an abnormal cluster is one with more than one primary, or no primary. A multiple-primary state can arise when a primary becomes disconnected from the network (e.g., cable failure), a secondary is promoted to be primary, and then the old primary is reconnected. A no-primary state exists whenever a primary fails, and no secondary is available to be promoted. This will be the case momentarily whenever a primary fails, but the admin process will promote a secondary to resolve it. It is not documented how long a cluster must be without a primary before it is considered to be abnormal.
Q What are `sync primaries', `sync backups', and `sync alternates' ?
A In a clustered environment, the primary is the server that holds authoritative session data for all application components that are marked for distributed sessions. Any such component will retrieve its data from the primary, and not from its own memory. If session data on a primary changes, the changes are reflected on the backups. This means that any backup can immediately become a primary if the primary fails; but no session data is obtained from backups in normal circumstances. If a primary does fail, then a new primary is selected from the backups according to the server priority list, as described below.
      An `alternate' holds no session data for distributed sessions; it always gets its session data from the primary, and never replicates it. However, if a primary or a backup fails, then an alternate can be selected to be a new backup. If that happens, it will start replicating session data, in case it has to become a primary in the future.
      A `local' holds no session data for distributed sessions but, unlike an alternate, it can never be selected for another role. It will never, under any circumstances, find itself holding session data to which other server refer.
Q Why would I want to allocate a `sync local' rather than a `sync alternate' ?
A Allocating a server as a local can be useful if that server is likely to come in and out of service. This could happen in a large enterprise if computers are dynamically allocated to applications according to load. If a local is removed from the cluster, this will cause less stress to the system that the removal of a primary. And bear in mind that any machine in the cluster could be a primary at some point, unless it is a local.
Q How do servers get allocated to `primary', `backup', and `alternate' roles ?
A When a cluster starts up from the state where all servers are down, the roles are determined by startup-time, and not by the priority settings in the admin tool. The first server to come up will be the primary; subsequent servers will be backups until the set number of backups is reached. Anything else will be an alternate or a local. If the server is listed in the cluster priority list then it will be an alternate; otherwise it will be a local.
      If a primary fails, then the backup with the highest priority is promoted to become the new primary. This leaves a space for a new backup, which is filled by the highest priority alternate.

Q How many backups do I need ?
A It is important to understand that the backup servers in a cluster only differ from alternates in that they hold copies of the distributed session data. If you applications are not set up to use distributed sessions, then you don't need any backups; they won't do anything anyway. Even if you are using distributed sessions, a preponderance of backups could be counter-productive; although increasing the number of backups reduces the probability of a failure that causes a user session to be lost, it does not increase the performance of the system in any way. Backups are never used to supply session data: this data always comes from the primary. In fact, backups will reduce performance slightly because of the network traffic overhead that the synchronization imposes. Therefore, one or two backups should be adequate for most purposes.
Q Can clustering be enabled without editing the registry ?
A Unlike previous versions of the application server, iAS allows a cluster to be defined using the admin tool. All that's necessary is that the `Cluster name' field of all machines in the cluster be set to the same name. This should be done with the servers down.
Q Can clustering be disabled, or a machine removed from a cluster ?
A You may wish to remove a machine from a cluster, or re-organize a cluster. Doing this involves editing the iAS registry manually; it can't be done from the admin tool. Try to separate the machines in your cluster back to non-clustered operation. Here is an outline of the procedure to follow. Apart from the first step, all these steps should be carried out on each individual system.

Shut down all iAS servers in the cluster using the admin tool. Close any open admin tools.
Now shut down each server fully, using KIVAes.sh stop.
Start the registry editor (kregedit &).
Delete all values from the subkey Software/Application Server/6.0/CCS0/Cluster Name and insert a new (integer) value [hostname]-NoDsync=0. The `NoDsync' suffix is important.
Delete everything from the subkey Software/Application Server/Clusters
Create the subkey Software/Application Server/Clusters/[hostname]-NoDsync
Under this new subkey, add (integer) values: MaxBackups=0, MaxHops=1, MaxSyncHeartBeat=10, SyncHeartBeatInterval=30, SyncTimerInterval=60, and the subkey SyncServers,
Under the subkey Software/Application Server/Clusters/[hostname]-NoDsync/SyncServers create the (integer) value `[IP number]:10818=0'.
When all servers in the cluster have been set up this way, restart their iAS servers, and verify that they are not participating in a cluster (check the kxs kxs logs).

Q How do hex addresses like `0xc0127755' in the logs relate to real IP numbers ?
A These are the IP numbers as 32-bit hex numbers. Split the 8-digit number into four groups of two, and convert each to decimal to get the normal IP number. In the example `0xc0127755', this is C0.12.77.55 (hex), which is 192.18.119.85.
Q Why are my iAS logs showing load balancing messages from machines that are not in my cluster ?
A Load balancing is not handled using the same mechansim as clustering. In a cluster, each participating machine is identified in the registry of each other machine. The load balancing system, however, uses a multicasting scheme for identifying other servers. If you have have two or more iAS clusters that are accessible to one another by a multicast (e.g., on the same ethernet cable segment) then they must be configured to use different multicast addresses or ports. This is done by editing the key Software/iPlanet/Application Server/6.0/GMS/KES subkey using kregedit.
Q How can I find out what role each server is playing in a cluster ?
A Using the admin tool, use the `Dump cluster info' button in the Logging/DSync page. This writes a file called iasdsync-cluster-[port].log in the logs directory for each engine, where [port] is the IP port number for the engine.

Database
Q Why can't I change my database settings by running db_setup.sh ?
A This script makes irreversible changes to the scripts that start the iAS engines. Once it has been run once, it can't be run again. It will appear to work, but nothing will happen. This problem can be prevented by making a backup of the ias/bin directory before running db_setup.sh. Otherwise you will have to re-install iAS, or manually edit all the scripts in the ias/bin directory that contain database settings.
Q What SQL version does iAS support ?
A With the exception of container-managed persistence, iAS does not generate or use SQL; in that sense it could be said that iAS does not support any SQL version. However, iAS can act as a proxy for database access for all applications that it supports; this means that it has to be able to support all the operations required by the JDBC 2.0 specification. Any application that excepts to find JDBC compliance at that level will be supported by iAS. JDBC 2.0 is largely based on the SQL-2 language, so it is reasonable to say that iAS supports SQL-2.
      However, iAS will generally support vendor-specific enhancements to SQL-2 if they return results that are standard data types supported by JDBC 2.0.
Q How does iAS mediate between applications and databases ?
A When an application needs a connection to a database, for the purpose of reading or writing data, it gets the connection from the iAS database engine, not directly from the database drivers. Doing this has certain benefits. Specifically, iAS operates a connection pooling scheme, which improves performance and reduces the number of simultaneous connections that the database is required to support. In theory, applications can get connections directly from database drivers, but this is not recommended as it obviates these benefits. When an application has obtained a database connection, it can use it exactly as it would a connection obtained from a driver; the role of iAS is transparent to the application.
Q What are `connection pooling', `connection sharing', and `connection stealing'?
A Opening and closing database connections can be time-consuming. In addition, licensing considerations may limit the number of concurrent connections that can be made to a particular database. When an application requests a database connection, iAS creates the connection and informs the application. When the application closes the connection, iAS detaches the connection from the application, but keeps the connection open. This makes it available to support the next request from an application. This mechanism is transparent to applications, but improves database performance because connections do not have to be made and broken.
      In reality, the situation is not quite as simple as this.
      When the application asks for a database connection, it gets a `virtual connection' from the iAS database manager. There is no limit to the number of these virtual connections that can be obtained. It is the job of the database manager to map virtual connections onto real connections, where the number of real connections is limited.
      When a new connection is made by the application, it is considered to be idle. That is, it has an association to the database (a virtual connection), but no transaction is in progress. A connection in this state can be mapped onto a real connection to the database, but need not be. If the connection begins a database operation, then the database manager must either map it to a real connection, or queue the request. If the connection has the same user credentials as an existing connection, then it can share the real connection with other virtual connections that have the same credentials. This is called connection sharing. If it has different credentials, then the database manager will either allocate a new connection to it (if available), or steal an idle connection from a different virtual connection (if available) or queue the request.
      So at any given time, the database connection cache contains three kinds of entry:

Unallocated: these entries represent connection slots that are available for use, and are currently not associated with any database connection. To use one of these connections means establishing a new connection with the database.
Idle: idle (free) connections are associated with a database, but are currently not in use, perhaps because they have been closed by the application that opened them. These connections can be reused very quickly, provided that the new user has the same security credentials as the previous one.
Active: these connections represent ongoing access to the database.

The total number of these three kinds of connection will be the value of `Maximum Connections' set by the admin tool.
      Let's see how this works by considering a trivial case. Suppose we start five applications, each of which requires one database connection. The maximum number of connections is four, of which two slots are allowed to be allocated to idle connections. To make it simple, let's assume that all five applications want connections with different user IDs (this means that we can't use connection sharing).
      When the five applications have started, the situations is as follows:
App1 ------> VC1 ------> C1 [idle] App2 ------> VC2 ------> C2 [idle] App3 ------> VC3 App4 ------> VC4 App5 ------> VC5 C3 [unallocated] C4 [unallocated]
The five applications are each assigned a virtual connection (VC1..VC5), but only the first two are mapped to real database connections (C1 and C2). C3 and C4 remain unallocated. Now App1 begins a database operation. So its connection is now active.
App1 ------> VC1 ------> C1 [active] App2 ------> VC2 ------> C2 [idle] App3 ------> VC3 App4 ------> VC4 App5 ------> VC5 C3 [unallocated] C4 [unallocated]
Now App3 and App4 begin database transactions (App1 is still busy). There are two unallocated slot, C3 and C4, which can be allocated, and made active. So now we have
App1 ------> VC1 ------> C1 [active] App2 ------> VC2 ------> C2 [idle] App3 ------> VC3 ------> C3 [active] App4 ------> VC4 ------> C4 [active] App5 ------> VC5
Now suppose App3 and App4 have finished, and their connections become idle,
App1 ------> VC1 ------> C1 [active] App2 ------> VC2 ------> C2 [idle] App3 ------> VC3 ------> C3 [idle] App4 ------> VC4 ------> C4 [idle] App5 ------> VC5
We now have three idle connections in the cache, which is greater than the two allowed. However, to avoid unnecessary re-opening of connections, iAS won't deallocate these connections until a configurable time interval has elapsed (typically two minutes). Before this happens, App5 requests a connection (App1 is still busy). Now there are no unallocated slots, so the database manager has to steal one from an idle connection. It can't steal C1 because that's busy, so let's suppose it steals C2 from App2. Now we have:
App1 ------> VC1 ------> C1 [active] App2 ------> VC2 App3 ------> VC3 ------> C3 [idle] App4 ------> VC4 ------> C4 [idle] App5 ------> VC5 ------> C2 [active]
You should be able to see that using the mechanisms of connection pooling and connection stealing, iAS is able to limit the number of real database connections, while maintaining an unlimited number of `virtual' connections for applications.
      Suppose, finally, that another application (call it App6) startup and and requests a connection. We have two active and two idle connections; we can't do anything with the active connections, but C3 and C4 are candidates for stealing or sharing. Whether we steal or share depends on the security attributes of the new connection. If App6 requests a connection with the same security attributes as C3, then it can share an idle connection with C3, like this:
App1 ------> VC1 ------> C1 [active] App2 ------> VC2 App3 ------> VC3 ------> C3 [idle] App6 ------> VC6 ------> " App4 ------> VC4 ------> C4 [idle] App5 ------> VC5 ------> C2 [active]
Otherwise it will have to steal C3 from App3.
Q What is `SQL parsing' and why should it be enabled in iAS ?
A SQL parsing is the process of checking the grammatical correctness of SQL statements. iAS can do this, if it is enabled (using the admin tool), on SQL statements before they are passed to the JDBC drivers. If the check fails, iAS logs an error in the kjs log. The iAS SQL parser complies with SQL-2, and does not recognize any vendor-specific extensions to the SQL language. This feature can be useful during development to ensure that the application will be portable, as all modern vendors have full support for SQL-2.
Q Can I use other databases with iAS if I have JDBC drivers ?
A Yes and no. In principle you can make JDBC calls from your EJBs and Servlets, so any database with a JDBC driver is accessible (you may have to alter the iAS CLASSPATH to get it to find the driver at run-time). In addition, many drivers will support connection pooling and transactions internally; these features are not limited to iAS. However, you won't be able to get a reference to your datasource through JNDI (you'll need hard-coded driver references), and you won't be able to configure it through the admin tool. In addition, you won't be able to use it in container-managed persistence or container-managed transactions. You may be able to use distributed transactions, but you'll have to do a lot of extra coding.
Q Does iAS support global transactions ?
A Yes, provided your databases do, and you have configured resource managers appropriately. iAS uses the Encina transaction manager.
Q What is a resource manager ?
A A resource manager is a piece of software that mediates between the transaction manager and a specific database engine. Its job, essentially, is to translate transaction control information in XA protocol into a form understandable by the specific database.

Security
Q What is the `j2ee security model' ?
A j2ee security is based on the notion of an `authenticated session'. When the client (e.g., Web browser) makes contact with the application server, the user is given the opportunity to log in. If login is successful, the client remains associated with his login credentials for the rest of the session. The user's identity is known as the principal, and that principle can be associated with one or more roles. This session is called an `authenticated session'.
      The login process is typically controlled by the application server; it will provide, for example, a servlet which accepts the user credentials (typically and ID and password), and stores the principal in the session. The developer does not have to write this servlet, but has to know how to get access to it.
      Security is implemented jointly by the developer and the administrator. The developer identifies security roles required in the application (`view', `edit', `manage',...) and writes the code so that only principals in the correct roles can carry out certain actions. The developer can also assign roles to the methods of EJBs. This is called `declarative security' as it involves no coding at all.
      The administrator maps the names of the roles assigned by the developer onto the names of real users, groups, customers, etc., according to the organization's needs and using the application server's provided tools. The administrator and/or the application deployer can modify the declarative security attributes, if required, although care has to be taken to avoid breaking the programmatic security when doing this.
Q How does iAS support the j2ee security model ?
A iAS uses LDAP to manage users and groups, and provides a scheme for mapping the developer's role names onto LDAP groups. When a user attempts to use an application, the user's credentials are checked against the LDAP server and, if acceptable, his principal is stored in the session. This process is carried out by the FormAuthServlet servlet, which is provided with iAS. This servlet accepts data from a login form provided by the developer and, if login is successful, dispatches to an application component nominated by the developer. At this point the session will have the user's security context.
      The mapping of roles onto groups can be carried out using the deployment tool or, after deployment, with the admin tool.
Q How do I allow a new user to get access to an iAS application (for an application I did not write) ?
A Ideally, the application developer will have provided a mechanism to do this, through the application itself. For example, in the `Bank' sample application that comes with iAS, there is the facility to add new customers. In practice, what this facility does is to add an entry to the LDAP directory in the `People' section and a corresponding one in the SQL database table.
      If the application adheres strictly to the j2ee security model, and has no other authentication mechanism, then you can manage user permissions using an LDAP browser (e.g., Netscape Console). The application will have been written so that all its authentication is done through roles. Using the admin tool you can map role names (which appear in the deployment descriptor) onto LDAP group names. Then using the LDAP browser you can add new users and assign them to the appropriate groups.
      If the application was not developed according to the j2ee security model, then there is no standard procedure for managing access. It will be at the whim of the developer.
Q What is an `access control list' ?
A Access control lists (ACL) are a form of security specific to iAS and used prior to the j2ee security model. An application that understands ACLs can query the ACL database to determine whether a specific user action is allowed. However, more modern applications will used forms-based login with the j2ee security model.
Q How secure are session IDs ?
A A number of iAS users have expressed concern that a non-authenticated user could duplicate the session ID of a customer that has already been authenticated, and get access to restricted services by posing as the authenticated user. While there is a theoretical risk of this, it is unlikely to happen in practice. The session ID is a 64-bit one-way hash made from, among other things, a random number. The likelihood of being able to synthesize a session ID that generates the correct hash value for a session that is currently in progress is exceptionally small. However, there is a small risk that an eavesdropper could obtain the values of currently-active session IDs by network snooping. Sensible use of firewalls will reduce this risk, and encryption of the Web connector protocol will reduce it further. See below for discussion.
Q Is the communication between the Web server and the iAS server encrypted ?
A By default, no. Encryption can be enabled by adding the following value to the configuration registry: Software/Application Server/6.0/CCS0/Security/EnableEncryption=1. The communication between the Web server and iAS is harder to protect using a firewall than the communication between iAS instances. Normally this communication will be through a firewall and therefore, by definition, visible on the more public side of the firewall. The communication will include, among other things, the session IDs of current user sessions. If the Web server itself is violated, it may be possible for the intruder to monitor communication between it and iAS, and thereby get access to session IDs. Encryption will reduce this risk to a negligible level, but it will introduce a small performance penalty.
Q Can the iAS servers and their Web servers be separated by a firewall ?
A Yes, and they probably should be. You would probably not want to put a publicly-accessible Web server on the same part of a network as your corporate data sources. To configure the firewall you will need to know the IP port numbers and addresses of the various iAS processes and their servers. Specifically, you will need to allow the Web server to talk to each of the kxs process on their allocated ports (10818 by default). kjs and kcs ports will not need to be accessible through the firewall. Some thought will have to be given to the mechanism for reporting faults in the iAS processes: you may not be able to e-mail event reports across the firewall, for example. In addition, the issues of application installation and management need some attention. These both require access to the kas process on its IP port (default 10817).
Q What security issues should be considered in the use of thick clients ?
A By a `thick' client I mean anything that will bypass the servlet/JSP layer and talk directly to EJBs using RMI/IIOP protocols. The biggest problems arise when deploying thick clients on the Internet (e.g., Java applets accessible from your Web site). There are two main issues to consider.
      First, iAS does not support the encryption of IIOP data; this means that information sent from the thick client application to iAS, and vice versa, will be in plaintext, and accessible to anyone with the appropriate snooping tools. This does not necessarily mean that user IDs and passwords will be accessible, as these are not usually handled at the application level. It does mean, however, that application-level data could be snooped (names, addresses, bank balances, etc). I understand that support for SSL-encrypted IIOP is being considered for a future iAS release.
      Second, getting IIOP traffic across a firewall requires a more relaxed firewall configuration than HTTP. As well as the IIOP bridge port (9010), you will need to enable access to the range of ports that the iAS IIOP bridge will use for sending data to the client.

JSP and servlets
Q Does iAS cache JSP and servlet page results ?
A Yes, if they are registered. To be registered they need to have their own descriptors in the WAR file used for deployment. In iAS terms, a registered JSP is one that has a GUID in the registry; JSPs do not have to be registered.
Q How much data can be stored in a servlet or JSP session ?
A There is, in principle, no limitation. However, poor performance has been reported using distributed sessions where the session data size is more than about 4 kilobytes. Remember that this data must be passed between over the network several times for each access, and in a heavily-loaded system this could add significantly to network traffic.

EJB
Q How long can a stateful session bean remain inactive before it times out ?
A 4 hours by default, although this is configurable, both at the EJB level and the server level.
Q What is the `metadata cache' ?
A EJB metadata is information about the classes that comprise that bean's set; specifically it identifies the home and remote interfaces. Caching this information makes EJB access slightly quicker.
Q What is the `implementation cache' ?
A This is the number of free instances of an EJB's implementation that will be held in a pooled state, pending incoming requests. Not all EJB types are pooled, and even for those that are a large cache is only helpful if you anticipate many concurrent calls on the bean's methods.

Performance
Q How does performance scale when adding CPUs and servers ?
A Not surprisingly, the best cost/benefit ratio appears to come from upgrading a single-CPU iAS server to a pair of single-CPU servers. However, it is also cost-effective to increase the number of CPUs per server, certainly up to four, and perhaps up to eight. Acceptable performance benefits continue to accrue up until about 12 CPUs per server, but cost/benefit ratios are unlikely to be favourable for more than 12 CPUs. If you are using clustering, increasing from two servers to three gives significantly better results than increasing from three to four; little is achieved by having more than four servers in a group. This suggests that the largest single iAS cluster that should be contemplated is four servers with twelve CPUs each. This appears to be the case whether applications are using predominantly Web components or predominantly EJBs. If you are not using clustering, scaling beyond four servers can still be effectice.
      Bear in mind that clustering allows the use of distributed sessions. Session failover is not available in a non-clustered environment. This means that there is a trade-off between reliability and scalability. If you need failover and scalability, a better approach may be to use a number of smaller clusters.
Q What can I do if even 48 CPUs does not offer adequate performance ?
A A `brute force' approach to resource allocation is not always effective with iAS. You will obtain far better performance by using two load-sharing groups with 24 CPUs each, than one group with 48 CPUs. The problem with large installations is that as the installation increases in size, the communications overhead required in synchronizing all the servers, and the processes within a server, can absorb the additional processing resource added. This problem can be avoided if multiple `independent' groups of servers are used. In such a configuration, no attempt is made to synchronize servers between groups, or to share load between groups. For this to work, load must be shared before the iAS groups, as well as within each group. Specific load sharing products are available that will intelligently distribute load to a number of Web servers. Each of these Web servers can stand as the entry point to an iAS load-sharing group. Good results have been reported using groups of three iAS servers, each sharing a Web server, with a third-party load-balancing product feeding the Web servers.
Q How does `sticky' load balancing affect performance ?
A Sticky load balancing ensures that requests for a particular application component continue to be sent to the server that first serviced the request, within a particular session. It is important to understand that sticky load balancing works at the session level; it does not force the same server to handle all requests for that component, merely requests within a given session (otherwise we would not be doing load balancing at all). In some circumstances, load balancing can be less effective than we might expect. Specifically, if a server cannot handle an incoming request, it must re-route it to a server that can. This is a particular problem with stateful session EJBs in a non-clustered environment, because if a request for a stateful session EJB is sent to a server that does not have an instance of the EJB in its kjs process, the request must be redirected. Sticky load balancing prevents this problem by ensuring that the server that receives the request can always handle it immediately. However, enabling sticky load balancing will impair performance if the system is handling a small number of very active sessions, because it is more likely that load will build up on a single server while others are idle.
      In a clustered environment sticky load balancing has less benefit, because the use of distributed sessions means that it is likely that any component will be a able to handle an incoming request, regardless of the server that handled it first. This is because all session data is stored on the `sync primary', not on the server that is processing the request. This also means that, contrary to popular opinion, sticky load balancing does not itself prevent session failover (see below).
      Note that if session data is extensive, it may be impossible to enable distributed sessions because the communication overhead would be too severe. In such circumstances, you should weigh up the benefits of sticky load balancing. Some servlets must be sticky; in particular this applies to the servlets that do login authentication. Q Does the use of sticky load balancing prevent session failover ?
A No, because sticky load balancing only controls the server to which a request is delivered; it has no impact on the server from which session information is obtained. If the request is delivered to a machine that is not the `sync primary', then it must refer to the sync primary for its session data. This will be true with or without sticky load balancing.
Q At what point does Web server performance become a limitation, and what can be done about it ?
A In practice we have found that a single Web server can usually support three or more iAS servers. If your Web servers are handling a significant amount of non-iAS traffic (e.g., images, multimedia) as well, then they may become a performance bottleneck. This has been reported in a few installations. In this case, you could consider adding a second Web server to the cluster. If your installation uses load sharing within an application (that is, you have distributed sessions), then care must be taken to ensure that the Web servers are sharing load in a sensible way. You should check your Web server documentation to see how it handles load sharing within user sessions, or consider a specific Web server load balancing product.
Q Does binding a process to a CPU improve performance ?
A There are theoretical reasons why binding a process to a CPU may improve kjs performance on a multi-CPU system. Specifically, the thread management overhead is reduced, as there is no need to check sleeping threads on different CPUs when checking which thread to wake. This overhead was significant with versions of JDK prior to 1.2, but as iAS 6.0 uses JDK 1.2.2 it is less of an issue. Process binding is now unlikely to offer a substantial performance improvement, and on single-CPU systems may leads to a reduction in performance. You should consider using it on systems with four or more CPUs. Note that if kjs crashes and restarts, the CPU binding will probably be cancelled by the operating system. This means that if you have to rely on CPU binding to get adequate performance, you should consider the mechanisms you have in place to handle a kjs failure.