----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 13, 2001 9:08 PM
Subject: Re: The pitfalls in restarting tomcat
> On Thu, 13 Sep 2001, Jonathan Eric Miller wrote:
>
> > Date: Thu, 13 Sep 2001 21:00:01 -0500
> > From: Jonathan Eric Miller <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: The pitfalls in restarting tomcat
> >
> >
> > ----- Original Message -----
> > From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, September 13, 2001 7:40 PM
> > Subject: Re: The pitfalls in restarting tomcat
> >
> >
> > >
> > >
> > > On Thu, 13 Sep 2001, Jonathan Eric Miller wrote:
> > >
> > > > Date: Thu, 13 Sep 2001 19:24:08 -0500
> > > > From: Jonathan Eric Miller <[EMAIL PROTECTED]>
> > > > Reply-To: [EMAIL PROTECTED]
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: The pitfalls in restarting tomcat
> > > >
> > > > IMHO, it would still be nice to have a true easy way to completely
> > restart
> > > > Tomcat. For example, say you were running into memory leak problems
or
> > > > something like that. You might want to schedule a script to run once
a
> > day
> > > > to restart the server. In a perfect world, one would never have to
do
> > this,
> > > > but, sometimes you run into bugs and you want to make sure that
things
> > are
> > > > completely reset.
> > > >
> > >
> > > On Unix, many /etc/rc.d/init.d scripts I've seen implement their
"restart"
> > > command as a shutdown followed by a startup. Why is it any more
> > > complicated than this?
> >
> > You have to put a pause in there too, otherwise you'll get an error
message
> > about the port already listening. This is because when you start it,
> > sometimes, the previous instance hasn't stopped yet.
> >
> A pause won't cut it -- the amount of time a shutdown takes is
> non-deterministic, because the destroy() method of all the initialized
> servlets, filters, and the contextDestroyed() method of listeners is
> called during the shutdown process. It would take code to do this
> reliably.
My point exactly. ;-)
> > > Note also that, if you don't physically restart the JVM, you don't
give
> > > any of the memory it grabbed back to the operating system.
> >
> > The restart command that I'm thinking of would completely stop Tomcat
and
> > start it again, and also shut down the JVM. It would basically, run
> > shutdown.sh and then startup.sh. However, the difference is that it
would
> > shut it down in a synchronous manner not asynchronous. Therefore, it
would
> > start the server back up immediately after it was shut down rather than
> > pausing for an arbitrary period of time waiting for Tomcat to shut down.
> >
> > I think this may be becoming less of an issue than it was before. Prior
to
> > Tomcat 7, the shutdown process seemed very laggy. As of 7 it was a lot
> > better. Now, with RC1, maybe it's just me, but, it seems even better
yet.
> >
>
> There have been substantial improvements in RC1.
>
> > On a somewhat unrelated note, but, speaking of lag, anyone know if Sun
is
> > planning doing anything to speed up the initialization of JSSE?
> >
>
> I would bet this is related to initializing the random number generator.
Yup.
> Do you *really* want to reduce the security of your cryptography?
No, but, what I want to know is why I'm able to start Apache Web Server with
SSL and I don't get this lag? I'm pretty sure that IIS with SSL doesn't take
that long either. There are also numerous other SSL enabled clients that
don't suffer from this kind of lag. I can see if it was only servers that
suffered from this, but that isn't the case. Say I want to write a console
app that is the rough equivalent of ldapsearch in Java that uses SSL.
Everytime, I run that program I'm going to get 15 seconds of lag before it
does anything. iPlanet's ldapsearch doesn't take that long. IMHO, they
should speed it up using native code if that's what it takes (now that JSSE
comes standard with JDK 1.4).
Jon
> The same issue shows up in Tomcat with initialization of the random number
> generator used for session ids. The current initialization algorithm is
> fast, but subject to predictable session ids if an attacker can read
> server.xml.
>
> > Jon
> >
> > > > Jon
> > > >
> > >
> > > Craig
> >
> >
> >
> Craig
>
>
