Expected CONNECTED frame, but none received

Issue #5 open
created an issue


We are using your stompclient and CoilMQ, but we encountered this problem on windows, on linux sometimes we encounter it, but most of the time its OK, but on windows its the other way around.

we tried running coilmq and stompclient on same machine still we encountered same problem

We are using CoilMQ-0.4.3,CoilMQ-0.4.4,CoilMQ-0.5.0, stompclient-0.3.1, Python 2.6



Traceback (most recent call last): File "cxstompware.py", line 132, in <module> File "cxstompware.py", line 20, in init File "stompclient\duplex.pyc", line 202, in connect Exception: Expected CONNECTED frame, but none received. }}}

Anyways, we would like to thank you for this project, we are using it with our cafe management system.

we tried editing the following: "duplex.py" connect function starting line 199. instead of raising an exception, re-try connection.

this solves our issue/problem, I don't know if this is a good approach or solution, anyways just to give you an idea.



try: return self.connected_queue.get(timeout=self.queue_timeout) except Empty: #raise Exception("Expected CONNECTED frame, but none received.") self.connect(login, passcode, extra_headers) }}}

Comments (5)

  1. hozn repo owner
    • changed status to open

    Thanks for posting this. I've certainly seen this error at certain times during testing -- typically, though, it seems to be when I don't start my listening "loop" before attempting to connect. Do you have an small code block of your setup/connect code that you could share that reproduces the problem (on Windows)?

    I will admit that I have spent much less time with this on Windows than Linux, but I do have access to Windows and should be able to verify this & do whatever is needed to get it fixed (or better documented, etc.)

  2. hozn repo owner

    Specifically, I would note that you need to ensure that the listening loop is actually finished setting up before connecting from the client. My default approach would be to use an event for that. So, from the docs example:

    client = PublishSubscribeClient('', 61613)
    listener = threading.Thread(target=client.listen_forever)
    # For our example, we want to wait until the server is actually listening
    # Now it's safe to connect

    Not sure if that helps at all -- or if that's already what you're doing. They key point here is just that the waiting on the listening_event ensures that the listener loop is running before you attempt to connect from the client.

    It's possible that we're setting that event prematurely too in the listener code. In that case, I would expect the problem to be "fixed" by adding a time.sleep() after the start of listener & before the connect() call. That isn't the official solution, of course, but would point us in the right direction for a fix if that does turn out to fix things. (It does look like we set that event right away when that method is called, which is probably not quite correct.)

  3. Gilbert reporter


    Here's our connection code block, we already tried putting delay, sometimes its working, but most of the time its not. we even tried it running on different machine/terminal, some machine its working some not

    self.client = PublishSubscribeClient(qhost, qport, socket_timeout=timeout, queue_timeout=timeout)
    self.listener = threading.Thread(target=self.client.listen_forever)
    self.client.subscribe("/queue/middleware", self.frame_received)	
  4. Log in to comment