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_
----
---