receiveFrame does not accept a timeout parameter about stompest

[nikipore]

Well, you shouldn't let concurrent consumers access the same socket in an uncontrolled fashion to begin with.

And no, exactly the two methods connect() and canRead() do the heavy lifting (i.e. socket communication) on the transport level. If you look under the hood, canRead() harvests what is on the socket, while receiveFrame() acts on the protocol level.

[arjunv]

I understand what you mean. But the fact that ActiveMQ supports multiple concurrent consumers is being used by me to run multiple instances of a script to distribute an action based on the data from the queue. The uncontrollable fashion is sadly something cannot be dealt with (its real time data that can come in waves of thousands and then die for long periods).
Adding some sort of timeout, so that the instances does not keep listening on such a rare case (queue popped by another consumer in between canRead and receiveFrame, which happened multiple times in my case), would have been really awesome.
Anyways thanks for this awesome project :)

[nikipore]

The support of multiple subscriptions is a property of the STOMP protocol, not just ActiveMQ. We're on the session level here (hierarchy: transport < protocol < session < client-specific concurrency scheme). You should use some concurrency primitive, say a threading.Lock() or threading.RLock() to govern access to the session.

Single-threaded event-driven concurrency models (Twisted, asyncio, Greenlets, ...) as opposed to parallel models (multiprocessing, threading) are the concurrency model of choice for your use case: many concurrent users of a single I/O resource. So, you'll be best off using the Twisted client stompest.async. Feel free to port it to the new name stompest.twisted (which should be pretty straightforward), or to asyncio (less straightforward).