The problem is that the default cache size is one and in the ajp_init
function
in jk_ajp_common.c we return from inside of an if when we initialize
the cache
so the secrect member of the structure never gets initialized. This
caused
some GPFs in certain cases on some of my builds.
I've
Remy Maucherat wrote:
The problem is that the default cache size is one and in the ajp_init
function
in jk_ajp_common.c we return from inside of an if when we initialize
the cache
so the secrect member of the structure never gets initialized. This
caused
some GPFs in certain
On Wed, 2002-02-13 at 15:40, [EMAIL PROTECTED] wrote:
If you ever see any commit (from me) that late in a release cycle - make
sure you -1 it, regardless of how usefull it may look. Peer review seems
to work well, but it needs more time.
After half a billion commits you introduced a bug.
One of the last changes on the connector ( the secret )
introduced a bug,
when worker_cache is enabled. The secret will not be initialized, and
that may creates all kind of serious problems.
Could you detail the problem ?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
The problem is that the default cache size is one and in the ajp_init
function
in jk_ajp_common.c we return from inside of an if when we initialize
the cache
so the secrect member of the structure never gets initialized. This
caused
some GPFs in certain cases on some of my builds.
I've checked
On Tue, 12 Feb 2002, Mike Anderson wrote:
The problem is that the default cache size is one and in the ajp_init
The problem is that I spent too much time writing java code. I didn't see
the return statement, the deep if() have confused me.
If you ever see any commit (from me) that late in a
