>I would argue that, architecturally, this kind of work doesn't belong in
>the "request processing" portion of the application. I generally do this
>kind of thing with cron jobs. Otherwise, you can have HTTP requests
>kicking-off lots of long-running processes. That may be possible in
>Java, but I'm not sure it's always advisable.
True, in general, but not just any HTTP request can spawn this thread. The
component is invoked via a GUI that is secured, so only someone with the
appropriate credentials can start the blast. Furthermore the component has
additional sanity-checks just in case someone tries spawning multiple
threads (which would break the constraint on per second requests).
Also the processing this thread does is episodic, not regular, so if I
couldn't invoke it via the management GUI, then i'd have to log into the
server and execute a bash scriptor some other one-off kludge thats slap-dash
and hard to maintain :-(
On Tue, Mar 24, 2009 at 11:25 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jonathan,
>
> On 3/20/2009 7:53 PM, Jonathan Mast wrote:
> >> 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.
>
> I would argue that, architecturally, this kind of work doesn't belong in
> the "request processing" portion of the application. I generally do this
> kind of thing with cron jobs. Otherwise, you can have HTTP requests
> kicking-off lots of long-running processes. That may be possible in
> Java, but I'm not sure it's always advisable.
>
> On the other hand, a background thread (in the same JVM) that serially
> processes some jobs scheduled by request processors (say, like sending
> an email message) is often a good idea. Just as long as you don't run
> "new Thread().start()" during request handling, which is a bit scary.
>
> > 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?
>
> I have no idea. I wasn't saying that you can do that in PHP (or, at
> least, you can't fire-off background threads during request
> processing)... I was saying that you shouldn't do that in /any/
> language, so the fact that PHP can't do it isn't really that relevant.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAknI+3sACgkQ9CaO5/Lv0PD+nwCgsCnQrQmKxAZQEN3wVap5Knxz
> zr0AoLKsUjDYMvCWQMxRb2Pe8ib/r88L
> =O3Ls
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
