[ 
https://issues.apache.org/jira/browse/TS-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15314870#comment-15314870
 ] 

ASF GitHub Bot commented on TS-4331:
------------------------------------

Github user jacksontj commented on a diff in the pull request:

    https://github.com/apache/trafficserver/pull/653#discussion_r65779442
  
    --- Diff: iocore/hostdb/HostDB.cc ---
    @@ -439,37 +327,24 @@ HostDBCache::start(int flags)
         Warning("Please set 'proxy.config.hostdb.storage_path' or 
'proxy.config.local_state_dir'");
       }
     
    -  hostDBStore = new Store;
    -  hostDBSpan = new Span;
    -  hostDBSpan->init(storage_path, storage_size);
    -  hostDBStore->add(hostDBSpan);
    -
    -  Debug("hostdb", "Opening %s, size=%d", hostdb_filename, hostdb_size);
    -  if (open(hostDBStore, "hostdb.config", hostdb_filename, hostdb_size, 
reconfigure, fix, false /* slient */) < 0) {
    -    ats_scoped_str rundir(RecConfigReadRuntimeDir());
    -    ats_scoped_str config(Layout::relative_to(rundir, "hostdb.config"));
    +  // Combine the path and name
    +  char full_path[2 * PATH_NAME_MAX];
    --- End diff --
    
    Yea, TBH I'm not sure why thats like that-- it was before (in a different 
part of the code-- moved to here. Presumably we actually know what the size 
is-- since we have the filename and path... I can definitely clean that :)


> Hostdb consistency problems due to MultiCache
> ---------------------------------------------
>
>                 Key: TS-4331
>                 URL: https://issues.apache.org/jira/browse/TS-4331
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: HostDB
>            Reporter: Thomas Jackson
>            Assignee: Thomas Jackson
>             Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to