Sending Bulk Emails Error

i am working on a project in which we are sending email offers to thousand of users. i am using javax.mail package. The problem is that after sending some hundreds of mail, the page expires. Please help me.
Thanks in Advance

we're not here to help spammers...

Sending bulk email is a violation of the "be nice" rule. Sending it from JSPs or servlets is a bad idea (even if sending it at all was a good idea it would still be a bad idea).

Sir
Actually there are around thousand users registered into our shopping cart site. Customer wants us to send Email Offers to all customers registered with the site. what is the option to send email offers to all customers? sending one by one is not practical. Please help.

http://www.oop-reserch.com/scheduler.html
see if this helps you.

It is not a very good idea to send thousands of email to all registered users. A better way is to use banners or ads in the shopping cart site in a appealing way so that whenever a user visits the site, he/she can see the ad and proceed further based on their interest in the ad.

It's really not for us to define his business model.
If his job is to implement a mailer according to spec, that's what his job is.
Every bulk mailer is not a spam engine.

With any long running process, I recommend shelling out to a new process or thread and returning the user to a polling status page immediately.
The status page can use a meta refresh tag or Javascript to refresh every 5 or so seconds. With each refresh it checks a database field or session scoped variable to see if the job is done. If not, return the same page, if so return the "complete" page.

Originally posted by Ben Souther:
With each refresh it checks a database field or session scoped variable to see if the job is done. If not, return the same page, if so return the "complete" page.

That would mean that the user would to be stuck with that same page until the email is dispatched to thousands of users. Just curious to know if that is a good approach?

The sending should be done in a separate thread. No output is given to the useer directly, a logfile can be kept for checking on success or failure.

Typically the only one interested (unless you're indeed checking for failure rate of harvested addresses (aka spam) which you claim not to be doing) might be a process removing dead email addresses from the list.
As failing addresses would not be indicated by the sending process (given the nature of email) that would mean only a fatal crash of the sending process would be of interest, something that the person starting the process would be unlikely to be able to do anything about anyway.

In a previous job where I institued a bulk mailer for customers who had opted in (not spamming), I actually has the mail handled by a separate daemon program -- not within the web app itself.

The web app would allow the admin to set up the email to be sent, and it would enter the info into a DB. The mailer daemon would read that info and send the messages, updating the DB with its progress.

The admin could visit a status page to see what the state of the process was at any time or to review the sending history.

Originally posted by Sripathi Krishnamurthy:

That would mean that the user would to be stuck with that same page until the email is dispatched to thousands of users. Just curious to know if that is a good approach?

No, they should be able to navigate to any page you like and then come back to the status page or, leave the status page open (separate window) until it's done.