NB: Haven't tried building or running since this clearup round.
…xpected. - commented out event_handler calls because of gen_event:call badarg. Probably becase event handler isn't started so there's no pid for it. - tested using sipsak with a file with a sip message example from the RFC.
rebar release starts and listens. simpleapp still untested. Added redundant supervisor to simpleapp to call sipserver:start automatically. Removed some makefile stuff. Removed ssl seed stuff - it's broken and ssl isn't needed. Removed extras supervisor startup - none of them look relevant. Hacked version printout since version mod was generated before. Removed some mnesia table init stuff. Doesn't look like any of the mnesia stuff will be needed.
rebarised appserver rebarise some apps Add rebar, move ssl.conf to a configs dir
Set TZ to CET in Makefile.in to allow running "make test" with UTC time zone. For example in a Debian/Ubuntu pbuilder chroot.
config.hrl was not in a directory search by erlc.
…eported by Krister Jarl.
When requesting sockets to the same destination multiple times in parallell, the single process actually trying to establish a new connection is asked to respond to all processes requesting the socket. Primarily (almost exclusively) for failing connections, there is a race condition where no new connection attempt is initiated, but the old process trying to connect has just exited. The race condition was supposed to be handled inside the transport layer, but the retry logic was broken so a retry was never actually made.
The last commit message shows my own confusion. The bug is not in the loop detection code, but in code preparing requests to be sent (sippipe and sipproxy). Another test case is always valuable though.
the loop detection code. The bug is supposed to be causing a valid spiraling request to be mistaken for a loop, but this test case is unable to make that happen.