[Twisted-Python] Timing problem with PB Broker's connectionReady

[Jean-Paul Calderone]

On Wed, 14 Nov 2007 16:35:09 +0100, Alan Franzoni <alan.franzoni.xyz at gmail.com> wrote:
>Hello everybody,
>I'm running Twisted 2.5 on 32-bit Ubuntu Linux (tested with both Feisty and
>Gutsy) and python2.5. All packages are the distro's own ones.
>
>I'm experiencing a small problem with the broker's connectionReady method on
>the server side of the PB connection. It's not huge and doesn't cause
>problems in real-world applications, but it's making more difficult for me
>to write a proper unit test.
>
> According to the docs, connectionReady is called as soon as Banana
>negotiation is done. This is true on the client side; connectionReady gets
>called before the client can get the root object from the server.
>
>But this is not true on the server side; as you can see from the printout of
>the attached file, the client says it already has got the server's root
>object but the connectionready hasn't been called on the server yet.
>
>In order to be sure connectionReady has been called on the server side, I
>must trigger an additional callRemote.
>

It's not triggered by the callRemote - the callRemote just keeps the example
program running long enough so that the server side actually has a chance
to get to connectionReady.

This is because there's no network activity required in between the client's
connectionReady call and the Deferred returned by getRootObject firing.
Since the client gets connectionReady first, without the callRemote (or
something else to prevent the process from exiting right away), the server
never receives the dialect negotiation response, so it never calls
connectionReady - as far as it is concerned, the connection never *is*
ready.

>I suppose there's some sort of caching or lazy behaviour implied here. Did I
>do something wrong? How can I force connectionReady to be called on the
>server side *before* the client can actually fetch the root object's
>remotereference?

You can't, as PB is currently implemented.  I'm not sure you really need
this, though.  Can you describe the difficulty you've had writing unit
tests?

Jean-Paul