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 process
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
} pr
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 lev
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 should be
learned at initialization time and then kept in state
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)
logg
On Mon, 2009-11-30 at 10:10 -0500, Kaiduan Xie wrote:
...
> > Ejabberd's solution sounds neat, but I think it should be measured
> > against the much simpler variant of adding a case statement checking the
> > log level before calling format_msg in logger:do_log/3.
>
> Then we need to save the log
Fredrik,
Please see my inline comments.
Thanks,
kaiduan
On Mon, Nov 30, 2009 at 4:14 AM, Fredrik Thulin wrote:
> 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 eac
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 o
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 m
On Thu, 2009-11-26 at 09:09 +0100, Fredrik Thulin wrote:
...
> >Upon receiving Message 100-4, message 180-5, and message 200-7, YXA
> > creates a process, and then just passes the message to client and
> > server transaction.
>
> Does it? I don't have the time to actually look it up, but my
>
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
11 matches
Mail list logo
