----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/63368/#review198409 -----------------------------------------------------------
3rdparty/libprocess/src/memory_profiler.cpp Lines 305 (patched) <https://reviews.apache.org/r/63368/#comment278541> This is a speculation, `result` should be informative enough. A likely reason is that `jeprof` is absent on the machine, in which case this line is confusing. 3rdparty/libprocess/src/memory_profiler.cpp Lines 312-322 (patched) <https://reviews.apache.org/r/63368/#comment278542> Ideally we would respond with a simply formatted data, e.g., JSON, if a request comes from `curl`/`httpie` and alike, and a "proper" html if it comes from a browser. Our help endpoints try to detect `curl` and `httpie` and respond accordingly. Another approach would be to introduce a parameter to the endpoints, e.g., `format=json` that allows to control the format of the response. 3rdparty/libprocess/src/memory_profiler.cpp Lines 675 (patched) <https://reviews.apache.org/r/63368/#comment278543> Can you please explain why you need default capture-by-reference here and below? 3rdparty/libprocess/src/memory_profiler.cpp Lines 689 (patched) <https://reviews.apache.org/r/63368/#comment278539> s\in"\in " 3rdparty/libprocess/src/memory_profiler.cpp Lines 689-692 (patched) <https://reviews.apache.org/r/63368/#comment278540> Technically, you do not redirect to the result, but you redirect to the `stop` endpoint if the browser is used. `curl` users will have to request `stop` manually: ``` alex@gru1: ~$ http 192.99.40.208:5555/memory-profiler/start?duration=1mins HTTP/1.1 200 OK Content-Length: 175 Content-Type: text/html Date: Wed, 28 Feb 2018 21:32:42 GMT <html> <head><meta http-equiv="refresh" content="60;url=./stop" /></head> <body>Started new heap profiling run.<br/>You will be redirected to the result in60s.</body></html> ``` - Alexander Rukletsov On Feb. 21, 2018, 10:41 a.m., Benno Evers wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/63368/ > ----------------------------------------------------------- > > (Updated Feb. 21, 2018, 10:41 a.m.) > > > Review request for mesos, Alexander Rukletsov and Benjamin Mahler. > > > Repository: mesos > > > Description > ------- > > This class exposes profiling functionality of jemalloc memory allocator > when it is detected to be the memory allocator of the current process. > > In particular, it gives developers an easy method to collect and > access heap profiles which report which pieces of code were > responsible for allocating memory. > > > Diffs > ----- > > 3rdparty/libprocess/Makefile.am c895d3ac7b9cc5ffd6c8b57ff24def866eb0213d > 3rdparty/libprocess/include/process/memory_profiler.hpp PRE-CREATION > 3rdparty/libprocess/include/process/process.hpp > 8661706cb058efb26f5bfbcc84972f9930d3670f > 3rdparty/libprocess/src/CMakeLists.txt > 0ce7dac5deea94623530820d173ce3ffe5b42ea4 > 3rdparty/libprocess/src/memory_profiler.cpp PRE-CREATION > 3rdparty/libprocess/src/process.cpp > 42e7adf740b234ebf23d2dcb71440749c0ed87ec > > > Diff: https://reviews.apache.org/r/63368/diff/6/ > > > Testing > ------- > > > Thanks, > > Benno Evers > >
