Opened 7 years ago

Closed 6 years ago

#2401 closed task (wontfix)

synchronous communication between DataSrcClientsMgr and DataSrcClientsBuilder

Reported by: jinmei Owned by:
Priority: medium Milestone: DNS Outstanding Tasks
Component: b10-auth Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 5 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

I think we need to provide a "synchronous mode" of command exchange
between the auth::DataSrcClientsMgr and auth::DataSrcClientsBuilder
classes.

Test and benchmark code will need this for deterministic behavior,
and I guess in some cases the main auth server will need it. For
example, in the very initial startup it may rather block than
prematurely returning REFUSED to all queries.

One possible approach is to introduce sequence numbers for commands
and another communication queue between the manager and builder. When
the manager wants a specific command to be done in the synchronous
mode, it sends it to the builder with a valid (non 0 or something)
sequence number. If a command has a valid sequence number, the
builder notifies the manager of its completion via the separate queue
with that number (and probably some result code).

Subtickets

Change History (3)

comment:1 Changed 7 years ago by vorner

Hello

Another approach that looks simpler to me is introducing a special „sync“ command.

There would be a boolean conditional variable (called synced). Before putting
the sync command into the queue, we would set it to false. Then queue the
command and wait on it to become true.

The only thing the sync command does is setting the variable to true.

So when the original thread wakes up, it can be sure everything up to the sync
command was executed.

P.S.: If it was haskell (and we could post functors to the queue), I'd propose
creating a new conditional variable every time and sending a lambda function to
set it to true. This works nicely even when more than one thread posts work
O:-).

comment:2 Changed 6 years ago by stephen

  • Milestone set to DNS Outstanding Tasks

comment:3 Changed 6 years ago by tomek

  • Resolution set to wontfix
  • Status changed from new to closed

DNS and BIND10 framework is outside of scope for Kea project.
The corresponding code has been removed from Kea git repository.
If you want to follow up on DNS or former BIND10 issues, see
http://bundy-dns.de project.

Closing ticket.

Note: See TracTickets for help on using tickets.