You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Eric P <er...@gmail.com> on 2010/07/22 06:58:37 UTC
Fire off asynch task in Tomcat.
Hi all,
In my Tomcat app I'm looking for a good (or commonly used) method for firing off an asynchronous task. For example, a
user registers for an account, and an a task to send a verification email to the user is triggered w/o delaying the
response to the user (i.e., task happens in the background).
I'm somewhat aware that JMS could be used for this and is part of most J2E environments, but I'd like to see if there's
some way to pull this off w/vanilla Tomcat.
I had a couple ideas that would probably work, but I'd like to see how others have solved this problem.
One idea would be to insert a record into a database table that signifies an email should be sent to the user. This
table could be regularly checked by a scheduled job (e.g., a TimerTask) that runs every minute in the background.
Another (maybe not so good) idea would be to leverage perhaps a session or request attribute listener that would check
for a certain attribute being added to a session or requests. Then if a 'send email' attribute comes through, the
listener could process an email. This seems like a bad idea though as I believe the listener event class would be
triggered incessantly any time attributes are added/removed when in fact I'm only actually interested in the 'send
email' attribute.
Anyway, I'm open to all ideas and appreciate you indulging me this far.
Eric P.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 7/23/2010 2:22 PM, André Warnier wrote:
> You can of course imagine which language I was thinking of.
#!/usr/bin/perl
use Perl::MailSendFromDbQueue;
go("mydb", "user", "pass");
#end
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxRnfEACgkQ9CaO5/Lv0PBEygCeOq8mr991YWfBmcSIvhL+U7I7
/yUAnRCCf/oNX8vP1hc67sNiX0ICHiyk
=Ai6J
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Eric,
>
> On 7/22/2010 7:41 PM, Eric P wrote:
>> I'll probably go w/the email queue/database table approach. All the
>> points André and Christopher raised gave me further insight into the
>> robustness of this approach (loose coupling w/the app, no extra lib
>> dependencies, emails not lost if the app goes down, etc.). Also, the
>> email queue table can serve as a nice log of emails processed.
>
> Heh, I hadn't thought of that point, which is an excellent one.
>
> Another (potential) advantage of using a database to hold the "queue" is
> that you can then choose some other programming language to do the
> actual email sending if that's more convenient for you.
>
Too late, that suggestion was already made :
".. it does not even depend on the programming language used to write the email-sending job.."
You can of course imagine which language I was thinking of.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric,
On 7/22/2010 7:41 PM, Eric P wrote:
> I'll probably go w/the email queue/database table approach. All the
> points André and Christopher raised gave me further insight into the
> robustness of this approach (loose coupling w/the app, no extra lib
> dependencies, emails not lost if the app goes down, etc.). Also, the
> email queue table can serve as a nice log of emails processed.
Heh, I hadn't thought of that point, which is an excellent one.
Another (potential) advantage of using a database to hold the "queue" is
that you can then choose some other programming language to do the
actual email sending if that's more convenient for you.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxJ27UACgkQ9CaO5/Lv0PAgEQCcDZlPk6RlfDPcCdANbTlvht1e
3SAAoKmHbkqZdFkPgTLYXnJkwApfQE2W
=GjNk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Eric P <er...@gmail.com>.
Christopher Schultz wrote:
> Oh, and one more thing: any in-memory solution you come up with (that
> is, without writing to a database) is likely to suffer from loss of jobs
> in the event of a crash or poorly-coded exception-handling.
>
> This isn't necessarily a case for using a separate process just for
> sending emails, but definitely a case for writing your "job" to the
> database synchronously during the request so that you're sure it was
> written.
>
Thanks everyone for all your excellent ideas. I duly read all of them (*grin*).
I'll probably go w/the email queue/database table approach. All the points André and Christopher raised gave me further
insight into the robustness of this approach (loose coupling w/the app, no extra lib dependencies, emails not lost if
the app goes down, etc.). Also, the email queue table can serve as a nice log of emails processed.
Anyway, you all were super helpful. Thanks again!
Eric P.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric,
On 7/22/2010 12:56 PM, Christopher Schultz wrote:
> Eric,
>
> On 7/22/2010 12:58 AM, Eric P wrote:
>> One idea would be to insert a record into a database table that
>> signifies an email should be sent to the user. This table could be
>> regularly checked by a scheduled job (e.g., a TimerTask) that runs every
>> minute in the background.
>
> I like this idea in theory, but prefer a different implementation: use
> cron instead of TimerTask. Make your email-sending code completely
> separate from your webapp.
>
> This will give you greater flexibility and you can even have the job
> running on a completely different server. Plus, if you decide to cluster
> your webapp, you don't have to figure out how to choose which cluster
> member should run the email job and which ones should not.
>
>> Another (maybe not so good) idea would be to leverage perhaps a session
>> or request attribute listener that would check for a certain attribute
>> being added to a session or requests.
>
> This sounds overly complicated.
Oh, and one more thing: any in-memory solution you come up with (that
is, without writing to a database) is likely to suffer from loss of jobs
in the event of a crash or poorly-coded exception-handling.
This isn't necessarily a case for using a separate process just for
sending emails, but definitely a case for writing your "job" to the
database synchronously during the request so that you're sure it was
written.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxIeYIACgkQ9CaO5/Lv0PC7xgCfYS9iTWmINbxkr/wrGx3wAnCs
1RgAoJj3aH4MVgfqkzEtSBfglWUz6w13
=gaIt
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric,
On 7/22/2010 12:58 AM, Eric P wrote:
> One idea would be to insert a record into a database table that
> signifies an email should be sent to the user. This table could be
> regularly checked by a scheduled job (e.g., a TimerTask) that runs every
> minute in the background.
I like this idea in theory, but prefer a different implementation: use
cron instead of TimerTask. Make your email-sending code completely
separate from your webapp.
This will give you greater flexibility and you can even have the job
running on a completely different server. Plus, if you decide to cluster
your webapp, you don't have to figure out how to choose which cluster
member should run the email job and which ones should not.
> Another (maybe not so good) idea would be to leverage perhaps a session
> or request attribute listener that would check for a certain attribute
> being added to a session or requests.
This sounds overly complicated.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxIeDkACgkQ9CaO5/Lv0PB86gCeO9Mhqdl7UJ/LvgP5TesfKL19
x3QAn04tmdN36IfSoka2JFNt2lavV/7J
=fX2A
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Padam J Singh <me...@padamj.com>.
Eric,
You can use a simple Consumer/Producer pattern here.
See the java.util.Queue classes. What I have done in a similar situation
is create a single Queue, multiple consumer threads all blocking on the
same queue. A user action puts something in the queue, and one of the
thread comes out of the blocked state to de-queue it and process the
request (which in your case would be sending the email).
Padam
On 22/07/10 10:28 AM, Eric P wrote:
> Hi all,
>
> In my Tomcat app I'm looking for a good (or commonly used) method for
> firing off an asynchronous task. For example, a user registers for an
> account, and an a task to send a verification email to the user is
> triggered w/o delaying the response to the user (i.e., task happens in
> the background).
>
> I'm somewhat aware that JMS could be used for this and is part of most
> J2E environments, but I'd like to see if there's some way to pull this
> off w/vanilla Tomcat.
>
> I had a couple ideas that would probably work, but I'd like to see how
> others have solved this problem.
>
> One idea would be to insert a record into a database table that
> signifies an email should be sent to the user. This table could be
> regularly checked by a scheduled job (e.g., a TimerTask) that runs
> every minute in the background.
>
> Another (maybe not so good) idea would be to leverage perhaps a
> session or request attribute listener that would check for a certain
> attribute being added to a session or requests. Then if a 'send
> email' attribute comes through, the listener could process an email.
> This seems like a bad idea though as I believe the listener event
> class would be triggered incessantly any time attributes are
> added/removed when in fact I'm only actually interested in the 'send
> email' attribute.
>
> Anyway, I'm open to all ideas and appreciate you indulging me this far.
>
> Eric P.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Pid <pi...@pidster.com>.
On 22/07/2010 15:37, André Warnier wrote:
> Mikolaj Rydzewski wrote:
>> On 07/22/2010 03:49 PM, Martin Gainty wrote:
>>> //i wasnt able to determine JMX ability to schedule a specific task
>>> for a specific time?
>>>
>>
>> I was referring to Andre's sentence:
>> "[using database] makes it easier to suspend/resume the sending of
>> emails separately if you need to for some reason, without having to
>> change anything to your running webapp. "
>>
>> One can use JMX to interact with code running in (possibly even
>> remote) JVM. So, one can use JMX to stop/start sending emails, using
>> custom code of course.
>> And my point was (with laugh), that now it becomes interesting and
>> exciting feature to implement.
>>
> And I got the point, and appreciated it.
> :-)
>
> Maybe we should have a competition for whom can find the most exciting
> and complex solution to the OP's problem. I'm sure we could fit SOAP in
> there somewhere, and use Hadoop for the db back-end.
> ;-)
Not forgetting JTA, JMS, JSF, EJB, JPA, JAF, etc...
Wait, then we'd have Glassfish.
p
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Fire off asynch task in Tomcat.
Posted by André Warnier <aw...@ice-sa.com>.
Mikolaj Rydzewski wrote:
> On 07/22/2010 03:49 PM, Martin Gainty wrote:
>> //i wasnt able to determine JMX ability to schedule a specific task
>> for a specific time?
>>
>
> I was referring to Andre's sentence:
> "[using database] makes it easier to suspend/resume the sending of
> emails separately if you need to for some reason, without having to
> change anything to your running webapp. "
>
> One can use JMX to interact with code running in (possibly even remote)
> JVM. So, one can use JMX to stop/start sending emails, using custom code
> of course.
> And my point was (with laugh), that now it becomes interesting and
> exciting feature to implement.
>
And I got the point, and appreciated it.
:-)
Maybe we should have a competition for whom can find the most exciting and complex
solution to the OP's problem. I'm sure we could fit SOAP in there somewhere, and use
Hadoop for the db back-end.
;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
On 07/22/2010 03:49 PM, Martin Gainty wrote:
> //i wasnt able to determine JMX ability to schedule a specific task for a specific time?
>
I was referring to Andre's sentence:
"[using database] makes it easier to suspend/resume the sending of
emails separately if you need to for some reason, without having to
change anything to your running webapp. "
One can use JMX to interact with code running in (possibly even remote)
JVM. So, one can use JMX to stop/start sending emails, using custom code
of course.
And my point was (with laugh), that now it becomes interesting and
exciting feature to implement.
--
Mikolaj Rydzewski<mi...@ceti.pl>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Fire off asynch task in Tomcat.
Posted by Martin Gainty <mg...@hotmail.com>.
Miki/Andre
//i wasnt able to determine JMX ability to schedule a specific task for a specific time?
//could you reply with an example demonstrating that capability?
//in the meanwhile you *could* implement Axis2 SchedulerTimerTask
//granted java.util.Timer is weak on specific time but if you would be willing to deploy axis2 as a TC webapp you *could* use SchedulerTimerTask
public class org.apache.axis2.deployment.scheduler.SchedulerTimerTask extends java.util.TimerTask {
private org.apache.axis2.deployment.scheduler.DeploymentIterator iterator;
private org.apache.axis2.deployment.scheduler.SchedulerTask schedulerTask;
public SchedulerTimerTask(org.apache.axis2.deployment.scheduler.SchedulerTask schedulerTask, org.apache.axis2.deployment.scheduler.DeploymentIterator iterator) {
this.schedulerTask = schedulerTask;
this.iterator = iterator;
}
public void run() {
schedulerTask.run();
reschedule(schedulerTask, iterator); //this will ultimately call to reschedule
}
private void reschedule(SchedulerTask schedulerTask, DeploymentIterator iterator) {
Date time = iterator.next(); //DeploymentIterator next will acquire the date/time the Task will be scheduled
if (time == null) {
schedulerTask.cancel();
} else {
synchronized (schedulerTask.lock) {
if (schedulerTask.state != SchedulerTask.CANCELLED) {
schedulerTask.timerTask = new SchedulerTimerTask(schedulerTask, iterator);
timer.schedule(schedulerTask.timerTask, time);
}
}
}
}
//DeploymentIterator handles the schedule date/time
public class org.apache.axis2.deployment.scheduler.DeploymentIterator {
private java.util.Calendar calendar = java.util.Calendar.getInstance();
public java.util.Date next() {
//tweak this for your specific Date/Time
// calendar.add(Calendar.SECOND, 10); //default date/time is current date/time and add 10 seconds
return calendar.getTime();
}
}
//org.apache.axis2.deployment.scheduler.Scheduler contains test harness to test DeploymentIterator.next()
public void schedule(SchedulerTask schedulerTask, DeploymentIterator iterator) {
Date time = iterator.next();
if (time == null) {
schedulerTask.cancel();
} else {
synchronized (schedulerTask.lock) {
schedulerTask.state = SchedulerTask.SCHEDULED;
schedulerTask.timerTask = new SchedulerTimerTask(schedulerTask, iterator);
timer.schedule(schedulerTask.timerTask, time);
}
}
}
dziekuje
Martin
______________________________________________
Jogi és Bizalmassági kinyilatkoztatás/Note de déni et de confidentialitéCe message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Thu, 22 Jul 2010 11:19:19 +0200
> From: miki@ceti.pl
> To: users@tomcat.apache.org
> Subject: Re: Fire off asynch task in Tomcat.
>
> On 07/22/2010 10:33 AM, André Warnier wrote:
> > Talking further to myself, I'll add that it also makes it easier to
> > suspend/resume the sending of emails separately if you need to for
> > some reason, without having to change anything to your running webapp.
> >
> > I know, it is certainly less exciting than using consumer/producer
> > patterns or Executor classes.. sigh.
>
> No no.
>
> You have opportunity then to use JMX for altering anything inside
> webapplication.
> It becomes more exciting :-)
>
> --
> Mikolaj Rydzewski<mi...@ceti.pl>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3
Re: Fire off asynch task in Tomcat.
Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
On 07/22/2010 10:33 AM, André Warnier wrote:
> Talking further to myself, I'll add that it also makes it easier to
> suspend/resume the sending of emails separately if you need to for
> some reason, without having to change anything to your running webapp.
>
> I know, it is certainly less exciting than using consumer/producer
> patterns or Executor classes.. sigh.
No no.
You have opportunity then to use JMX for altering anything inside
webapplication.
It becomes more exciting :-)
--
Mikolaj Rydzewski<mi...@ceti.pl>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 7/22/2010 4:33 AM, André Warnier wrote:
> André Warnier wrote:
> Talking further to myself, I'll add that it also makes it easier to
> suspend/resume the sending of emails separately if you need to for some
> reason, without having to change anything to your running webapp.
+1
> I know, it is certainly less exciting than using consumer/producer
> patterns or Executor classes.. sigh.
This is still a producer/consumer pattern, honestly. It's just that the
classes are communicating using a database-based queue instead of via
method calls, etc.
I've built a wonderfully over-engineered email sending program that uses
the Executor classes. It actually is a multi-threaded and pipelined
report-generation-and-emailing program. It chews through tons of
quarterly reports and runs quite well.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxIeNcACgkQ9CaO5/Lv0PBIjQCgrDrW+/E2GwhMueyvPsiNbiUh
KmoAnirc+zn0MBrrjxmUabq2ODZN7904
=atUL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by André Warnier <aw...@ice-sa.com>.
André Warnier wrote:
> Eric P wrote:
>> Hi all,
>>
>> In my Tomcat app I'm looking for a good (or commonly used) method for
>> firing off an asynchronous task. For example, a user registers for an
>> account, and an a task to send a verification email to the user is
>> triggered w/o delaying the response to the user (i.e., task happens in
>> the background).
>>
>> I'm somewhat aware that JMS could be used for this and is part of most
>> J2E environments, but I'd like to see if there's some way to pull this
>> off w/vanilla Tomcat.
>>
>> I had a couple ideas that would probably work, but I'd like to see how
>> others have solved this problem.
>>
>> One idea would be to insert a record into a database table that
>> signifies an email should be sent to the user. This table could be
>> regularly checked by a scheduled job (e.g., a TimerTask) that runs
>> every minute in the background.
>>
>> Another (maybe not so good) idea would be to leverage perhaps a
>> session or request attribute listener that would check for a certain
>> attribute being added to a session or requests. Then if a 'send
>> email' attribute comes through, the listener could process an email.
>> This seems like a bad idea though as I believe the listener event
>> class would be triggered incessantly any time attributes are
>> added/removed when in fact I'm only actually interested in the 'send
>> email' attribute.
>>
> My grain of salt :
> It basically depends on how often you expect this to happen (e.g. a new
> user registering), and the acceptable delay before the email is sent.
> I like very much the first idea (the database record and separate job),
> for its simplicity and robustness. It does not depend on any particular
> feature or library present in the servlet engine or the Java version, it
> does not even depend on the programming language used to write the
> email-sending job or the scheduling facilities available on the platform
> (think Windows vs Unix/Linux), it makes it easy in the future to change
> the email to something else, or add to it, or whatever. It makes it
> easy to split these tasks onto separate servers if the need arises
> (think that host/user-id which runs Tomcat may not be allowed to send
> emails; in most corporate environments, you need a "domain user" for that).
> It also makes it possible for the emailing job to collect in one single
> loop all recipients which need to receive an email, send them all at
> once, and warn the administrator and the sales people that 15 new
> customers just signed up.
>
Talking further to myself, I'll add that it also makes it easier to suspend/resume the
sending of emails separately if you need to for some reason, without having to change
anything to your running webapp.
I know, it is certainly less exciting than using consumer/producer patterns or Executor
classes.. sigh.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by André Warnier <aw...@ice-sa.com>.
Eric P wrote:
> Hi all,
>
> In my Tomcat app I'm looking for a good (or commonly used) method for
> firing off an asynchronous task. For example, a user registers for an
> account, and an a task to send a verification email to the user is
> triggered w/o delaying the response to the user (i.e., task happens in
> the background).
>
> I'm somewhat aware that JMS could be used for this and is part of most
> J2E environments, but I'd like to see if there's some way to pull this
> off w/vanilla Tomcat.
>
> I had a couple ideas that would probably work, but I'd like to see how
> others have solved this problem.
>
> One idea would be to insert a record into a database table that
> signifies an email should be sent to the user. This table could be
> regularly checked by a scheduled job (e.g., a TimerTask) that runs every
> minute in the background.
>
> Another (maybe not so good) idea would be to leverage perhaps a session
> or request attribute listener that would check for a certain attribute
> being added to a session or requests. Then if a 'send email' attribute
> comes through, the listener could process an email. This seems like a
> bad idea though as I believe the listener event class would be triggered
> incessantly any time attributes are added/removed when in fact I'm only
> actually interested in the 'send email' attribute.
>
My grain of salt :
It basically depends on how often you expect this to happen (e.g. a new user registering),
and the acceptable delay before the email is sent.
I like very much the first idea (the database record and separate job), for its simplicity
and robustness. It does not depend on any particular feature or library present in the
servlet engine or the Java version, it does not even depend on the programming language
used to write the email-sending job or the scheduling facilities available on the platform
(think Windows vs Unix/Linux), it makes it easy in the future to change the email to
something else, or add to it, or whatever. It makes it easy to split these tasks onto
separate servers if the need arises (think that host/user-id which runs Tomcat may not be
allowed to send emails; in most corporate environments, you need a "domain user" for that).
It also makes it possible for the emailing job to collect in one single loop all
recipients which need to receive an email, send them all at once, and warn the
administrator and the sales people that 15 new customers just signed up.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
On 07/22/2010 10:17 AM, Pid wrote:
>
> Have a look at Executors.class in java.util.concurrent. You can
> start/stop an ExecutorService in the init/destroy methods of your
> Servlet, submit a Runnable to the ExecutorService representing the
> job(s) you want to execute.
>
Timer / TimerTask might be an easier option.
Not to mention Quartz - but that would be an overkill I guess.
--
Mikolaj Rydzewski<mi...@ceti.pl>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Posted by Wesley Acheson <we...@gmail.com>.
This is very useful for me slightly different circumstance.
+1
On Thu, Jul 22, 2010 at 10:17 AM, Pid <pi...@pidster.com> wrote:
> On 22/07/2010 05:58, Eric P wrote:
> > Hi all,
> >
> > In my Tomcat app I'm looking for a good (or commonly used) method for
> > firing off an asynchronous task. For example, a user registers for an
> > account, and an a task to send a verification email to the user is
> > triggered w/o delaying the response to the user (i.e., task happens in
> > the background).
> >
> > I'm somewhat aware that JMS could be used for this and is part of most
> > J2E environments, but I'd like to see if there's some way to pull this
> > off w/vanilla Tomcat.
> >
> > I had a couple ideas that would probably work, but I'd like to see how
> > others have solved this problem.
> >
> > One idea would be to insert a record into a database table that
> > signifies an email should be sent to the user. This table could be
> > regularly checked by a scheduled job (e.g., a TimerTask) that runs every
> > minute in the background.
> >
> > Another (maybe not so good) idea would be to leverage perhaps a session
> > or request attribute listener that would check for a certain attribute
> > being added to a session or requests. Then if a 'send email' attribute
> > comes through, the listener could process an email. This seems like a
> > bad idea though as I believe the listener event class would be triggered
> > incessantly any time attributes are added/removed when in fact I'm only
> > actually interested in the 'send email' attribute.
> >
> > Anyway, I'm open to all ideas and appreciate you indulging me this far.
>
> You didn't say which version of Tomcat and JVM you're using, so I'll
> assume the latest - 6.0.28 and 1.6.
>
> Have a look at Executors.class in java.util.concurrent. You can
> start/stop an ExecutorService in the init/destroy methods of your
> Servlet, submit a Runnable to the ExecutorService representing the
> job(s) you want to execute.
>
>
> p
>
> > Eric P.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
>
Re: Fire off asynch task in Tomcat.
Posted by Pid <pi...@pidster.com>.
On 22/07/2010 05:58, Eric P wrote:
> Hi all,
>
> In my Tomcat app I'm looking for a good (or commonly used) method for
> firing off an asynchronous task. For example, a user registers for an
> account, and an a task to send a verification email to the user is
> triggered w/o delaying the response to the user (i.e., task happens in
> the background).
>
> I'm somewhat aware that JMS could be used for this and is part of most
> J2E environments, but I'd like to see if there's some way to pull this
> off w/vanilla Tomcat.
>
> I had a couple ideas that would probably work, but I'd like to see how
> others have solved this problem.
>
> One idea would be to insert a record into a database table that
> signifies an email should be sent to the user. This table could be
> regularly checked by a scheduled job (e.g., a TimerTask) that runs every
> minute in the background.
>
> Another (maybe not so good) idea would be to leverage perhaps a session
> or request attribute listener that would check for a certain attribute
> being added to a session or requests. Then if a 'send email' attribute
> comes through, the listener could process an email. This seems like a
> bad idea though as I believe the listener event class would be triggered
> incessantly any time attributes are added/removed when in fact I'm only
> actually interested in the 'send email' attribute.
>
> Anyway, I'm open to all ideas and appreciate you indulging me this far.
You didn't say which version of Tomcat and JVM you're using, so I'll
assume the latest - 6.0.28 and 1.6.
Have a look at Executors.class in java.util.concurrent. You can
start/stop an ExecutorService in the init/destroy methods of your
Servlet, submit a Runnable to the ExecutorService representing the
job(s) you want to execute.
p
> Eric P.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>