Hi Michael, I'm away from my PC so I can't take a look in the code, but at face value I'd say that using pauses seems like a bad idea, users might have no control of how connections are started. I'n many organisations brokers and routers would be 'owned' by different parts of the organisation than the clients and would be expected to sort this out.
I think that an actual solution, rather than a client side workaround would be the better approach. Out of curiosity, this issue isn't caused by something simple like the socket listen backlog is it, the default for this is generally 10 and is a common cause of this sort of symptom. Cheers, Fraser Sent from my iPad On 16 Apr 2014, at 09:32, "michael goulish (JIRA)" <[email protected]> wrote: > michael goulish created DISPATCH-45: > --------------------------------------- > > Summary: starting clients too rapidly causes connection failures > Key: DISPATCH-45 > URL: https://issues.apache.org/jira/browse/DISPATCH-45 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node > Affects Versions: 0.2 > Reporter: michael goulish > > > I don't know if this should be a code change, or an extra warning issued by > the router, or just a Note To Users of some kind, but I'm putting it here so > as not to lose track of it. > > If I start too many clients too rapidly, all trying to connect to the same > router, some of them will fail. My clients are very simple, not attempting > any retries. > > When this shows up, it's looks like an error in the client, and users will > probably hunt around for the cause. It can be avoided by simply putting > occasional pauses in my client-launching script. Looks like some kind of > backlog problem. > > > > > -- > This message was sent by Atlassian JIRA > (v6.2#6252) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
