<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello List.<br><br>We're seeing some funky stuff with our BOSH testing.  We haven't been able to fully track down the cause yet, but at some point, ejabberd (2.1.5) starts spewing tons and tons of debugging logs (~500MB in a few minutes) with mostly this:<br><br>=INFO REPORT==== 2010-11-02 09:45:23 ===<br>D(<0.550.0>:ejabberd_http_bind:918) : OutPacket: [{xmlstreamstart,<br>                                                  "stream:stream",<br>                                                  [{"xml:lang","en"},<br>                                                   {"xmlns","<a href="jabber:client">jabber:client</a>"},<br>                                                   {"xmlns:stream",<br>                                                    "<a href="http://etherx.jabber.org/streams">http://etherx.jabber.org/streams</a>"},<br>                                                   {"id","4224552436"},<br>                                                   {"from",<br>                                                    "<a href="http://ci-jabber.wopr.connectsolutions.com/">ci-jabber.wopr.connectsolutions.com</a>"}]}]<br><br><br>This is only for two or three users connected.  Eventually the server crashes with this reason:<br><br>Slogan: eheap_alloc: Cannot allocate 912262800 bytes of memory (of type "heap").  I analyzed the crash dump in the erlang crashdump_viewer and it looks like the error_logger process had it's mailbox filled up.  This makes sense since the disk on this machine is rather slow so it lagged in writing out the debug traces and the memory balloon burst.<div><br></div><div>What we suspect happens is that a client sends a bosh stream start request but doesn't wait for the reply and closes the socket.  Looking through the code, I see that in ejabberd_http_bind, prepare_statement/4 calls prepare_outpacket_response/4 which matches the second pattern of the function head:</div><div><br></div><div><div>%% Handle a new session along with its output payload</div><div>prepare_outpacket_response(#http_bind{id=Sid, wait=Wait, </div><div><span class="Apple-tab-span" style="white-space:pre">                         </span>      hold=Hold, to=To}=Sess,</div><div><span class="Apple-tab-span" style="white-space:pre">                 </span>   Rid, OutPacket, true) -></div></div><div><br></div><div>Here OutEls is set to [] as can be seen from the above log entry -- there's only one element in the list:</div><div><br></div><div><div>   case OutPacket of</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>[{xmlstreamstart, _, OutAttrs} | Els] -></div></div><div>...</div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>    OutEls =</div><div><span class="Apple-tab-span" style="white-space:pre">               </span>case Els of</div><div><span class="Apple-tab-span" style="white-space:pre">          </span>    [] -></div><div><span class="Apple-tab-span" style="white-space:pre">                       </span>[];</div></div><div><br></div><div>And eventually prepare_response/4 is called again and the whole cycle repeats:</div><div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre">    </span>    case OutEls of </div><div><span class="Apple-tab-span" style="white-space:pre">           </span>[] -></div><div><span class="Apple-tab-span" style="white-space:pre">             </span>    prepare_response(Sess, Rid, OutPacket, true);</div><div><br></div><div><br></div><div>I haven't been able to trace http_get/2 in prepare_response/4 yet, so I am just bringing this up on the list for someone who is more intimate with this code.</div><br>Would anyone here have any ideas on how to track this down further?<br><br>Thanks!</div></body></html>