<div dir="ltr">Hi!<div><br></div><div>It kind of sounds similar to the idea behind gproc, which is a widely used library,<br>so as everyone has said already - this is perfectly fine.</div><div><br></div><div><a href="https://github.com/uwiger/gproc">https://github.com/uwiger/gproc</a><br></div><div><br></div><div><h3 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;font-size:1.25em;line-height:1.25;color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol"">Use case: System inspection</h3><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol";font-size:16px">Gproc was designed to work as a central index for "process metadata", i.e. properties that describe the role and characteristics of each process. Having a single registry that is flexible enough to hold important types of property makes it easier to (a) find processes of a certain type, and (b) query and browse key data in a running system.</p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 18, 2017 at 11:33 AM, Mikael Pettersson <span dir="ltr"><<a href="mailto:mikpelinux@gmail.com" target="_blank">mikpelinux@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Jay Doane writes:<br>
 > Our team is currently using the process dictionary to store meta<br>
 > information for long running processes, and would like to hear from folks<br>
 > familiar with beam internals whether this is a recommended practice.<br>
 ><br>
 > Essentially we add meta information about the current request in a process<br>
 > dictionary of every process related to handling of this request. This<br>
 > information could be:<br>
 > - current file<br>
 > - user name of initiator of the request<br>
 > - http query parameters<br>
 > - type of a process (indexer | compactor | http_handler)<br>
 ><br>
 > For example, when we detect performance problems, we run a function that<br>
 > returns the Pids of (say) top memory using processes. We use the meta info<br>
 > stored in process dictionaries to determine which documents are using<br>
 > excessive memory so we can take corrective action.<br>
 ><br>
 > In practice, we are unable to use normal OTP messaging because in many<br>
 > cases, the high memory using processes have also grown huge message queues,<br>
 > and so would be unresponsive to any additional messages.<br>
 ><br>
 > Given our existing constraints, is this a reasonable use of the process<br>
 > dictionary?<br>
<br>
</span>Yes, I think this is perfectly reasonable.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>