Opened 10 years ago

Closed 10 years ago

#58 closed defect (fixed)

REVIEW: getting an answer sent with group_reply() when there are other message in the queue

Reported by: jelte Owned by: jelte
Priority: medium Milestone:
Component: Unclassified Version:
Keywords: msgq group_reply group_recv Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: Add Hours to Ticket:
Total Hours: Internal?:

Description

Jeremy has seen a problem;

After an update I went from two "unexpected answer" to only one:

Error: unexpected answer from ConfigManager?

i don't see the problem on my machine, but what i think causes it is that there are multiple messages waiting in the queue, and during the handling of the first the module that handles it sends out another message somewhere, and it expects an answer back. But it doesn't get that answer, because it is added to the end of the queue (and so group_recv() returns the next 'normal' message that was in the queue)

Should we implement some kind of local queue in each module to do this or are we simply using the msgq interface badly here?

(perhaps we can do something with the message id, but in that case i think that should go into the cc/session.py/.cc)

Subtickets

Change History (6)

comment:1 Changed 10 years ago by jelte

  • Owner set to jelte
  • Status changed from new to accepted

The python case has already been handled; recv() and group_recv() now take an optional argument seq that has the sequence number of the message that is to be replied to (i.e. the return value of the original group_send_msg() to which another module responds with group_reply()).

If this argument is set, and any incoming messages do not have that value set in the 'reply' part of the envelope, they are queued in the Session object, and returned on the next call of recv() or group_recv().

It does need an addition though; currently you can get the socket to perform select() loops on, but that will not trigger if messages are on the queue but no new messages are coming in. The best solution i think is to add at least a 'hasQueued()' (or something similar) function that simply returns True if there is anything on the queue, so you can empty that before doing the select(). Perhaps we can also add a recvQueue() that only returns messages from the queue.

And both the queuing and hasQueued have to be implemented in the c++ interface as well.

comment:2 Changed 10 years ago by jelte

  • Owner changed from jelte to UnAssigned
  • Status changed from accepted to assigned

branches/trac58 handles this issue, branched in r1659

C++ code additions in r1660 and r1661

Extra cleanup and a fix for another related issue in r1663

This is also ready for review

comment:3 Changed 10 years ago by shane

  • Summary changed from getting an answer sent with group_reply() when there are other message in the queue to REVIEW: getting an answer sent with group_reply() when there are other message in the queue

comment:4 Changed 10 years ago by shane

  • Owner changed from UnAssigned to mgraff

comment:5 Changed 10 years ago by mgraff

  • Owner changed from mgraff to jelte
  • Status changed from assigned to reviewing

The code looks good to go.

comment:6 Changed 10 years ago by jelte

  • Resolution set to fixed
  • Status changed from reviewing to closed

Merged to trunk in r1870.

Note: See TracTickets for help on using tickets.