1. To log asynchronously can't we use the existing logging code that logs asynchronously the transactions? 2. Logging inline may produce the messages in order, but wouldn't it cause heisenbugs? 3. It looks like the current developers/committers don't know whether logging lnline was intentional or an oversight?
On Mon, Oct 15, 2018 at 8:38 AM Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > It's generally accepted that enable logging messages will decrease ATS > performance by roughly an order of magnitude, but as Dan points out, based > on this, we might be able to do better if the output was sent to an AIO > thread. OTOH, if you're trying to track timing / ordering issues, have the > messages come out asynchronously might negate much of the utility. > > On Sun, Oct 14, 2018 at 10:52 PM Daniel Xu <d...@apache.org> wrote: > > > Yeah that sounds suboptimal. Maybe it’d be good enough to leave a > > documentation note and mark fixing this as an intern project or > > something. > > Writing some off thread logging code and writing a poor man’s multi > > producer queue sounds like a pretty nice project. > > > > Daniel > > > > > > On Tue, Oct 9, 2018, at 7:34 PM, Pushkar Pradhan wrote: > > > I was going through the code in Diags.cc and I saw that if debug > > > logging is> on, ATS calls vfprintf in the thread that handles the > client > > request.> E.g. > > > > > > https://github.com/apache/trafficserver/blob/master/src/tscore/Diags.cc#L301 > > > > > > Is this a good idea? > > > Or is the assumption that if you have turned on debug logging you > > > make this> trade off? > > > > > > -- > > > pushkar > > > > > > -- > *Beware the fisherman who's casting out his line in to a dried up > riverbed.* > *Oh don't try to tell him 'cause he won't believe. Throw some bread to the > ducks instead.* > *It's easier that way. *- Genesis : Duke : VI 25-28 > -- pushkar
