You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Shyam A <st...@yahoo.com> on 2003/12/04 18:08:39 UTC
[OT] Mailing large number of recipients
Hi,
I have a Struts application in which I need to send
email notification to a large number of recipients
based on a user action. Currently, I use the Java Mail
API and send emails from my application. I use a
single email with all recipients in the "BCC" field.
Although, this approach works reasonably well for
small numbers (around 100), it doesn't seem suitable
for mailing very large number of recipients (in the
order of 1000's). I'm not sure if the mailing process
can be done at the backend with Oracle 9i database,
using a stored procedure or a trigger.
Any ideas/suggestions/pointers will be greatly
appreciated.
Thanks,
Shyam
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Brice Ruth <br...@fiskars.com>.
Cool, thanks for clearing that up - your explanation is very good :)
Kirk Wylie wrote:
> Brice Ruth wrote:
>
>> I was under the impression that creating threads from within a web
>> application was a relatively big no-no ... I seem to remember reading in
>> my J2EE book it talking about their being an implicit contract between
>> the the application and the container that no add'l threads would be
>> created, so that the container can manage distributing the
>> application, etc.
>
>
> Correct. It's one of those things that you're not supposed to do, and
> there are certain contexts (such as within EJB methods) where it can
> lead to really bad outcomes. You also have to make REALLY sure that
> you NEVER use anything that's controlled by the servlet container in
> that thread: in other words, use pure DAOs and primitives to pass
> information into the subordinate thread, rather than passing around
> the PageContext or something). But it's not specifically outlawed by
> the specifications, and so it will actually function on every servlet
> container that I've run across up until now (though I've not worked
> with some of the fringe containers).
>
> That's why I'm saying that doing it is probably a Bad Idea, but it's
> the fastest way to get the functionality that he wants. I'd recommend
> using JMS for this, becuase it's what it's designed for. But if he has
> non-JMS requirements (i.e. no J2EE application server, just a servlet
> container), then the thread-creation business should work.
>
> Of course, as always, YMMV.
>
> Kirk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Kirk Wylie <kw...@m7.com>.
Brice Ruth wrote:
> I was under the impression that creating threads from within a web
> application was a relatively big no-no ... I seem to remember reading in
> my J2EE book it talking about their being an implicit contract between
> the the application and the container that no add'l threads would be
> created, so that the container can manage distributing the application,
> etc.
Correct. It's one of those things that you're not supposed to do, and
there are certain contexts (such as within EJB methods) where it can
lead to really bad outcomes. You also have to make REALLY sure that you
NEVER use anything that's controlled by the servlet container in that
thread: in other words, use pure DAOs and primitives to pass information
into the subordinate thread, rather than passing around the PageContext
or something). But it's not specifically outlawed by the specifications,
and so it will actually function on every servlet container that I've
run across up until now (though I've not worked with some of the fringe
containers).
That's why I'm saying that doing it is probably a Bad Idea, but it's the
fastest way to get the functionality that he wants. I'd recommend using
JMS for this, becuase it's what it's designed for. But if he has non-JMS
requirements (i.e. no J2EE application server, just a servlet
container), then the thread-creation business should work.
Of course, as always, YMMV.
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Brice Ruth <br...@fiskars.com>.
I was under the impression that creating threads from within a web
application was a relatively big no-no ... I seem to remember reading in
my J2EE book it talking about their being an implicit contract between
the the application and the container that no add'l threads would be
created, so that the container can manage distributing the application, etc.
Kirk Wylie wrote:
> Shyam A wrote:
>
>> Hi,
>>
>> I have a Struts application in which I need to send
>> email notification to a large number of recipients
>> based on a user action. Currently, I use the Java Mail
>> API and send emails from my application. I use a
>> single email with all recipients in the "BCC" field.
>>
>> Although, this approach works reasonably well for
>> small numbers (around 100), it doesn't seem suitable
>> for mailing very large number of recipients (in the
>> order of 1000's). I'm not sure if the mailing process
>> can be done at the backend with Oracle 9i database,
>> using a stored procedure or a trigger.
>
>
> What specifically is taking a long time? Is it the generation of the
> email, or its sending? Because most email servers should make sending
> such a message quite quick as they're doing the actual caching and
> sending to multiple recipients.
>
> But in general, you might look into JMS for this type of thing (i.e.
> some way to "background process" an operation), since it's the
> standard J2EE way to do asynchronous event management like this.
>
> An alternative which is a little messier, but is probably quicker to
> do, is to have a thread-based operation which you kick off in your
> Action class immediately before returning from execute(...). It would
> then create and send the email. In this case you would return control
> to the user (who's the one who caused the mass email to kick off)
> immediately, and background-process the emails. The major problems
> here are:
> 1) There are "better" ways to do this (i.e. JMS and/or message driven
> beans)
> 2) You're potentially creating a large number of threads if this is
> happening on a regular basis. But if it is, that's even more reason to
> use JMS or a commercial bulk emailing system (where bulk != spam)
> 3) You can't provide immediate feedback to the user about the status
> of the mail job because it's happening in the background.
> 4) Because it's not transactional (unlike JMS), you might "lose" the
> email if there's a failure.
>
> Kirk Wylie
> M7 Corporation
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Brice Ruth <br...@fiskars.com>.
So, to clarify - is the mail-sending slow waiting for the mail server to
return with a 250 - OK response, or is creating the mail message to send
(with all the BCC: addresses), before sending it over to the server,
slow? The point being - in theory, the mail server should bear the brunt
of the time of sending the message out to the recipients, unless it is
hanging on to the connection you've opened, until it has sent to all
recipients, before returning with the 250-OK message, indicating that
everything was successful.
If that's the case, you might consider sending through a different SMTP
server, one that doesn't block on that ... and just accepts the message
for delivery instantaneously.
Shyam A wrote:
>Kirk,
>
>Thanks a lot for your suggestions. I will look into
>JMS.
>In my current approach, the process of sending the
>mail is time consuming.I'm concerned that sending an
>email to 1000's of recipients from my application
>(using JMS, Thread etc) would clog my application
>server (OC4J) and slow down its operation, which is
>why I was wondering if it could be done at the
>backend-Oracle 9i.
>
>Thanks,
>Shyam
>
>--- Kirk Wylie <kw...@m7.com> wrote:
>
>
>>Shyam A wrote:
>>
>>
>>
>>>Hi,
>>>
>>>I have a Struts application in which I need to
>>>
>>>
>>send
>>
>>
>>>email notification to a large number of recipients
>>>based on a user action. Currently, I use the Java
>>>
>>>
>>Mail
>>
>>
>>>API and send emails from my application. I use a
>>>single email with all recipients in the "BCC"
>>>
>>>
>>field.
>>
>>
>>>Although, this approach works reasonably well for
>>>small numbers (around 100), it doesn't seem
>>>
>>>
>>suitable
>>
>>
>>>for mailing very large number of recipients (in
>>>
>>>
>>the
>>
>>
>>>order of 1000's). I'm not sure if the mailing
>>>
>>>
>>process
>>
>>
>>>can be done at the backend with Oracle 9i
>>>
>>>
>>database,
>>
>>
>>>using a stored procedure or a trigger.
>>>
>>>
>>What specifically is taking a long time? Is it the
>>generation of the
>>email, or its sending? Because most email servers
>>should make sending
>>such a message quite quick as they're doing the
>>actual caching and
>>sending to multiple recipients.
>>
>>But in general, you might look into JMS for this
>>type of thing (i.e.
>>some way to "background process" an operation),
>>since it's the standard
>>J2EE way to do asynchronous event management like
>>this.
>>
>>An alternative which is a little messier, but is
>>probably quicker to do,
>>is to have a thread-based operation which you kick
>>off in your Action
>>class immediately before returning from
>>execute(...). It would then
>>create and send the email. In this case you would
>>return control to the
>>user (who's the one who caused the mass email to
>>kick off) immediately,
>>and background-process the emails. The major
>>problems here are:
>>1) There are "better" ways to do this (i.e. JMS
>>and/or message driven beans)
>>2) You're potentially creating a large number of
>>threads if this is
>>happening on a regular basis. But if it is, that's
>>even more reason to
>>use JMS or a commercial bulk emailing system (where
>>bulk != spam)
>>3) You can't provide immediate feedback to the user
>>about the status of
>>the mail job because it's happening in the
>>background.
>>4) Because it's not transactional (unlike JMS), you
>>might "lose" the
>>email if there's a failure.
>>
>>Kirk Wylie
>>M7 Corporation
>>
>>
>>
>>
>>
>---------------------------------------------------------------------
>
>
>>To unsubscribe, e-mail:
>>struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
>>struts-user-help@jakarta.apache.org
>>
>>
>>
>
>
>__________________________________
>Do you Yahoo!?
>Free Pop-Up Blocker - Get it now
>http://companion.yahoo.com/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
--
Brice D. Ruth
Sr. IT Analyst
Fiskars Brands, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Kirk Wylie <kw...@m7.com>.
Colin Kilburn wrote:
> my $0.02:
>
> Back in my perl days ;-), on a crappy server I would have simply sent
> bulk emails in bursts, such as 5 at a time with a second sleep in
> between. This was the difference between 90%cpu usage to an
> unnoticeable blip. While it's not ideal, if you can get the process
> into the background, server load doesn't have to be an issue.
This is what something like Postfix does. I've had a lot of luck with
its built-in throttling capabilities, and it's all very configurable
(and very comprehensibly configurable, unlike some of its major
alternatives) in terms of its throttling. Has support for things like
controlling how many batch emails it sends to any given server at a
time, how many emails it will send out a minute, stuff like that. I've
never been able to overload a Postfix installation, but then again I've
not been in the bulk emailing game. :-)
Now we're definitely OT.
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Colin Kilburn <co...@accesstec.ca>.
my $0.02:
Back in my perl days ;-), on a crappy server I would have simply sent
bulk emails in bursts, such as 5 at a time with a second sleep in
between. This was the difference between 90%cpu usage to an
unnoticeable blip. While it's not ideal, if you can get the process
into the background, server load doesn't have to be an issue.
Colin
Shyam A wrote:
>Kirk,
>
>Thanks a lot for your suggestions. I will look into
>JMS.
>In my current approach, the process of sending the
>mail is time consuming.I'm concerned that sending an
>email to 1000's of recipients from my application
>(using JMS, Thread etc) would clog my application
>server (OC4J) and slow down its operation, which is
>why I was wondering if it could be done at the
>backend-Oracle 9i.
>
>Thanks,
>Shyam
>
>--- Kirk Wylie <kw...@m7.com> wrote:
>
>
>>Shyam A wrote:
>>
>>
>>
>>>Hi,
>>>
>>>I have a Struts application in which I need to
>>>
>>>
>>send
>>
>>
>>>email notification to a large number of recipients
>>>based on a user action. Currently, I use the Java
>>>
>>>
>>Mail
>>
>>
>>>API and send emails from my application. I use a
>>>single email with all recipients in the "BCC"
>>>
>>>
>>field.
>>
>>
>>>Although, this approach works reasonably well for
>>>small numbers (around 100), it doesn't seem
>>>
>>>
>>suitable
>>
>>
>>>for mailing very large number of recipients (in
>>>
>>>
>>the
>>
>>
>>>order of 1000's). I'm not sure if the mailing
>>>
>>>
>>process
>>
>>
>>>can be done at the backend with Oracle 9i
>>>
>>>
>>database,
>>
>>
>>>using a stored procedure or a trigger.
>>>
>>>
>>What specifically is taking a long time? Is it the
>>generation of the
>>email, or its sending? Because most email servers
>>should make sending
>>such a message quite quick as they're doing the
>>actual caching and
>>sending to multiple recipients.
>>
>>But in general, you might look into JMS for this
>>type of thing (i.e.
>>some way to "background process" an operation),
>>since it's the standard
>>J2EE way to do asynchronous event management like
>>this.
>>
>>An alternative which is a little messier, but is
>>probably quicker to do,
>>is to have a thread-based operation which you kick
>>off in your Action
>>class immediately before returning from
>>execute(...). It would then
>>create and send the email. In this case you would
>>return control to the
>>user (who's the one who caused the mass email to
>>kick off) immediately,
>>and background-process the emails. The major
>>problems here are:
>>1) There are "better" ways to do this (i.e. JMS
>>and/or message driven beans)
>>2) You're potentially creating a large number of
>>threads if this is
>>happening on a regular basis. But if it is, that's
>>even more reason to
>>use JMS or a commercial bulk emailing system (where
>>bulk != spam)
>>3) You can't provide immediate feedback to the user
>>about the status of
>>the mail job because it's happening in the
>>background.
>>4) Because it's not transactional (unlike JMS), you
>>might "lose" the
>>email if there's a failure.
>>
>>Kirk Wylie
>>M7 Corporation
>>
>>
>>
>>
>>
>---------------------------------------------------------------------
>
>
>>To unsubscribe, e-mail:
>>struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
>>struts-user-help@jakarta.apache.org
>>
>>
>>
>
>
>__________________________________
>Do you Yahoo!?
>Free Pop-Up Blocker - Get it now
>http://companion.yahoo.com/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Shyam A <st...@yahoo.com>:
> Kirk,
>
> Thanks a lot for your suggestions. I will look into
> JMS.
> In my current approach, the process of sending the
> mail is time consuming.I'm concerned that sending an
> email to 1000's of recipients from my application
> (using JMS, Thread etc) would clog my application
> server (OC4J) and slow down its operation, which is
> why I was wondering if it could be done at the
> backend-Oracle 9i.
>
Would it not be simpler to set up a mailing list application on your mail
server, so you only have to send the message to a single recipient address
(pretty much the way the struts-user mailing list works)? This would also
relieve you of the burden of having to change your application every time the
list of recipients changs.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Shyam A <st...@yahoo.com>.
Kirk, Brice and Elio,
Thanks a lot for pointing me in the right direction. I
really appreciate it!
Shyam
--- Kirk Wylie <kw...@m7.com> wrote:
> Shyam A wrote:
>
> > Kirk,
> >
> > Thanks a lot for your suggestions. I will look
> into
> > JMS.
> > In my current approach, the process of sending the
> > mail is time consuming.I'm concerned that sending
> an
> > email to 1000's of recipients from my application
> > (using JMS, Thread etc) would clog my application
> > server (OC4J) and slow down its operation, which
> is
> > why I was wondering if it could be done at the
> > backend-Oracle 9i.
>
> No doubt, there's a way to do it using PL/SQL or
> some type of
> server-side Java in O9i, but then we're getting so
> far OT that I
> wouldn't have the first idea on how you would do
> that.
>
> But using something like JMS would actually allow
> much better
> scalability on your application as a whole:
> 1) The DB is usually the most overloaded part of a
> major application,
> and your DBAs will probably be MOST unhappy if they
> find out you're
> sending bulk email on your database server.
> 2) If you start overloading the database server, the
> whole application
> will slow down anyway, as well as any other
> applications running on the
> database server. Not such a great idea.
> 3) The application server tier is much more
> "naturally" horizontally
> scalable, meaning it's easier to setup a horizontal
> cluster of idential
> application server nodes (either in a true cluster
> or just as a
> load-balanced farm).
> 4) If you really have this one problem (which is
> that this one task is
> really computational), JMS is the way to go, because
> you can setup a
> separate application server instance with ONLY that
> queue processing
> ocurring on it and thus offload all the work from
> the rest of the system.
>
> #4 is the kicker with the JMS approach. In essence
> you're creating a
> mail server (har har) which only does this one task.
>
> But I think that Brice has the right idea here: it
> sounds like what you
> really need is a better email server. There's no
> excuse for a mail
> server that isn't horribly overburdened or remote
> taking a long time to
> respond to a large batch email like this. If yours
> is (perhaps because
> you're using your corporate email server as a bulk
> SMTP gateway), ask
> your IT staff if you can setup a postfix (my
> favorite for this stuff) or
> sendmail system on a cheap Linux box to do SMTP
> gateway for you, because
> they'll handle this without even a murmur.
>
> Kirk Wylie
> M7 Corporation
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Kirk Wylie <kw...@m7.com>.
Shyam A wrote:
> Kirk,
>
> Thanks a lot for your suggestions. I will look into
> JMS.
> In my current approach, the process of sending the
> mail is time consuming.I'm concerned that sending an
> email to 1000's of recipients from my application
> (using JMS, Thread etc) would clog my application
> server (OC4J) and slow down its operation, which is
> why I was wondering if it could be done at the
> backend-Oracle 9i.
No doubt, there's a way to do it using PL/SQL or some type of
server-side Java in O9i, but then we're getting so far OT that I
wouldn't have the first idea on how you would do that.
But using something like JMS would actually allow much better
scalability on your application as a whole:
1) The DB is usually the most overloaded part of a major application,
and your DBAs will probably be MOST unhappy if they find out you're
sending bulk email on your database server.
2) If you start overloading the database server, the whole application
will slow down anyway, as well as any other applications running on the
database server. Not such a great idea.
3) The application server tier is much more "naturally" horizontally
scalable, meaning it's easier to setup a horizontal cluster of idential
application server nodes (either in a true cluster or just as a
load-balanced farm).
4) If you really have this one problem (which is that this one task is
really computational), JMS is the way to go, because you can setup a
separate application server instance with ONLY that queue processing
ocurring on it and thus offload all the work from the rest of the system.
#4 is the kicker with the JMS approach. In essence you're creating a
mail server (har har) which only does this one task.
But I think that Brice has the right idea here: it sounds like what you
really need is a better email server. There's no excuse for a mail
server that isn't horribly overburdened or remote taking a long time to
respond to a large batch email like this. If yours is (perhaps because
you're using your corporate email server as a bulk SMTP gateway), ask
your IT staff if you can setup a postfix (my favorite for this stuff) or
sendmail system on a cheap Linux box to do SMTP gateway for you, because
they'll handle this without even a murmur.
Kirk Wylie
M7 Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: [OT] Mailing large number of recipients
Posted by Elio Bonazzi <eb...@capecomputing.com>.
You could look into Oracle Advanced Queuing. It is basically a queueing
mechanism implemented inside the database. There is also a JMS interface to
it. The mass e-mail job could be performed by another process running on a
different machine from the Web server. I don't recall the license
arrangements for Advanced Queueing - it could be part of the Enterprise
license for Oracle. So if you don't have Oracle Enterprise Edition you
probably have to pay a license for it. Just do your homework; it is worth
looking at Advanced Queueing in your case.
Elio
-----Original Message-----
From: Shyam A [mailto:struts_newbie@yahoo.com]
Sent: Thursday, December 04, 2003 1:05 PM
To: Struts Users Mailing List
Subject: Re: [OT] Mailing large number of recipients
Kirk,
Thanks a lot for your suggestions. I will look into
JMS.
In my current approach, the process of sending the
mail is time consuming.I'm concerned that sending an
email to 1000's of recipients from my application
(using JMS, Thread etc) would clog my application
server (OC4J) and slow down its operation, which is
why I was wondering if it could be done at the
backend-Oracle 9i.
Thanks,
Shyam
--- Kirk Wylie <kw...@m7.com> wrote:
> Shyam A wrote:
>
> > Hi,
> >
> > I have a Struts application in which I need to
> send
> > email notification to a large number of recipients
> > based on a user action. Currently, I use the Java
> Mail
> > API and send emails from my application. I use a
> > single email with all recipients in the "BCC"
> field.
> >
> > Although, this approach works reasonably well for
> > small numbers (around 100), it doesn't seem
> suitable
> > for mailing very large number of recipients (in
> the
> > order of 1000's). I'm not sure if the mailing
> process
> > can be done at the backend with Oracle 9i
> database,
> > using a stored procedure or a trigger.
>
> What specifically is taking a long time? Is it the
> generation of the
> email, or its sending? Because most email servers
> should make sending
> such a message quite quick as they're doing the
> actual caching and
> sending to multiple recipients.
>
> But in general, you might look into JMS for this
> type of thing (i.e.
> some way to "background process" an operation),
> since it's the standard
> J2EE way to do asynchronous event management like
> this.
>
> An alternative which is a little messier, but is
> probably quicker to do,
> is to have a thread-based operation which you kick
> off in your Action
> class immediately before returning from
> execute(...). It would then
> create and send the email. In this case you would
> return control to the
> user (who's the one who caused the mass email to
> kick off) immediately,
> and background-process the emails. The major
> problems here are:
> 1) There are "better" ways to do this (i.e. JMS
> and/or message driven beans)
> 2) You're potentially creating a large number of
> threads if this is
> happening on a regular basis. But if it is, that's
> even more reason to
> use JMS or a commercial bulk emailing system (where
> bulk != spam)
> 3) You can't provide immediate feedback to the user
> about the status of
> the mail job because it's happening in the
> background.
> 4) Because it's not transactional (unlike JMS), you
> might "lose" the
> email if there's a failure.
>
> Kirk Wylie
> M7 Corporation
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Shyam A <st...@yahoo.com>.
Kirk,
Thanks a lot for your suggestions. I will look into
JMS.
In my current approach, the process of sending the
mail is time consuming.I'm concerned that sending an
email to 1000's of recipients from my application
(using JMS, Thread etc) would clog my application
server (OC4J) and slow down its operation, which is
why I was wondering if it could be done at the
backend-Oracle 9i.
Thanks,
Shyam
--- Kirk Wylie <kw...@m7.com> wrote:
> Shyam A wrote:
>
> > Hi,
> >
> > I have a Struts application in which I need to
> send
> > email notification to a large number of recipients
> > based on a user action. Currently, I use the Java
> Mail
> > API and send emails from my application. I use a
> > single email with all recipients in the "BCC"
> field.
> >
> > Although, this approach works reasonably well for
> > small numbers (around 100), it doesn't seem
> suitable
> > for mailing very large number of recipients (in
> the
> > order of 1000's). I'm not sure if the mailing
> process
> > can be done at the backend with Oracle 9i
> database,
> > using a stored procedure or a trigger.
>
> What specifically is taking a long time? Is it the
> generation of the
> email, or its sending? Because most email servers
> should make sending
> such a message quite quick as they're doing the
> actual caching and
> sending to multiple recipients.
>
> But in general, you might look into JMS for this
> type of thing (i.e.
> some way to "background process" an operation),
> since it's the standard
> J2EE way to do asynchronous event management like
> this.
>
> An alternative which is a little messier, but is
> probably quicker to do,
> is to have a thread-based operation which you kick
> off in your Action
> class immediately before returning from
> execute(...). It would then
> create and send the email. In this case you would
> return control to the
> user (who's the one who caused the mass email to
> kick off) immediately,
> and background-process the emails. The major
> problems here are:
> 1) There are "better" ways to do this (i.e. JMS
> and/or message driven beans)
> 2) You're potentially creating a large number of
> threads if this is
> happening on a regular basis. But if it is, that's
> even more reason to
> use JMS or a commercial bulk emailing system (where
> bulk != spam)
> 3) You can't provide immediate feedback to the user
> about the status of
> the mail job because it's happening in the
> background.
> 4) Because it's not transactional (unlike JMS), you
> might "lose" the
> email if there's a failure.
>
> Kirk Wylie
> M7 Corporation
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Mailing large number of recipients
Posted by Kirk Wylie <kw...@m7.com>.
Shyam A wrote:
> Hi,
>
> I have a Struts application in which I need to send
> email notification to a large number of recipients
> based on a user action. Currently, I use the Java Mail
> API and send emails from my application. I use a
> single email with all recipients in the "BCC" field.
>
> Although, this approach works reasonably well for
> small numbers (around 100), it doesn't seem suitable
> for mailing very large number of recipients (in the
> order of 1000's). I'm not sure if the mailing process
> can be done at the backend with Oracle 9i database,
> using a stored procedure or a trigger.
What specifically is taking a long time? Is it the generation of the
email, or its sending? Because most email servers should make sending
such a message quite quick as they're doing the actual caching and
sending to multiple recipients.
But in general, you might look into JMS for this type of thing (i.e.
some way to "background process" an operation), since it's the standard
J2EE way to do asynchronous event management like this.
An alternative which is a little messier, but is probably quicker to do,
is to have a thread-based operation which you kick off in your Action
class immediately before returning from execute(...). It would then
create and send the email. In this case you would return control to the
user (who's the one who caused the mass email to kick off) immediately,
and background-process the emails. The major problems here are:
1) There are "better" ways to do this (i.e. JMS and/or message driven beans)
2) You're potentially creating a large number of threads if this is
happening on a regular basis. But if it is, that's even more reason to
use JMS or a commercial bulk emailing system (where bulk != spam)
3) You can't provide immediate feedback to the user about the status of
the mail job because it's happening in the background.
4) Because it's not transactional (unlike JMS), you might "lose" the
email if there's a failure.
Kirk Wylie
M7 Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: [OT] Mailing large number of recipients
Posted by Sandra Cann <sc...@jcorporate.com>.
You might look at using eForum (open source) at www.jcorporate.com. In
addition to handling discussion forums it can also be used for one way out
going emails. As a discussion forum, expresso's user forum has 3245
subscribers which has numerous postings each day. As announcement forums
Expresso News has 9K, and general new has 16K+ subscribers. eForum handles
nicely; and with recent releases quickly. Also the last revision has
integration with Lucene for search.
Alternatively one of our Expresso community members has built an opt-in mail
system - which is closer to what you are describing, If you are interested
contact me off-list and I will put you in touch with them.
Sandra
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org