On Dec 4, 2013, at 9:11 AM, James Peach <jpe...@apache.org> wrote: > On Dec 4, 2013, at 7:37 AM, Leif Hedstrom <zw...@apache.org> wrote: > >> On Dec 3, 2013, at 10:30 PM, jpe...@apache.org wrote: >>> >> >> >> Fwiw, this new_Deleter does not have the same semantics as the old code. The >> old code would schedule the deletion on the ET_TASK thread pool, whereas >> new_Deleter runs on any of the net-threads. This could mean that we’d block >> a net-thread for some time if the remap table is sufficiently large. >> >> I don’t know if it is a real, detrimental problem, but if I recall we moved >> the remap.config reloading / management to ET_TASK because it did have a >> real problem when loading very large configs. > > Oh interesting. All the config processor stuff happens on ET_CALL threads > too. The remap.config loading still happens on the ET_TASK.
Maybe we should move those config processors too ? > >> Maybe the right thing is to make new_Deleter use ET_TASK? > > Yes this sounds like the right thing to do. Ok, I’ll file a Jira (unless you already did?). > >> If there are no task threads configured, that falls back to the old behavior? > > Or make sure we always have at least 1 task thread? Btw, that last sentence was a statement, not a question :). We do fall back on ET_NET (aka CALL) when there are no task threads. The default is at least 1 I think. We could probably change the behavior for v5.0 to require at least 1. Another Jira? — Leif
