Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of jhmast.developer@gmail.com
 designates 74.125.46.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ZcZKTITXqc2LlC24LnpQNMlTSsINeiumvDS5RCJuQzRRadPGoCG1w/UQv4rnhYYgZj
         oMn2uneOfiCfUvssiN59DC/adpJFFjF2MgBL33hAOLJONGVI/i3TcTI9nOCVzH1vNUrz
         hoQwCMg3py+lJeXcCj4YvGQfZrKf2iOWdSpKo=
MIME-Version: 1.0
In-Reply-To: <49C4019D.7060500@christopherschultz.net>
References: <007f01c9a974$43a1afa0$d9847159@office.devexperts.com>
	 <49C4019D.7060500@christopherschultz.net>
Date: Fri, 20 Mar 2009 19:53:08 -0400
Message-ID: <f5af14000903201653nb6e1249h80ed88ca15726bc0@mail.gmail.com>
Subject: Re: FW: very off topic marketing question
From: Jonathan Mast <jhmast.developer@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=000e0cd4d7a05c719b0465959e31

--000e0cd4d7a05c719b0465959e31
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

>Meh. Most Java webapps aren't multithreaded anyway in the sense that
>each request lives in its own little world and usually runs start to
>finish with no other threading involved.

Just this week I added threading to a component of my web-app.  I had some
what dreaded it, but found that it took me only a half-hour and about 10
extra lines of code, here's a synopsis:

Thread t = new Thread(new Runnable() {
    public void run() {
        ...blast()
    }
}, "Blast Thread");

t.start();

Where blast() iterates thru several thousand records, which are sent to a
third-party site for processing.  The third-party site allows no more than 5
connections per second, so I just call Thread.sleep(1000) on every 5th
record.

It is very simple, very elegant and very fast now that some much load has
been moved off the main http thread.

My question is: how would this be accomplished in PHP?  Would I need to
recompile the whole php server with a special thread package or what?


On Fri, Mar 20, 2009 at 4:50 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ilya,
>
> Don't get me wrong... I loves me some Java. But...
>
> On 3/20/2009 11:55 AM, Ilya Kazakevich wrote:
> > If you are going to move to php, be ready to:
> > 1) loose tools like log4j.
>
> log4p?
>
> > 2) meet API, 10% of which uses OOP and exceptions, and 90% is procedure /
> > errors based.
>
> This does really suck. It's going back and using C when you've become
> sooo used to exceptions.
>
> > 3) you would not have namespaces.
>
> Meh. I suppose on a large (huge?) project this could be a problem. You
> can always "namespace" your files by using subdirectories. Oh, wait. You
> weren't suggesting that you use objects in PHP were you? Ha ha ha ha.
> Oh, maybe you were. Sorry.
>
> > 4) because of dynamic typization, you would be able to find some types of
> > errors only in runtime.
>
> Java is not safe from runtime errors; they're just (mostly) not the
> kinds of errors that can be prevented using static type-checking. I've
> come-around on this one: static typing is just one way of doing things.
> Ruby's mix-ins are very attractive for those of us who have had trouble
> breaking-into a class hierarchy. :)
>
> > 5) no multithreading
>
> Meh. Most Java webapps aren't multithreaded anyway in the sense that
> each request lives in its own little world and usually runs start to
> finish with no other threading involved.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAknEAZ0ACgkQ9CaO5/Lv0PA66ACfYgElGkBrKzxS2Lp9ABhW9ZZU
> UDgAn0eFpdBXzUCcda4G2LOE5733XSgL
> =X7eW
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

--000e0cd4d7a05c719b0465959e31--