On 06/17/2013 07:31 PM, Steve Huston wrote:
And anything you can think of for dynamically load balancing across
brokers?
Honestly, I think the simplest solution overall is for us to get federation
working on windows. I assume its some issue in the IO layer.
Does anyone have a concrete understanding of what the problem is and
what is required to fix it?
Any volunteers from our windows experts to take a look (Cliff, Chuck,
Andrew, Steve)?
https://issues.apache.org/jira/browse/QPID-2199
It is likely not a very complicated issue once it's understood more. Getting
the time/funding to do it has been the only impediment.
A view was expressed that this was because the AsynchConnector for
windows was not in fact asynchronous. I'm a little sceptical of that,
though I admit I haven't looked into the issue at all.
The underlying socket is reported to be established. As Ted suggests in
his comment, perhaps that the link registry has not been notified or was
unable to match the notification to the pending link.
The connection id and federation link matching was very fragile in
earlier versions (and seems now to be a little more robust). For example
https://issues.apache.org/jira/browse/QPID-4315, where SSL federation
broke if hostnames were used qith qpid-route.
Could a similar issue be (or have been) behind the windows problem?
Has anyone tried with a recent broker? E.g. 0.22 or trunk? There have
been quite a few changes in the codepaths involved.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
