There are no known bugs in the Object Communications System.Yeah! Right! There are some bugs and oddities that have crept in over time. They tend to stay in because they are difficult to fix, and I often end up working on the problem of the moment instead of the communications system!
I haven't experienced this myself when doing similar tests, but my simulator doesn't suffer the overhead of having Pardise running. My guess is that the system is spending lots of time in Paradise and Shore, and not enough CPU is available for the thread of TcpControl which accepts TCP connections!
One possible work-around is to increase the priority of the various threads that Object Comm starts to "above normal" priority, so they will be given a chance to run and process events. This is somewhat a case of priority inversion, because the idle thread will eventually run to schedule those threads when events become ready ... but the thread itself may not have the priority to run once scheduled!
Another possible workaround is to back-off and reetry connect()ing to another node for a period, incase something similar happens.
For now, Curt is delaying startup between groups of disk nodes, starting gangs of them less than the listen queue size, give-or-take!