BIND 10 #2804: Make sure the ModuleCCSession::groupRecvMsg in blocking mode works even when already started.
BIND 10 Development
do-not-reply at isc.org
Fri Feb 22 10:36:42 UTC 2013
#2804: Make sure the ModuleCCSession::groupRecvMsg in blocking mode works even
when already started.
-------------------------------------+-------------------------------------
Reporter: | Owner:
vorner | Status: new
Type: task | Milestone: New Tasks
Priority: | Keywords:
medium | Sensitive: 0
Component: | Sub-Project: Core
Inter-module communication | Estimated Difficulty: 0
CVSS Scoring: | Total Hours: 0
Defect Severity: N/A |
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
When the session is started, an asynchronous read of size 0 is scheduled,
to notify when some data come. After that, it checks for incoming command.
However, if groupRecvMsg is called after this, it also schedules an
asynchronous read (and starts waiting for the read to finish). The two
reads then get intermingled and confuse things, losing messages or
crashing. We need to solve this, because the session is unusable for
rpcCall (see #2768). Currently, auth keeps a second (plain) session, but
that is ugly and the plain session doesn't have the rpcCall.
I tried registering an asynchronous read (by groupRecvMsgAsync) and
waiting for it to finish in the blocking method, but it didn't work. I'd
propose another solution. Cancel the asynchronous read of size 0 at the
start of groupRecvMsg (if it was already started) and return it back after
the groupRecvMsg ends.
After that, the rpcCall should be usable by auth, so the attached patch
could be applied.
--
Ticket URL: <http://bind10.isc.org/ticket/2804>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list