So when using zmq with crossbar you have to pass the flag zmq.NOBLOCK in
the socket receive. Also there needs to be a yield sleep(#) somewhere in
the while loop or else it will not exit. I do not understand why there
needs to be a sleep, so i just put a small sleep period.
Now crossbar will end using crossbar stop.
Thanks again for helping me out!
On Friday, October 9, 2015 at 9:27:56 AM UTC-4, Samuel Coombs wrote:
Tobias, thank you for your response.
Running it as an admin does not stop that process. Yes it is
connected to a database but that connection is not always open. I
receive a json file using ZMQ. Once I receive a message, I send it
to a function which open a database connection and write the data,
then closes the connection.
The problem is with ZMQ, it sits there and waits for a message. Only
CTRL-C will kill that process, so I will have to fix that and will
let you know if I fix it.
If you would like to play around with this here is the code. I took
out the database stuff because right now that is not the problem,
from twisted.internet.deferimport inlineCallbacks
from twisted.loggerimport Logger
from autobahnimport wamp
from autobahn.twisted.utilimport sleep
from autobahn.twisted.wampimport ApplicationSession
import zmq, json
log = Logger()
def onJoin(self, details):
# setting up zmq to read from port 5555
ctx1 = zmq.Context()
OverViewSocket = ctx1.socket(zmq.PULL)
self.log.info <http://log.info>('Overview Ready')
msg = OverViewSocket.recv()
yield self.publish("com.example.Overview", msg)# publish to 'com.example.Overview'
yield self.log.info <http://log.info>(msg)
On Friday, October 9, 2015 at 2:57:30 AM UTC-4, Tobias Oberstein wrote:
as can be seen from the logs, Crossbar indeed tries to kill the
'TerminateProcess', 'Access is denied.'
Here is a theory of what happens: the third worker is different
from the others, because it holds a DB connection ("that write
to a database. "). Crossbar will first try to orderly shutdown
all the workers which succeeds for router and the first 2
containers, but doesn't for the third. (I don't use pyodbc, so I
don't know if there is an option to hook into that so it can be
shutdown properly). After a timeout, Crossbar will then try to
hard terminate the remaining worker.
Now, why the behavior is different between CTRL-C'ing Crossbar
versus `crossbar stop` is another question.
My guess on that would be: when CTRL-Cing, the killing is done
by the program you originally started (the Crossbar node
controller that forker the worker, and that you now CTRL-C).
But when you use `crossbar stop`, the killing is done by a
different program (the new "crossbar stop"). And that fails,
because killing arbitrary, different processes requires extended
Please try the following: run the "crossbar stop" command in a
CMD shell started with "admin privileges".
Am Donnerstag, 8. Oktober 2015 20:03:29 UTC+2 schrieb Samuel Coombs:
This is the latest error i just got. My company does not
have a linux machine so i can't try that out. Ill look in
the other thing you said to try!
Traceback (most recent call last):
line 1194, in run
line1203, in mainLoop self.runUntilCurrent()
line 847, in runUntilCurrent self.fireSystemEvent("shutdown")
line 640, in fireSystemEvent event.fireEvent()
--- <exception caught here> ---
line 411, in fireEvent result = callable(*args, **kwargs)
line 566, in _cleanup_worker
line 255, in signalProcess
pywintypes.error: (5, 'TerminateProcess', 'Access is denied.')
On Thursday, October 8, 2015 at 12:35:59 PM UTC-4, Alexander > Gödde wrote:
So it seems that this specific component handles
shutdown signals differently than the others.
1. Do you have `psutil` installed on your machine? This
should influence how shutdown is sent.
2. Could you try to run things on a Linux machine and
see if the same problem occurs there (to see whether
this is a Windows issue or some more general problem
with Crossbar.io shutdown mechanisms)?
Am Donnerstag, 8. Oktober 2015 17:56:12 UTC+2 schrieb > Samuel Coombs:
My OS is an windows 7, 64 bit machine. I am using
python for the backend.
Attached is the config file.
For the DB Write i am using pyodbc to a SQLExpress
And I moved all the order of the workers around and
it always fails on the same worker(the one that
writes to the database) .I have to go task manager
and end the python.exe file. Then it will allow me
to start crossbar again.
here is a snip of the error
9312]←[39m Container 'worker2': component
9312]←[39m Starting Container with ID 'worker3'...
1888]←[39m Fatal error in component: While firing
onJoin - Address in use
9312]←[39m Component 'component1' failed to start;
shutting down node.
1888]←[39m Closed connection to 'component1' with
And thanks for the response, I really appreciate it!
On Thursday, October 8, 2015 at 11:42:51 AM UTC-4, > Alexander Gödde wrote:
Just tried with hello:nodejs extended to three
workers on Ubuntu, and shutdown is clean.
A more complete list of information required to
replicate your problem:
1. What operating system are you using?
2. What language are you using the hello example
for? Do all guests use the same language/runtime?
3. What is your configuration file?
You could also experiment a bit with the workers
to give us a better idea for where the problem
lies, e.g.: Is it the third worker in the
config? (change the order or the workers) Is it
the worker itself? (run this as the only worker)
Am Donnerstag, 8. Oktober 2015 16:04:08 UTC+2 > schrieb Samuel Coombs:
Yeah I Can
2. Uses ZMQ to receive messages to forward
to a screen
3. Reads a Tag from a PLC
4. Using ZMQ to receive messages that write
to a database.
The fourth on never ends when using crossbar
stop, but ends when using ctrl-c. There
might be something I am doing wrong, I am
new to crossbar but it seems pretty straight
forward. I basically took the hello app that
is on the crossbar.io <http://crossbar.io>
website and modified that, I just changed
the port and classnames for the containers.
On Thursday, October 8, 2015 at 9:51:36 AM > UTC-4, Alexander Gödde wrote:
This behavior is not something that
we've encountered during our testing.
Could you post more information about
what precisely you are doing in the
worker and how things are configured?
With the current information we can't
really give you any feedback.
Am Donnerstag, 8. Oktober 2015 15:10:50 > UTC+2 schrieb Samuel Coombs:
I just started using crossbar.io
<http://crossbar.io> (python) and I
have a program that has 4 workers(3
containers and 1 router).
I have a problem when I stop
crossbar. When I use CTRL-C to stop
it, all the processes end and I am
able to start it again. When I use
the command 'crossbar stop' only 3
of the 4 processes end. When I try
to start crossbar again, 3 of the
workers will start, and when the 4th
one tries to start, it will fail and
I will get the error 'Address in Use.'
I was wondering if there is
something I am doing wrong or is
there a bug somewhere?
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
To post to this group, send email to cross...@googlegroups.com
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.