Conversation
…viceTracker when CF is ready.
|
"Registration" of devices against CF is done by way of notifyDeviceExists function. That in turn calls baseNotify. That function calls checkLogin. CheckLogin checks if login to CF has occurred, and if not yet done, does so. baseNotify is not using the persistent connection between CF and provider. That connection is only used for requests from CF to the provider, not vice versa. Calls to CF are normal GET/POST over HTTP using a session token that is acquired via login. Perhaps your PR code is changing something in your scenario, but I am not seeing what that is. Were you seeing an error that you don't see any more with this patch? If so, could you please provide the error message so I can understand better what was going wrong and what the appropriate fix would be? |
|
Hi, first the logs of an stuck connection attempt: ios_remote_provider cf I also took a network trace, in which you can see that remote provider logs connects to ControlFloor with HTTP-POST to endpoint /provider/login. After the login the endpoint /provider/device/status/exists is not called. While debbuging I saw that Hope this explains the issue a bit better. If you need further information's or maybe the pcap, just give me a sign. |
|
Just a small point to add, the issue is only occurring in distributed system. In my traces the device registration worked, when the login to ControlFloor took about 120ms. When the network interface was in idle and the login took about 200ms the remote_provider got stuck in the described state. |
added var delayed to the ControlFloor class in order to notify the DeviceTracker when CF is ready.
If the ControlFloor server is a remote server it sometime occur that the connection to the server is established after the DeviceTracker tries to register the devices against CF.
In this case DeviceTracker stores the devices in pendingDevs and waits for the notifcation of controlfoor.go but this notification only happens if the server can't be reached at all.