Header Ads

  • Breaking News

    Why a Service or PS-Query request runs twice though it is submitted only once from PIA?

    This is very common among PS-Queries due to improper configuration setup. Before we find an answer to this question, it would be better if we could understand how a PS-Query is processed and little bit on the various timeout values in PeopleSoft Application Server and Web Server? 


    Let us see how by first understanding the overview of PeopleSoft Pure Internet Architecture.
    1. The Web Browser sends requests to the Web Server using HTTP protocol.
    2. A Servlet installed on the Web Server facilitates all browser connections and relays the transaction requests and data to the Application Server by way of communication to Jolt which runs on the App Server. Servets are nothing but Java programs running on the Web Server. The environment in which the servlets run is called the Servlet Engine and Java executables are required for the engine to operate. A Java-enabled Web Server supports the browser transaction requests and the application messaging technology. A collection of Java servlets need to be installed on the web server, to handle the wide range of PeopleSoft transactions.
    3. Jolt is the communication layer between the web-based environment and the C++ environments. The Jolt Server Listener (JSL) routes the browser request to an available Jolt Server Handler (JSH) which passes the request onto the Application Server. 
    4. The Application Server further runs the appropriate SQL against the database.
    1) Application Server Timeout:
    All services performed by the Application Server for any 3-tier, PIA request is subject to certain timeout values. This time out is essential as the system needs to control how much time is spent on processing a request.

    Service Timeout value in psappsrv.cfg:
    This is one of the prime settings that affect the service execution. For each type of server (PSAPPSRV, PSQRYSRV, PSQCKSRV, etc), this value(Service Timeout Value) can be specified in the corresponding server’s section in psappsrv.cfg  in $PS_HOME/appserv/<domain>. The psappsrv.cfg contains 1 Service Timeout value per server. 
    This value represents the number of seconds Tuxedo waits for a service request, such as MgrGetObj or PprLoad, to complete before terminating it. If this is set to 0, the request can run endlessly however a request received through PIA may still be timed out due to the tuxedo_receive_timeout on the Web Server. If the Service Timeout value is greater than 0 seconds, the service request gets terminated after it is executed for the specified duration. The process servicing the request will be terminated by Tuxedo and a message will be logged in the Tuxedo log(tuxlog and also in Appsrv.log). If the domain setting ‘Restartable’ is set to Y in psappsrv.cfg, Tuxedo automatically starts another instance of the same server process to replace the killed one. This could result to serious complications depending on the web server timeout setting and could run multiple instances of same query in database. This setting affects the service requests from both PIA and 3-tier.
    Sample  psappsrv.cfg file:
    [PSAPPSRV]
    ; Settings for PSAPPSRV
    ; UBBGEN settings
    Min Instances=3
    Max Instances=3
    Service Timeout=300


    After Changing the Service Timeout value it is required to reconfigure the domain and then to restart the Application Server processes via psadmin.


    2) Web Server Timeout:
    If an Application Server process dies because of any reason other than a server timeout or a database timeout, the servlet behavior should be analyzed. The same request may be resubmitted one more time by the app server depending on the value for Restartable in psappsrv.cfg file.

    tuxedo_receive_timeout in the Web Server’s pstools.properties file:
    tuxedo_receive_timeout represents the servlet timeout value. When a PIA request is submitted, the Web Server waits for the duration of the tuxedo_receive_timeout, and when this timeout is reached, it re-issues the request.  If the reissued(second) request still times out, an error is returned to the user.
    In general, the Web Server can attempt a maximum TWICE to run a PIA request. The Web Server re-attempts to process the request, not only in case of the request exceeding the tuxedo_receive_limit however, it also reissues the request for the second and final time for any requests failing due to server exceptions. The default value for tuxedo_receive_timeout is 600 seconds.
    Note: 
    This affects only PIA requests.

    Sample pstools.properties file:
    # Tuxedo parameter settings
    # default is disconnect=0, send=10, receive=120
    tuxedo_network_disconnect_timeout=0
    tuxedo_send_timeout=50
    tuxedo_receive_timeout=600


    3) Database Timeout:
    In sqlnet.ora file or Oracle database server, there is a parameter as SQLNET.EXPIRE_TIME which accepts values in minutes. Oracle's recommended value is 10. When the query execution reaches this expiry time, the database system will ping the client(in this case a program servicing a Tuxedo service request), and when this timeout hits, if the connection is down, the transaction will be stopped and rolled back.  So, if the client is busy, nothing will happen and query will continue to execute, if the client is not busy, the transaction will be cleaned up. This setting will not work when using local connection(BEQ). If a BEQ connection is used in the application server - psappsrv.cfg file UseLocalOracleDB will be 1. Using TCP and IPC connections for this setting will take affect of this setting.


    So now, Why a Service or PS-Query request runs twice though it is submitted only once from PIA?
    If the tuxedo_receive_timeout is set to a value less than the server’s Service Timeout,  the web-server servlet, which submits the user request to the application server domain via Jolt, receives a Jolt exception and the Web Server will reissue the request, although the original request may still be running in the database. In simple words,the first query submitted continues to run on the database, even when it is not running on the application server side. In these cases, the Tuxedo terminates the PeopleSoft process however the query could still be executing on the Database Server though it is killed on PeopleSoft side. Since the request gets submitted for the second time, the database server will receive the same query again for execution, process it  and it might fail again.

    Solution:
    This should be prevented by correctly configuring the timeouts. This is also one of the reasons why a query service could run twice though it was submitted only once. It is preferable to have the tuxedo_ receive_timeout value more than or at least equal to the service timeout value for Application Server processes. This avoids the query re-submission by web server when the app server has killed it. While this will only take care of preventing future requests from being submitted again there is no way from PeopleSoft side to kill the query in database once it is killed by Tuxedo. However, Oracle provides workaround to find out if the parent process exists or not, if the parent process is dead it terminates the child process also.

    No comments

    Please refrain for marketing messages and unnecessary back links.

    Post Top Ad

    Post Bottom Ad

    ad728