Обсуждение: Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL

Hi,

> > Web applications should NEVER fork processes or create their own threads.
> > Period. Do this isn't safe in any environment, os, web server or
> development
> > tool. You can see on the J2EE specs that Servlets and EJBs are expressly
> > prohibited from doing this.
>
> Is this true?  I know lots of servelet developers (mostly using Tomcat) that
> do this all the time without encountering any problems.  Could you point me
> to the part in the spec where it indicates that this is inappropriate?

The fact it worked for your friends using Tomcat doesn't mean it isn't wrong.
Take for example IE rendering of CSS attributes. I don't have the J2EE and
Servlet specs at hand to look at, but I'm sure I've read this.

Last year I was talking with Jetty developers (another open source web
container) and they realized they were'nt folowing the specs regarding to
authentication. The specs are a very long document and hot easy to read (or to
locate some specific info), so it's easy to misinterpret them or to forgive
somethg, but some (application) developers never bothered to read it. Just use
trial and error until "something works". :-)

I can't imagine how a web server cannot be affected by apps creating threads
and/or proccesses. Think about memmory use, resource pooling, syncronization
issues, ... remember a child process ot thread prevents the termination of its
parent (which may become a zombie on Unix systems, and a zombie still holds its
open file handles). If these child threads are buggy they could get to the
point the web server cannot accept new requests.

You may be lucky and never crash your server. But you may not be. The
difference between reliable and unreliabe system is the first ones don't leave
it to lucky, they impose rigid standard on coding practices and won't do things
that "just work".

[]s, Fernando Lozano

> > > Web applications should NEVER fork processes or create their own
threads.
> > > Period. Do this isn't safe in any environment, os, web server or
> > development
> > > tool. You can see on the J2EE specs that Servlets and EJBs are
expressly
> > > prohibited from doing this.
> >
> > Is this true?  I know lots of servelet developers (mostly using Tomcat)
that
> > do this all the time without encountering any problems.  Could you point
me
> > to the part in the spec where it indicates that this is inappropriate?
>
> The fact it worked for your friends using Tomcat doesn't mean it isn't
wrong.
> Take for example IE rendering of CSS attributes. I don't have the J2EE and
> Servlet specs at hand to look at, but I'm sure I've read this.

I realize that.  That is why I asked the question.  I'm just saying that
when I hear people that I trust tell me that it is a common accepted
practice and then I hear someone else tell me otherwise I'm not just going
to take either side's opinion.  Seeing the spec however would be nice
because next time I discuss it witha Java developer I could back up what I
was saying.  (It would be especially nice when the developer is bashing php
for it's lack of thread support.)

> Last year I was talking with Jetty developers (another open source web
> container) and they realized they were'nt folowing the specs regarding to
> authentication. The specs are a very long document and hot easy to read
(or to
> locate some specific info), so it's easy to misinterpret them or to
forgive
> somethg, but some (application) developers never bothered to read it. Just
use
> trial and error until "something works". :-)

All the more reason not to take anyone's word at face value (your's or my
servelet writing friends') but rather to read the spec for myself.

> I can't imagine how a web server cannot be affected by apps creating
threads
> and/or proccesses. Think about memmory use, resource pooling,
syncronization
> issues, ... remember a child process ot thread prevents the termination of
its
> parent (which may become a zombie on Unix systems, and a zombie still
holds its
> open file handles). If these child threads are buggy they could get to the
> point the web server cannot accept new requests.

That fact that I know that this is being done regularly on widely deployed
entrprise wide applications for very, very large companies without even a
hint of a problem makes me think that your perception of the issue may be
slightly flawed.  If you can't imagine how this would ever not cause huge
problems then I think you just might be missing something.  The fact is, and
I have discussed the issue at length with the actual developers, is that it
works like a charm causing no noticible problems.  The software is heavily
used and very mission critical.

> You may be lucky and never crash your server. But you may not be. The
> difference between reliable and unreliabe system is the first ones don't
leave
> it to lucky, they impose rigid standard on coding practices and won't do
things
> that "just work".

Which is why I feel that your analysis of the situation is missing
something.  If they were relying on luck to not have their servers crash
they would notice.  They have very, very reliable systems running mission
critical applications with high levels of usage and concurrency.  In
addition it makes a lot of sense to me why forking an apache process would
cause all kind of problems.  It does not make as much sense to me that
spawning a new thread inside of Tomcat (or any other servlet container)
would cause any more problems then spawning a thread inside of any other
application.  Obviously it must be done correctly and carefully but I don't
see why when done right it should cause any problems.

I would be interested to read the spec sometime and check it out for myself.
Sometimes however searching for something that someone else says they are
"sure" that they have read is sometimes harder than finding something that
is actually there.  I'm not saying that you are wrong I'm just saying that
what your saying doesn't match up at all with what I have experienced or
talked about with anyone else and thus I am suspicious of it.

listas@lozano.eti.br writes:

> I can't imagine how a web server cannot be affected by apps creating
> threads and/or proccesses. Think about memmory use, resource
> pooling, syncronization issues, ... remember a child process ot
> thread prevents the termination of its parent (which may become a
> zombie on Unix systems, and a zombie still holds its open file
> handles).

This is wrong.  Parents *can* terminate with running children, and
zombie processes take up no resources other than a process table slot.

-Doug

> > I can't imagine how a web server cannot be affected by apps creating
> > threads and/or proccesses. Think about memmory use, resource
> > pooling, syncronization issues, ... remember a child process ot
> > thread prevents the termination of its parent (which may become a
> > zombie on Unix systems, and a zombie still holds its open file
> > handles).
>
> This is wrong.  Parents *can* terminate with running children, and
> zombie processes take up no resources other than a process table slot.

In addition I don't think that if thread A spawns thread B that thread A has
to wait until thread B terminates before it can itself terminate.  Why would
this be the case?  Threads to not necessarily have the same parent child
relationships that processes do.

On Fri, Jan 30, 2004 at 03:45:08PM -0500, Doug McNaught wrote:
> listas@lozano.eti.br writes:
>
> > I can't imagine how a web server cannot be affected by apps creating
> > threads and/or proccesses. Think about memmory use, resource
> > pooling, syncronization issues, ... remember a child process ot
> > thread prevents the termination of its parent (which may become a
> > zombie on Unix systems, and a zombie still holds its open file
> > handles).
>
> This is wrong.  Parents *can* terminate with running children, and
> zombie processes take up no resources other than a process table slot.

Additional zombie processes are automatically cleared when their parent dies
(they are reparented to init, which then takes care of it).

--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> (... have gone from d-i being barely usable even by its developers
> anywhere, to being about 20% done. Sweet. And the last 80% usually takes
> 20% of the time, too, right?) -- Anthony Towns, debian-devel-announce

On Fri, 30 Jan 2004 listas@lozano.eti.br wrote:

> Hi,
>
> > > Web applications should NEVER fork processes or create their own threads.
> > > Period. Do this isn't safe in any environment, os, web server or
> > development
> > > tool. You can see on the J2EE specs that Servlets and EJBs are expressly
> > > prohibited from doing this.
> >
> > Is this true?  I know lots of servelet developers (mostly using Tomcat) that
> > do this all the time without encountering any problems.  Could you point me
> > to the part in the spec where it indicates that this is inappropriate?
>

This was recently discussed on the jdbc list here:

http://archives.postgresql.org/pgsql-jdbc/2003-12/threads.php

The general consensus was that threads are legal in servlets.

Kris Jurka