<div dir="ltr">If you store some data that doesn't change much later — I see no problem here, perfectly fine example of PD use.<div>But on the other hand, if you store mutable data in PD — this is considered an antipattern and it makes your code have side effects which are hard to track. Also when your process dies, all data in PD will be lost, which is OK if data is set once, but not OK if the data was important.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-04-17 22:43 GMT+02:00 Jay Doane <span dir="ltr"><<a href="mailto:jay.s.doane@gmail.com" target="_blank">jay.s.doane@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Our team is currently using the process dictionary to store meta information for long running processes, and would like to hear from folks familiar with beam internals whether this is a recommended practice.</div><div><br></div><div>Essentially we add meta information about the current request in a process dictionary of every process related to handling of this request. This information could be:<br></div><div><div>- current file</div><div>- user name of initiator of the request</div><div>- http query parameters</div><div>- type of a process (indexer | compactor | http_handler)</div></div><div><br></div><div>For example, when we detect performance problems, we run a function that returns the Pids of (say) top memory using processes. We use the meta info stored in process dictionaries to determine which documents are using excessive memory so we can take corrective action.</div><div><br></div><div>In practice, we are unable to use normal OTP messaging because in many cases, the high memory using processes have also grown huge message queues, and so would be unresponsive to any additional messages.<br></div><div><br></div><div>Given our existing constraints, is this a reasonable use of the process dictionary?</div><div><br></div><div>Thanks,</div><div>Jay</div></div>
<br>______________________________<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>
<br></blockquote></div><br></div>