The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Simple Ajax for J2EE application and long running processes

I always think of ajax as for projects like this:

I want to have a simple servlet and have it launch a large set of emails (say 100,000) that must be delayed a minute every 200 emails or so.  Basically the request will take a very long time and from a servlet.

I want to be able to have the client updated for every 200 or so emails.

1. This batch was sent
2. This batch was sent...etc

Ajax would be perfect for this.  The only thing.  it seems like an ajax client still has to prompt the server for data.  How does the server prompt the client?

I am assuming that I need to use some kind of javascript timing functions that on every 10 seconds or so; poll the server?

Project 2:

I also would like to have a simple project that reads Tomcat log files from an ajax application.  And when the logs change, update the ajax based client.

What are the approaches for these?
Bot Berlin
Thursday, December 07, 2006
The easiest way is just to have a javascript timer send a request to the server every n seconds.

Ajax doesn't really change anything in the fundamental way the web works. Clients request data from a server - all Ajax does is make the data a part of a page not the whole page.

Server push is possible but generally doesn't work too well.
Martin Send private email
Thursday, December 07, 2006
Are you a spammer?
Full name
Thursday, December 07, 2006
I assumed he just had lots of friends to send christmas (hanukah/kwanza/pagan-mid-winter-festival) messages to.
Martin Send private email
Thursday, December 07, 2006
No, an internal project for our users.
Bot Berlin
Thursday, December 07, 2006
I have been thinking about this, and I'm stumped - I think AJAX only supports the client pull paradigm and you can't have the server reliably push to the client for the simple matter that there's no AJAX "listener" accepting any and all connections.

Having said that, if you mean by "internal", you mean within the confines of a company network, then your mail administrator will probably want you to do some sort of carbon copy instead of sending 100,000 individual letters. If you broke them down into 25 groups of roughly 4,000 people each, that's a lot easier for the email infrastructure to handle. (Each group can represent a letter of the alphabet, so to speak.)

If you have 25 batches, you can organize them into fake parallel threads, and simply have the client poll to see which mock-threads are complete.

I need to think the idea through more because I don't think it solves the real problem, but it can make it a lot easier to deal with or otherwise eliminate the "long running" part of it.
Thursday, December 07, 2006
Nevermind, I missed the original problem "requirement" that only 200 emails are sent at a time. :)
Thursday, December 07, 2006
I would separate out the action from notification.

There is a push paradigm for AJAX called Commet (
so you could push status to the interface.

I wouldn't use a servlet to send the email. I would use a data approach to handle failures cleanly. The servlet notifies a service that persistently schedules the operation. It uses cron or whatever to wake up, do the operation, and write the status to central store. You poll the central store for the current status, or work up an event for notification, and then push that to the web interface.

For long lived operations you don't want to rely on the servlet context because it may fail and you'll duplicate the email sends when the operation restarts.
son of parnas
Friday, December 08, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz