GitHub user selvaganesang opened a pull request:

    https://github.com/apache/trafodion/pull/1685

    [TRAFODION-3180] At times establishing a JDBC/ODBC connection takes o…

    …bservably long time
    
    Analysis revealed that the mxosrvr process in connecting state was 
attempting to open the
    ssmp process on the node for a non-unique query as part of establishing 
connection.
    The ssmp process has many ports in CLOSE_WAIT state. It looks like the 
client happens
    to hit on a port that is in CLOSE_WAIT state.  The port transitions to 
ESTABLISHED state
    after some time. Hence the connection was taking a longer time.
    
    The mxssmp process keeps the port in CLOSE_WAIT because the socket wasn't 
closed on the
    server side when client exits gracefully as well as abruptly. The seabed 
layer in
    Trafodion doesn't handle  more than one open to a process in a correct way. 
I have changed
    the IPC infrastructure in SQL to ensure that the ssmp process is opened 
only once
    in mxosrvr process.
    
    The API msg_get_phandle opens the process with the given name to obtain the 
handle. This API
    is now replaced with XFILENAME_TO_PROCESSHANDLE_
    
    Also added code to possibly fix the regression failure hive/TEST006

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/selvaganesang/trafodion close_wait

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/trafodion/pull/1685.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1685
    
----
commit 02b9a0eac55840325a869102c5bbf28aaa516a3a
Author: selvaganesang <selva.govindarajan@...>
Date:   2018-08-07T18:03:04Z

    [TRAFODION-3180] At times establishing a JDBC/ODBC connection takes 
observably long time
    
    Analysis revealed that the mxosrvr process in connecting state was 
attempting to open the
    ssmp process on the node for a non-unique query as part of establishing 
connection.
    The ssmp process has many ports in CLOSE_WAIT state. It looks like the 
client happens
    to hit on a port that is in CLOSE_WAIT state.  The port transitions to 
ESTABLISHED state
    after some time. Hence the connection was taking a longer time.
    
    The mxssmp process keeps the port in CLOSE_WAIT because the socket wasn't 
closed on the
    server side when client exits gracefully as well as abruptly. The seabed 
layer in
    Trafodion doesn't handle  more than one open to a process in a correct way. 
I have changed
    the IPC infrastructure in SQL to ensure that the ssmp process is opened 
only once
    in mxosrvr process.
    
    The API msg_get_phandle opens the process with the given name to obtain the 
handle. This API
    is now replaced with XFILENAME_TO_PROCESSHANDLE_

----


---

Reply via email to