A couple of questions, just in case anyone knows. While working on the SSL support for the .NET client, I've been running into some issues which I think are related to the failover support implementation. If anyone has any ideas about them, sure would appreciate it.
1- How are connection open and IO exceptions during the connection handshake supposed to be handled by the failover support? In particular, what path should they be traversing through the code and how do they get back to the client opening the connection? Here's the problem I'm seeing: For example, if the client can't validate the broker certificate, an IOException is raised when the client tries to do the first read/write to the broker (that's how the library works, unfortunately). This seems to be triggering the retry/failover support correctly, as it is clearly obvious the client is retrying the connection. Problem is, when running my tests standalone, X-number of connection attempts are done, and then the client hangs. No exception ever gets to the client. But, if I run the client under the debugger, it immediately ends correctly with an exception. This seems to me to point to a race condition somewhere in how those exceptions are handled by the failover threads and how they are handed down to the client, but I just don't understand the code enough yet to say for sure. Any pointers on where to look would be appreciated here. 2- The second issue I see here is how the FailoverHandler class works. Why exactly does it have its own host/Ports properties (get/setHost, get/setPort) instead of being handed down an IBrokerInfo object somewhere? >From what I see, this functionality is used by the public Failover method in the AMQProtocolListener class, that also takes host and port as arguments. However, it does not appear that the method is used anywhere. My issue here is that I'm following Kevin's lead of putting Ssl configuration options on the client as part of the broker info (which is kinda logical since that's where the UseSSL flag was in the first place). The problem is that sooner or later all of that SSL Configuration options are going to be needed whenever a connection is established, and so we'd need it here also. (this is important to later enable support for client-side certificates) Normally, I'd just go ahead and refactor this to deal with IBrokerInfo instances (which already contain the necessary info), except that a comment on the afore mentioned Failover() method reads "Failover for redirection." Which suggest to me this was put in there to support something at the protocol level. Can anyone confirm If there's some redirection facilities at the protocol level? I'd like to know if I can just refactor that bit, or if we can just downright get rid of that or what. Thanks Tomas Restrepo [EMAIL PROTECTED] http://www.winterdom.com/weblog/
