Ashwani Raina has posted comments on this change. ( 
http://gerrit.cloudera.org:8080/20535 )

Change subject: [CLI] Set rpc_max_message_size to accommodate huge response 
payloads
......................................................................


Patch Set 3:

(1 comment)

http://gerrit.cloudera.org:8080/#/c/20535/2/src/kudu/tools/tool_main.cc
File src/kudu/tools/tool_main.cc:

http://gerrit.cloudera.org:8080/#/c/20535/2/src/kudu/tools/tool_main.cc@264
PS2, Line 264:   int64_t max_memory_available = 
kudu::process_memory::MaxMemoryAvailable();
Note: I noticed from a couple of test failures 
(RaftConsensusITest.TestEarlyCommitDespiteMemoryPressure and 
ClientStressLowMemoryTest.TestMemoryThrottling) that if I use 
kudu::process_memory::HardLimit here, it fiddles with memory_limit_hard_bytes 
that is set to low values by above two tests to induce memory pressure. When 
HardLimit is called from here (to get the memory available), it overwrites the 
memory_limit_hard_bytes flag to a bigger value (i.e. the actual memory 
available) thereby causing the test to fail because memory pressure condition 
was not induced to arrive at the expected result.

Due to the time constraint, I was not able to RCA why HardLimit would overwrite 
the hard limit flag. HardLimit implementation does initialise g_hard_limit but 
it is not clear how that would impact the server's flag. IIUC, Kudu tool and 
server are separate binaries, so even if I hard limit gets overwritten upon 
calling HardLimit in Kudu CLI code, it should only impact its own copy of hard 
limit flag and not the one within the server. Maybe I am missing something here.

If this is not expected behaviour, I would like to open a separate jira to 
address this.

For now, to make it work, I have added a new method whose only job is to find 
out the memory available without initialising any limits.



--
To view, visit http://gerrit.cloudera.org:8080/20535
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Ic27b494bc1fde46c2a095c7291fc840a98429068
Gerrit-Change-Number: 20535
Gerrit-PatchSet: 3
Gerrit-Owner: Ashwani Raina <[email protected]>
Gerrit-Reviewer: Alexey Serbin <[email protected]>
Gerrit-Reviewer: Ashwani Raina <[email protected]>
Gerrit-Reviewer: Kudu Jenkins (120)
Gerrit-Comment-Date: Fri, 06 Oct 2023 10:39:56 +0000
Gerrit-HasComments: Yes

Reply via email to