[
https://issues.apache.org/jira/browse/TRAFODION-3260?focusedWorklogId=192663&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-192663
]
ASF GitHub Bot logged work on TRAFODION-3260:
---------------------------------------------
Author: ASF GitHub Bot
Created on: 31/Jan/19 05:34
Start Date: 31/Jan/19 05:34
Worklog Time Spent: 10m
Work Description: selvaganesang commented on pull request #1786:
[TRAFODION-3260] SSMP may wait 3 seconds before handling requests
URL: https://github.com/apache/trafodion/pull/1786#discussion_r252539896
##########
File path: core/sql/bin/ex_ssmp_main.cpp
##########
@@ -246,8 +247,12 @@ void runServer(Int32 argc, char **argv)
}
}
*/
- // wait for system messages only until ssmp starts receiving msgs.
- cc->wait(300);
+ // Wait for messages, but we need ssmp to wake up periodically to
+ // perform garbage collection.
+ short mask = XWAIT(LREQ | LDONE, ssmpGlobals->getStatsMergeTimeout());
+ if (mask & LREQ) {
+ cc->wait(0);
Review comment:
This change looks good except that it is not encapsulated. XWAIT, LREQ and
LDONE concepts should have been part of the IPC infrastructure and not expected
to be used in the callers of IPC infrastructure. So, @narendragoyal and I
tried the following and it seems to achieve the same effect.
Add the following 2 lines in lieu of this code
if (cc->getConnection() == NULL)
cc->wait(ssmpGlobals->getStatsMergeTimeout());
And undo the change at ssmpGlobals::work().
Prior to Trafodion there used to be at least one opener to ssmp always.
Hence this issue was not observed earlier. It is good catch
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 192663)
Time Spent: 2h 40m (was: 2.5h)
> SSMP may wait 3 seconds before handling requests
> ------------------------------------------------
>
> Key: TRAFODION-3260
> URL: https://issues.apache.org/jira/browse/TRAFODION-3260
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
> Affects Versions: any
> Reporter: He Zhenxing
> Priority: Major
> Fix For: 2.4
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> SSMP may wait and stop responding for up to 3 seconds before handling
> requests. This problem was found while investigating LOB locking issue, which
> may take 3 seconds to acquire the lock.
> Here are the steps to reproduce the issue:
>
> {code:java}
> >> cqd traf_blob_as_varchar 'off';
> >> create table t1 (a blob);
> >> set statistics on;
> >> insert into t1 values (stringtolob('abc'));
> >> insert into t1 values (stringtolob('abc'));
> {code}
>
> We ignore the first insert, which may take long for loading metadata.
> starting from the second, sometimes the insert will take 3 or 6 seconds to
> finish. Normally, it should only take hundreds of milliseconds.
> The problem is because SSMP waiting for client requests from $RECEIVE and
> replies from SSCP separately, so there is a possibility that SSMP is waiting
> on $RECEIVE while there are replies from SSCP and thus it will have to wait
> until timeout (3 seconds) before the replies can be handled and then SSMP can
> reply the client. If both LOB lock and unlock suffered this, the insert will
> take more than 6 seconds to finish.
> This problem also affects other scenarios that need to interact with SSMP.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
