[GitHub] trafodion pull request #1685: [TRAFODION-3180] At times establishing a JDBC/...

2018-08-07 Thread asfgit 
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/...

2018-08-07 Thread arvind-narain 
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 ?


---

[GitHub] trafodion pull request #1685: [TRAFODION-3180] At times establishing a JDBC/...

2018-08-07 Thread selvaganesang 
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 
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_




---