Opened 10 years ago

Closed 6 years ago

#287 closed enhancement (wontfix)

revisit cc::Session establish/disconnect mode

Reported by: jinmei Owned by: UnAssigned
Priority: medium Milestone: Remaining BIND10 tickets
Component: ~Inter-module communication(obsolete) Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

[background: a review comment in Trac #275:
http://bind10.isc.org/ticket/275#comment:7]

We may have to revist the C++ API of how to establish cc::Session:

  • we should clarify who is responsible for establishing the session, especially if the session object is passed to a different module
  • we may want to detect an attempot of doubly establishing a session
  • same for disconnect
  • same for other operations that require an established session: send/receive, etc. should we support automatic session establishment?

Another planned refacotring with a generalized ASIO link may affect the design decision on these.

A backlog item.

Subtickets

Change History (10)

comment:1 Changed 10 years ago by jinmei

  • Owner changed from UnAssigned to jinmei
  • Status changed from new to accepted

One more point:

  • the current interface can easily cause rerource leak: if the app forgets to disconnect the session and destroys the session object, the underlying connection will remain open.

This leads to the following questions: is there any reason to allow a
session object to be constructed without opening the session?
Also, is there any reason for allowing disconnecting and re-opening
the sessions dynamically? If the answer (other than we may want to
allow it) to these questions is no, we can and should simplify the
interface and implementation so that the session is open on
construction, and is disconnected on destruction. Even if the answer
to the second question is yes, this approach still makes sense unless
we want to allow delayed session establishment.

(now that the issue includes how to close the session, I'm going to change the ticket subject accordingly)

comment:2 Changed 10 years ago by jinmei

  • Summary changed from revisit cc::Session establish mode to revisit cc::Session establish/disconnect mode

comment:3 Changed 9 years ago by jinmei

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

comment:4 Changed 9 years ago by stephen

  • Milestone feature backlog item deleted

Milestone feature backlog item deleted

comment:5 follow-up: Changed 8 years ago by shane

  • Defect Severity set to N/A
  • Owner changed from UnAssigned to jinmei
  • Sub-Project set to Core

I don't recall any work changing the session API, so I think this is probably still a valid issue.

Jinmei, can you confirm this?

comment:6 in reply to: ↑ 5 Changed 8 years ago by jinmei

  • Milestone set to New Tasks

Replying to shane:

I don't recall any work changing the session API, so I think this is probably still a valid issue.

Jinmei, can you confirm this?

As far as I know it's still a valid issue, but it may be somewhat moot
now because we are considering replacing msgq (and I think this issue
is related to the backend bus interface).

comment:7 Changed 8 years ago by jinmei

  • Owner changed from jinmei to shane

comment:8 Changed 8 years ago by shane

  • Milestone New Tasks deleted
  • Owner changed from shane to UnAssigned

comment:9 Changed 6 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:10 Changed 6 years ago by tomek

  • Resolution set to wontfix
  • Status changed from assigned to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check http://bundy-dns.de.

Closing ticket.

Note: See TracTickets for help on using tickets.