<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 26, 2015 at 9:39 AM, Bryan <span dir="ltr"><<a href="mailto:bryan@go-factory.net" target="_blank">bryan@go-factory.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Everyone,<div><br></div><div>I was hoping to better understand an interesting condition I recently encountered, and was able to alleviate though I am not 100% clear why.</div><div><br></div><div>In our system, we have two types of main processes: for simplicity sake, lets just call them groups (A) and endpoints (B). Each of the processes are implemented as gen_servers.</div><div><br></div><div>Process A implements functionality and represents a group of endpoints. These endpoints are then each instantiated as a process B. Each endpoint can then be in multiple groups. If I have two groups, then I will have two A processes. If I have five endpoints, I will then have five B processes. In our example, endpoint process #3 is a member in groups one and two.</div><div><br></div><div>The system is very simple. If a change occurs in A, a message is then sent to each endpoint process B that is a member. In our example, group #1 process would send a message to five endpoint processes. If a change occurs in the endpoint process B, a message is sent to each group process A it is a member of. In our example, if this is endpoint #3, it sends a message to both group one and two.</div><div><br></div><div>Seems simple enough. My interesting condition that I ran into was where one of the messages from the group process A to the endpoint process B was a cast. All others for both gen_servers are calls. When A sent the cast message to B, B simply updates its state. For reasons that are not clear to me, this ultimately reaches a timeout state, where all the processes start timing out, even though there are no calling/casting cycles.</div><div><br></div><div>I know that calling cycles introduce a deadlock condition, but I trying to understand why a cast, which is suppose to return immediately and be handled asynchronously would produce a timeout?</div><div><br></div><div>When I move this message from a cast to a call, the system works perfectly.</div></div></blockquote><div><br></div><div>Just a guess, but I would check to make sure that the code for handle_cast in the recipient "B" process wasn't doing something to make it unresponsive, such that the next call to that process would timeout. Are you sure that there was no call as a result of that handle_cast?</div><div> </div></div></div></div>