You are viewing a plain text version of this content. The canonical link for it is here.
Posted to codereview@trafodion.apache.org by selvaganesang <gi...@git.apache.org> on 2018/08/07 18:10:06 UTC
[GitHub] trafodion pull request #1685: [TRAFODION-3180] At times establishing a JDBC/...
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 <se...@...>
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_
----
---
[GitHub] trafodion pull request #1685: [TRAFODION-3180] At times establishing a JDBC/...
Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:
https://github.com/apache/trafodion/pull/1685
---
[GitHub] trafodion pull request #1685: [TRAFODION-3180] At times establishing a JDBC/...
Posted by arvind-narain <gi...@git.apache.org>.
Github user arvind-narain commented on a diff in the pull request:
https://github.com/apache/trafodion/pull/1685#discussion_r208368992
--- Diff: core/sql/common/IpcGuardian.cpp ---
@@ -4135,13 +4131,9 @@ void IpcGuardianServer::useProcess(ComDiagsArea **diags,
short i = 0;
while (i < 3)
{
- short gprc = 0;
- procHandle = get_phandle_with_retry(tmpProcessName, &gprc);
- if (procHandle != NULL)
- rc = 0;
- else
- rc = gprc;
- if ((rc != 0) || (procHandle == NULL))
+ int gprc = 0;
+ gprc = get_phandle_with_retry(tmpProcessName, &procHandle);
+ if (rc != FEOK)
--- End diff --
Should rc be set first or use gprc ?
---