What causes the REQ socket to NOT recv replies from REP?

0
votes

I implemented the lazy pirate pattern for my client module, which works great for retrying the requests. But here's the problem.

  1. REQ Client sends message to REP server. [OK]
  2. REP server interprets the message. [OK]
  3. REP server executes some action, and prepares the response. [OK]
  4. REP server sends back the response. [OK]
  5. REQ Clients polls message but doesn't receive any until it timeout. [NOT OK]
  6. REQ Client restarts the socket, and retries to send the request again. [NOT OK]
  7. REP Server executes the action again. [THE PROBLEM]
  8. This time REQ Client successfully receives the response. [OK]

That's the problem, I'm executing the action twice which was intended to be only executed once. I think this is the best way I could explain it.

In certain occasions client can send simultaneously send request to server as I have a coroutine running on a thread, separated from the main thread both of which has functionality that sends request to server. Could this be the cause of it?

I also have multiple of these clients connected to the server, could this be the problem?

Thank you!

1
zeromqpyzmq

1 Answers

1
votes

Q1 : "Could this ... coroutine based co-existence ... be the cause of it?"

Yes, mostly if coroutines use the same instance of the REQ-archetype.

Q2 : "... could this ... multiple of these clients connected to the server ... be the problem?"

No, given each client operates on it's own instance of a REQ-archetype, connected towards the REP-(server)-side, there ought be no reason to imminent blocks ( for details, read more about the REQ/REP principal certainty to fall into an un-salvagable mutual dead-lock, where the only thing you cannot know is, when it will happen, but we all may be sure, it will happen )

If an atomic, singleton-alike unique executions are needed ( and if server implementation permits that ), one may log each REQ's task-{UUID}, to prevent double-shots onto the same task-target.

There is hardly to tell more, without the actual MCVE / MWE-representation of the problem ( the .poll-ing loop logic / timeout / remedy-strategies ).