This FAQ tries to cover the basic doubts and questions that newcommers ask when first looking at ISS.
If you have not read the How it works section we strongly advise you to do so.
ISS is a process execution manager.
ISS serves as an utility that receives several processes for execution. It is configured with several performance parameters that tells it how to manage the multi-threaded execution of requests.
ISS takes care of deciding the best load to place on the server in order to get the best execution times for all requests it is delegated. ISS can decide to place a request on hold on a execution queue or to execute it immediately depending on the current load at the moment of process execution delegation.
These decisions that ISS makes are guided by the statistical information gathered by the performance monitor ISS incorporates witch enables ISS to know if it will be faster to execute the process immediately or if the server will start overloading and thus is best to queue the request n a FIFO execution queue.
When ISS receives a requests and is able to execute it immediately it returns the caller with the results of the executed process. This consists of a synchronous request execution. The caller placed a request and received the response after it has been executed. This s the normal expected behaviour.
On the other hand when a requests is placed on the execution queue due to heavy load at the moment of process delegation, ISS return the caller the information about he queued request and manages it's execution accordingly to the pending processes list. The caller thread is then free to decide how to act since the requests is not executed yet. It can inform the user of this situation, it can even decide to allow the user to interactively decide what to do, wait, or proceed. This is the result of an asyncrounous request execution. Since ISS detects that this particular request will not be executed immediately it releases the caller waiting for it and forks execution in his asynchronous mode.
This is one of the advantages of ISS. This allows for immediate response to the user even on heavy load on the server. ISS is even prepared to give estimated time of execution for processes on queue to assist caller applications to know how much longer they have to wait for the execution of their request (see JavaDoc).
You should check the How it works section for a more detailed explanations of how queueing requests may actually result on faster execution/response times.
For a quick answer let's just state that ISS tries to be the best of both worlds. As long as the server keeps responding within acceptale performance ISS behaves just like a normal multi-threaded execution of all requests as they are delegated. But if and when the turning point arrives when placing more processes in execution at the same time starts dropping performance bellow an acceptale performance minimum, either due to a decrease of the server processing capacity or by the shear load of to many processes in a given time slice, this is when all processes will be best server by not execution all requests at the same time, but rather execution a number of fixed processes at the same time while the others sequentially added to the executing processes in order to always keep the server at the best performance condition.
This is preciselly what ISS acomplishes and this is why at times it is best to queue requests rather than to execute them immediately.
You can see the following graph as an example of test case that simulates the overload of a server in order to test the ISS performance compared to the alternatives of process execution. Sequential and full multi-threaded execution of all processes.
The ISS's Intelligence comes from the performance monitor it incorporates. ISS is always monitoring the execution times of all managed processes. It has a set of performance parameters that instructs it what are the best performance values it should try to maintain and is constantly managing the amount of processes executing at the same time in order do keep the server at the best performant load possible. This is possible due to an internal queue of processes to serve ISS maintain. ISS has even the ability to predict how much time a process will take to execute because of the performance monitor and provided a method for this purpose.
ISS as a default configuration. But you can (and probably should) provide ISS with a custom performance parameters that help ISS to know what are the best execution times it should try to accomplish.
You can see how this is done be checking the User Guide section (see JavaDoc).
For a quick preview will list a few of these parameters here:
If by chance you do wish to do so, you can. You simply have to provide custom configuration parameters to ISS that set the maximum synchronous processes to zero!
This will force all requests to be placed on the queue and be managed sequentially by the ISS.
If we configure the Logger that we pass ISS to the Info Level or any other more verbose than this one, ISS will write to the log stream statistical data for every X processes executed.
You can.
ISS comes with an ISS Manager (see JavaDoc). This manager is who provides the ISS to the caller. It takes care of maintaining the instances of ISS in use.
One simply has to ask the ISS Manager for an ISS instance with a different identifier name (see JavaDoc).
Eatch identifier corresponds to a different ISS instance with a dedicated configuration and execution queue.
ISS returns a ServiceRequest object when ask to. It includes the process state. See the ServiceRequest JavaDoc for more info.
For more informations on how to use ISS and what it can help you with see the User Guide.