On Tue, 2009-12-01 at 13:33 -0500, Vance Shipley wrote:
On Mon, Nov 30, 2009 at 10:10:38AM -0500, Kaiduan Xie wrote:
} Then we need to save the log level to ETS or Mnesia, and every time,
} you want to log, we need to read from ETS/Mnesia.
That is not the functional way. The debug level
On Tue, Dec 01, 2009 at 08:45:32PM +0100, Fredrik Thulin wrote:
} Would passing an ETS table reference count as functional? ;)
No, not really.
} We're moving from having a named table with global configuration data
} towards passing a reference to /a/ version of configuration data that a
}
On Mon, 2009-11-30 at 21:15 -0500, Kaiduan Xie wrote:
Fredrik,
Adding line number and module name to the log is quite helpful to read
the log, at least from my personal experience.
Well, I'm not sure... I see the current (debug) log as more of a story
about what happened when YXA processed
On Fri, 2009-11-27 at 15:08 -0500, Kaiduan Xie wrote:
Thank you Fredrik for the clarification on the rationale.
You are most welcome.
In fact, spawning a process for each request is not creating
performance bottleneck at all. I just want to understand the reason.
Logger creates a lot of
Fredrik,
Adding line number and module name to the log is quite helpful to read
the log, at least from my personal experience. I agreed with you that
in order to to do that we need to change a lot of code in YXA, for
example replacing the log with macro.
-define DEBUG(Formats, Parameter)
Thank you Fredrik for the clarification on the rationale.
In fact, spawning a process for each request is not creating
performance bottleneck at all. I just want to understand the reason.
Logger creates a lot of overhead in the code. Now no matter if the log
level is big enough, YXA formats the
On Wed, 2009-11-25 at 16:58 -0500, Kaiduan Xie wrote:
Hi, all,
I have two questions on the design of YXA.
I appreciate that someone takes the time to look that deep into the
source code. Thanks!
1. Client transaction and server transaction are implemented as
gen_server, why not choose
