implementation question/recommendation?

#1

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.

  1. “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.

0 Likes

#2

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

···

On Saturday, August 29, 2015 at 2:57:26 PM UTC-4, Dave Barndt wrote:

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).
  1. Crossbar running on system B (“Crossbar B”). System B is a backend server (Crossbar running here allows networked WAMP connections to multiple IoT devices).
  1. 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.
  1. “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.
  1. 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.

0 Likes

#3

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.

···

Am 31.08.2015 um 20:07 schrieb Dave Barndt:

Hopefully someone else finds this exercise helpful in their work.

Thanks,
Dave

On Saturday, August 29, 2015 at 2:57:26 PM UTC-4, Dave Barndt wrote:

    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.

--
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.

0 Likes

#4

Hi Tobias,

Terrific! And thank you for the reply.

Grateful as always,

Dave

···

On Monday, August 31, 2015 at 5:52:47 PM UTC-4, Tobias Oberstein wrote:

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.

Hopefully someone else finds this exercise helpful in their work.

Thanks,

Dave

0 Likes