[ https://issues.apache.org/jira/browse/TS-4705?focusedWorklogId=27669&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-27669 ]
ASF GitHub Bot logged work on TS-4705: -------------------------------------- Author: ASF GitHub Bot Created on: 01/Sep/16 00:15 Start Date: 01/Sep/16 00:15 Worklog Time Spent: 10m Work Description: Github user jpeach commented on a diff in the pull request: https://github.com/apache/trafficserver/pull/753#discussion_r77096388 --- Diff: iocore/net/I_NetVConnection.h --- @@ -566,6 +573,21 @@ class NetVConnection : public VConnection is_transparent = state; } + /// Set the context and return context value + NetVConnectionContext_t + set_context(NetVConnectionContext_t context) + { + if (NET_VCONNECTION_UNSET == netvc_context) + netvc_context = context; + return netvc_context; + } + /// Get the context. + NetVConnectionContext_t + get_context() const + { --- End diff -- I know we don't have strong conventions, but I'd prefer to aim for ``context()`` and ``set_context()`` as the member functions. The former reads better than ``get_context()``. As noted above I'd like to try to eliminate ``set_context()``. Issue Time Tracking ------------------- Worklog Id: (was: 27669) Time Spent: 1h 20m (was: 1h 10m) > Proposal: NetVC Context > ----------------------- > > Key: TS-4705 > URL: https://issues.apache.org/jira/browse/TS-4705 > Project: Traffic Server > Issue Type: Improvement > Components: Core > Reporter: Oknet Xu > Assignee: Oknet Xu > Fix For: 7.0.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Goal 1st: > In the NetVConnection, we have get_local_addr() and get_remote_addr() methods. > Also have members local_addr, remote_addr and netvc->con.addr. > Thus, we should using netvc->con.addr or remote_addr to replace member > server_addr in UnixNetVConnection. > Goal 2nd: > SSLNetVConnection has member sslClientConnection with 2 methods > setSSLClientConnection() and getSSLClientConnection() to indictor ATS is a > client or server in a SSL session. > To abstract above two goals, I'm design the netvc context function. > As a proxy, there has two side: client side ( Client <-> Proxy ) and server > side ( Proxy <-> Server ). With the netvc context funtion to indicate which > side the NetVC working on. > Goal 3rd: > Fix a minor bug in NetAccept::do_blocking_accept, call to > check_emergency_throttle(con) first then allocate vc. > Goal 4th: > NetAccept Optimize, remove dup code, etc... -- This message was sent by Atlassian JIRA (v6.3.4#6332)