GOMEZ Henri wrote:
>
> >Just realised that the core I have was compiled without -g option. VERY
> >useful. I also wanted to replicate the core dump with the
> >httpd that was
> >compiled with -g, but that didn't work. Now I'm starting to think that
> >the core file I had was a result of a differe
jean-frederic clere wrote:
>
> GOMEZ Henri wrote:
> >
> > >Just realised that the core I have was compiled without -g option. VERY
> > >useful. I also wanted to replicate the core dump with the
> > >httpd that was
> > >compiled with -g, but that didn't work.
>
> What did not work? -It does not
GOMEZ Henri wrote:
> Ask to Apache specialist in new-http list, may be JF Clere could
> forward your question to them ?
I'll subscribe to the list and try to find out how it's done. Then
(hopefully) I'll be able to send over something you can work with.
Bojan
The announcement reads:
The new class loader scheme in this release ignores your CLASSPATH
setting. Instead, you may add needed jars to Tomcat's "lib/apps",
"lib/common", and "lib/container" directories. See the "readme" file
in Tomcat's "doc" directory for details.
Also supported are two
GOMEZ Henri wrote:
>
> >> >> Good information, and could send us a strace ?
> >> >
> >> >This may sound strange to all you Apache experts, but how
> >do I do that?
> >> >How do I run strace on a detached process?
> >>
> >> strace httpd -f (follow forks)
> >
> >Thanks for the tip. The log file (bz
jean-frederic clere wrote:
>
> Bojan Smojver wrote:
> >
> > GOMEZ Henri wrote:
> > >
> > > >> Good information, and could send us a strace ?
> > > >
> > > >This may sound strange to all you Apache experts, but how do I do that?
&g
GOMEZ Henri wrote:
>
> >> Good information, and could send us a strace ?
> >
> >This may sound strange to all you Apache experts, but how do I do that?
> >How do I run strace on a detached process?
>
> strace httpd -f (follow forks)
Thanks for the tip. The log file (bziped) is attached.
Bojan
GOMEZ Henri wrote:
>
> >Now I have some new info here. After recompiling everything clean, I've
> >taken out PHP altogether. So it's not part of the equation. It is
> >sufficient to compile mod_jk in and use static pages only (ie. no
> >JSP's/VM at all). If you gracefully restart the server a
> >
GOMEZ Henri wrote:
>
> >Now I have some new info here. After recompiling everything clean, I've
> >taken out PHP altogether. So it's not part of the equation. It is
> >sufficient to compile mod_jk in and use static pages only (ie. no
> >JSP's/VM at all). If you gracefully restart the server a
> >
Bojan Smojver wrote:
>
> GOMEZ Henri wrote:
> >
> > >Just did a DSO version and couldn't replicate the problem (BTW, I've
> > >recompiled/statically linked Apache and mod_jk again since then and the
> > >problem was still there). So, maybe it ha
GOMEZ Henri wrote:
>
> >Just did a DSO version and couldn't replicate the problem (BTW, I've
> >recompiled/statically linked Apache and mod_jk again since then and the
> >problem was still there). So, maybe it has to do with statically linking
> >Apache after all...
>
> Strange problem. What's t
GOMEZ Henri wrote:
> >I still have to distribute this DSO version of Apache and mod_jk to some
> >slower machines to see if that makes any difference at all. The machine
> >that didn't produce any errors is a 1 GHz Athlon, so timing issues could
> >have been resolved by brute force, who knows...
>
GOMEZ Henri wrote:
>
> >Just did a DSO version and couldn't replicate the problem (BTW, I've
> >recompiled/statically linked Apache and mod_jk again since then and the
> >problem was still there). So, maybe it has to do with statically linking
> >Apache after all...
>
> Strange problem. What's t
Bojan Smojver wrote:
> As for DSO, I'll have to work on that, so probably some time tomorrow
> (Sydney time).
Just did a DSO version and couldn't replicate the problem (BTW, I've
recompiled/statically linked Apache and mod_jk again since then and the
problem was still the
OOPS! Sorry :-(
jk.conf (called from httpd.conf)
-
###
# Apache JK Configuration
File#
###
After including it in Apache 1.3.20, statically compiled/linked for
RedHat Linux 7.0, the error messages 'child pid x exit signal
Segmentation fault (11)' start appearing in the error log file of
Apache. mod_jk from Tomcat 3.3 M3 works fine with both Tomcat M3 and the
latest 3.3 CVS snapshot.
[EMAIL PROTECTED] wrote:
> You may file a feature request on bugzilla, attach you patch - this way
> it'll be recorded.
Done.
> Or send few more patches ( there are many open bugs, most of them are
> easy to solve but require time to test and reproduce ), and you'll be
> able to check in the pa
Don't know if the patch for this was missed (since it was buried into a
long e-mail), you guys didn't like it or just didn't have time to
implement. Anyway, I'm doing it clean in this e-mail. Thanks to Doug
Barnes who explained the issues of random number generation...
Here is the patch (I had to
Doug Barnes wrote:
> You only have so much entropy that's available on a given machine at a
> given time. From the same manpage, you can see that if you have access
> to more entropy than /dev/random knows about normally, you can write it
> back to /dev/random (they give an example) but at the en
Doug Barnes wrote:
> The answer to these arguments are: use /dev/urandom, not
> /dev/random. It's going to do as good or better than anything
> you're going to seed with /dev/random, and IT WILL NOT BLOCK.
>
> I may be wrong (I'm just starting to poke around in related
> code) but it doesn't loo
[EMAIL PROTECTED] wrote:
> As pointed out by someone else, at some point on a system that is not
> busy processes will hang on /dev/random waiting for their next chance to
> catch some randomness generated by things like mouse moves. And if you
> are on a server, the mouse may never move. There w
another note, you might want to mention in mod_jk documentation
that a mount like this has to exist:
JkMount /login/j_security_check ajp13
or j_security_check won't work from Apache. That's provided your login
and error pages live in /login directory.
Bojan
Bojan Smojver wrote:
>
d and so the first time a
> jsp page or servlet tries to getSession(), a null
> pointer exception occurs. We need to figure out some
> way to have a default sid generator get instantiated
> in the absence of an explicit server.xml entry (or at
> least a decent error message).
>
>
tor shuld set the id.
>
> I can't reproduce the problem, and probably it would be simpler if you
> could add few println() and check if SessionIdGenerator got called and why
> is it not generating the random id.
>
> Costin
>
> On Wed, 11 Apr 2001, Bojan Smojver wrot
verSession that when getId() is called, it returns
MessageBytes that are actually a string, so that toString() from it
returns something meaningful.
Bojan
Bojan Smojver wrote:
>
> I'm not sure if this is something I'm doing... Anyway, latest Tomcat 3.3
> from CVS gives me this:
&
I was tossing this idea around as well after I couldn't get mod_webapp
to work successfully with Tomcat 4.
Tomcat might be good for HTTP but it's probably faster to employ mod_ssl
to do HTTPS.
In the proxy setup like that, what would happen to the SSL connections?
Would Tomcat have to do that ki
[EMAIL PROTECTED] wrote:
>
Thanks. I figured it out after I asked that silly question. It must have
been the most brain dead question you had to answer in a while, I guess.
A good read of server.xml will get you a long way these days ;-)
> Note that the option will be disabled by default ( I'
[EMAIL PROTECTED] wrote:
> Given that tomcat should run for days or weeks at a time, I don't think
> you want to keep /dev/random open. There maybe other processes that also
> need random data during that time.
Are you really sure that other processes are unable to use /dev/random
while Tomcat is
I'm not sure if this is something I'm doing... Anyway, latest Tomcat 3.3
from CVS gives me this:
2001-04-10 20:23:06 - JspFactoryImpl: Exception initializing page
context - java.lang.NullPointerException
at java.util.Hashtable.remove(Hashtable.java:421)
at
org.apache.tomcat.module
No worries. It's purely selfish ;-) I kind of need JDBCRealm to work
with encrypted password and per virtual host, so that's why Tomcat
3.3...
I would just like someone from a certain software company to join this
mailing list to see how fast the bugs are fixed in open source. I've
already applau
Forgot to ask, would you be interested in instructions/simple shell
script for building mod_jk as a statically linked Apache module?
Bojan
Dan Milstein wrote:
>
> I can't speak to mod_webapp, but a mod_jk response:
>
> > - I understand the need for the TCP connections to be persistent in
> > m
[EMAIL PROTECTED] wrote:
> The patch allows systems that have /dev/random to use it instead of the
> slower Random. Instead of checking for OS==linux ( as in submited patch )
> we use an option of the module.
Cool.
> The code if the option "useDevRandom" is not set is the same as befor
The digest should be called on credentials, not on what's picked up from
the database. That would already be digested. Here is the patch for
JDBCRealm.java:
---
jakarta-tomcat-3.3-src-original/src/share/org/apache/tomcat/modules/aaa/JDBC
Realm.java Wed Feb 28 06:10:16 2001
+++
jakarta-tomcat
I think there is a bug in AccessInterceptor.java, line 488, which only
shows when cookies are turned off in server.xml file with:
The problem is related to the fact that at the time of 'if', the
req.getSessionIdSource() returns null and the test is blown sky high
(ie. there is a NullPointerExce
Beauty.
I'm actually playing with 3.3 as well, because some of the features I
like (eg. realm per host) are there as well.
Bojan
Dan Milstein wrote:
>
> I can't speak to mod_webapp, but a mod_jk response:
>
> > - I understand the need for the TCP connections to be persistent in
> > mod_jk and
I've posted a few messages about this to Tomcat User list, but since
this is really development related, I'm posting this one here.
Basically, mod_webapp packaged with Tomcat 4.0 b2 and b3 doesn't
compile, so I switched back to the version from b1. I've noticed a few
things:
- I'm confused as to
301 - 336 of 336 matches
Mail list logo
