qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lei.dai@airlink-software.com" <lei....@airlink-software.com>
Subject Re: Re: [Qpid C++ Broker] Why broker link state retains connecting when I setup Broker Federation in windows using qpid-route ?
Date Sun, 20 Nov 2016 08:50:11 GMT
After some tracing, I found that these points are probably related to the problem.

1.When use federation, one broker will connect to another, and once the connection is established,
broker will send an INIT message for negotiation.

2.In linux version, all the network operations, including connect, read and write, are asynchronous.
   So the INIT message is sent in the connected callback called by the network IO worker threads.
   But in windows version, connect is implemented synchronously, thus the INIT message is
not sent even if the connection is established,
   because no connected callback will be called.

3.When the connection is established, the link state should be set to Operational, but the
precondition is that
   when LinkRegistry::notifyConnection is called, the Link object must be in the pendingLinks
list.
   For the same reason as [2], in linux version it will be no problem because the Link object
is put into the pendingLinks by the connecting thread
   and LinkRegistry::notifyConnection will be called later by the network IO worker threads.
   But in windows version, because of the synchronous connect operation, LinkRegistry::notifyConnection
will be called by the connecting thread
   before the Link object  is put into pendingLinks. So the link state will not be set to
Operational.

Therefore, I tried to modify the source code, add a temporary thread to do the connection
and call AsynchIO::notifyPendingWrite
(which will call the idle callback to send the INIT message) after the synchoronous connect
operation succeeds.
Now the federation works on windows when use tcp, but when use ssl it still doesn't work.
It seems that ssl negotiation is more complex than tcp, and I have no time to read the source
code yet.

But my modification is only a temporary solution because I didn't add any asynchronous connecting
function to the IocpPoller, 
and if the correct modification is made, AsynchIO::notifyPendingWrite (or the idle callback)
should be called automatically, I think.

So, at the end, is there anyone who did test the federation functions on windows?
Or the federation is not designed to work on windows yet?
Or should I contact the developers' mailing list to ask this question? ;)

Regards,


Lei Dai
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message