implementation question/recommendation?

[Dave Barndt]

Hi,

I'm hoping someone can confirm or point me in the right direction on how best to implement the following.

Given:

1) Crossbar running on system A ("Crossbar A"). System A is an IoT-type device (Crossbar running here allows direct/local WAMP connections to the device).

2) Crossbar running on system B ("Crossbar B"). System B is a backend server (Crossbar running here allows networked WAMP connections to multiple IoT devices).

3) Python app running on system A ("App A"):

- Spawns a WAMP component to connect to Crossbar A (via AutobahnPython's ApplicationRunner).

- Spawns a WAMP component to connect to Crossbar B (via AutobahnPython's ApplicationRunner).

- Runs its own (non-WAMP) application processing loop to handle communication with the non-WAMP portion of system A. This (I think) is why "App A" cannot itself run as a WAMP component, because it must have its own non-WAMP processing loop.

4) "App A" passes queues to the two WAMP components it spawns, so that the WAMP components can register/handle RPCs from "Crossbar A" and "Crossbar B" and pass the requests via the queues to "App A", which translates them and passes them on to the rest of system A.

Problem:

1) If "App A" runs as a container in or as a guest worker of Crossbar A, when it spawns the WAMP component to connect to Crossbar A, the connection never completes. I've tried start_reactor=True and False on the ApplicationRunner.run() method, no difference.

2) If "App A" runs completely outside Crossbar A, it may try to connect to Crossbar A before Crossbar A is ready to accept connections.

I think the soon-coming Crossbar reconnect/retry feature may be the solution allowing 2) to work, but I can't help but wonder if I'm perhaps missing something obvious, or perhaps there is another easier way to do what I want?

Thanks for any light,

Dave B.

[Dave Barndt]

Hi,

OK, it looks like the problem is not related to the implementation, but to a change in the setup of SSL/TLS in the most recent version (0.10.5) of AutobahnPython, in its autobahn.wamp.ApplicationRunner client helper. I've opened a question in the Autobahn group about this.

Meanwhile, if we remove SSL/TLS, then when we run "App A" as a guest worker of Crossbar A, when it spawns the WAMP component to connect to Crossbar A, the connection DOES complete. That seems to be exactly what we need - ensuring we wait until Crossbar A is running before trying to connect to it.

Can someone confirm that this is indeed true? Does Crossbar wait until the router is initialized before it starts other containers and/or guest workers?

Hopefully someone else finds this exercise helpful in their work.

Thanks,

Dave

[Tobias Oberstein]

Am 31.08.2015 um 20:07 schrieb Dave Barndt:
> Hi,
>
> OK, it looks like the problem is not related to the implementation, but
> to a change in the setup of SSL/TLS in the most recent version (0.10.5)
> of AutobahnPython, in its autobahn.wamp.ApplicationRunner client helper.
> I've opened a question in the Autobahn group about this.
>
> Meanwhile, if we remove SSL/TLS, then when we run "App A" as a guest
> worker of Crossbar A, when it spawns the WAMP component to connect to
> Crossbar A, the connection DOES complete. That seems to be exactly what
> we need - ensuring we wait until Crossbar A is running before trying to
> connect to it.
>

> Can someone confirm that this is indeed true? _Does Crossbar wait until

> the router is initialized before it starts other containers and/or guest

> workers?_

With Crossbar.io running in standalone mode (the only one avail. today),
it works like this:

1. the node configuration is read once during startup
2. the controller process starts
3. each worker from the workers list is started one after the other, in
strict order
4. starting a worker means: starting everything inside, eg all
transports of a router

Whether a worker is a router, container or guest does not matter as far
as order is concerned.

So given a worker list [R1, C1] with a Router1 and Container1, C1 won't
be even started before R1 hasn't started with all listening transports!
So a component in C1 can assume that R1 is started already.

> --
> You received this message because you are subscribed to the Google
> Groups "Crossbar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crossbario+...@googlegroups.com
> <mailto:crossbario+...@googlegroups.com>.
> To post to this group, send email to cross...@googlegroups.com
> <mailto:cross...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crossbario/8efc66cc-ab17-415b-876b-19d2a2b00fd9%40googlegroups.com
> <https://groups.google.com/d/msgid/crossbario/8efc66cc-ab17-415b-876b-19d2a2b00fd9%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Dave Barndt]

Hi Tobias,

Terrific! And thank you for the reply.

Grateful as always,

Dave