Hi Steven, i cant say that the broadcaster probably would be diconnected before r1582. It never ran long enough without the "killing ghost connection" routine. Without this "keep alive stuff", red5 last just for a few hours and this broadcaster disconnect never happened. It used to freeze before. With "keep alive" routine the longest run took 22h (for this test). But because some stream connection remains (even when the clients where closed and the broadcaster should be able to publish again. Also the logs showed some stream ids) lead me to the assumption that the killing ghost routine (or the connection handling code) is at some point in time screwed. But it could be anything else! I dont know. The "keep alive" is dealing with connection killing. the broadcaster gets unpublish.success and Netconnection.close. I would say, could a killed broadcaster connection, killed by "keep alive", lead to a unpublish.success and Netconnection.close than this is probably a point to look into. Of course, it could be another code, but my knowledge is to smal to tell you definitely. btw in my last test when a bulk amount of clients connected ive received Exception in thread "FlowControlService" java.lang.OutOfMemoryError: Java heap space There was 150MB of physical memory available. -Adam-
_______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
