Using tomcat with RMI

[abe1]

Hi, I need some advice in a system that I am trying to implement.

The system is a computerized survey with a client-server architecture with a database in the back end. Some of the requirements of the system are the following:
Users will use a client machine to log in to a remote server application that will return the questions of the survey.
The questions are sent to the client one by one. This is, when the user logs in, the server sends the first question, the user answers and the client sends the response back to the server. The server stores the answer in the database and sends the next question back to the client. This process is repeated until all the questions are answered.
The questions will be sent as java objects and will encapsulate some images. The answers of the client will be simple int.
At peak time I can have ~15000 users per hour taking the survey
My client application will be a java Swing application. For the server side I am still trying to decide:
I am considering using a java multithreaded server application and communicate with the swing client using RMI. I read that RMI is not very scalable because it does not reuse threads and because it does not have a way to define an upper limit in the number of threads that can be generated; this situation could make the server crash if I have many clients using the system at the same time (which will happen).

I am also considering using tomcat as my server application and have the swing application to connect to servlets that will return the question objects serialized. This option will use the multithreaded and session management capabilities of tomcat. However, I am not sure if I am adding to much overhead by using tomcat.

Does any body have some advice for me?

Thanks

 

[pfist]

Hey Abe,

It is difficult to see what the important issues are with your application. Although it wasn't you primary question, I find myself wondering why you decided create a client piece using swing. ( Is it where your background is from? ) I am wondering why a web browser can't be the client. With the many users you speak of, I would think you have some serious logistics problems with distribution/installation/maintanence of your swing client piece. Oh well, I guess that can be something to think about.

I can't be of help on the RMI question because I haven't had occasion to use it. Isn't an RMI a continuous connection much like a database connection? I would think there would be a massive connection problem on the server-side. (10k to 15k live connections, with memory allocated for each, all on one server???) I am not aware of any high capacity RMI servers being available.

As far as Tomcat being too much overhead, I am not sure that is the way to look at it. I believe Tomcat is capable of processing many hundreds of requests/responses per minute. ( Maybe 100 to 200 hundred per second on powerful machine and high bandwidth network ) Ask this question on a Tomcat forum to see how many requests others have been able to handle.

If you are going to have potentially 15,000 users at any one time with let's say maybe one request/response every 30 seconds, works out to 500 requests per second. That is very heavy traffic even for the top web sites of the internet. I suspect your worst case scenario would be much lower than this.

Note that a Tomcat solution would have anywhere from 3 to 12 database connections satisfying all the data persistence needs of the system.

I need to call it a night now. I hope I have been some help by thinking out loud.

Best Regards, pfist

 

[abelleon]

pfist,
Thank you for your comments.

A browser would not support the functionality that we required in the client side. Before answering the questions users will be able to highlight text, draw images, move some tools around, etc. We need a rich user interface and Swing provides this. Java applets would support this as well but we don't want to download the applet every time they take tests. We could also use Flash Remoting or any other GUI tool available but we decided on Swing for now.
When you use RMI, your client invokes a remote method in your server, the server executes the code in that method and returns results to the client. At that point the connection is released. To support my application I would need to develop a multithreaded server application in order to support all the clients calling the same methods.
Tomcat already has this multithreaded capabilities and that’s one of the main reason we already decided to use it.
Tomcat seems to handle around 80 requests per second, which would be ok for the first releases of my application. For future releases I might need to use more than 1 server or move to another application container (Jrun seems to handle more requests per second)

Thanks again for your comments

 

[pfist]

I have been impressed with Tomcat. I expect you will find it will serve your needs in many ways.

A few ideas.

1) From jakarta.apache.org you might find the Commons Httpclient useful. It provides a java API and full implementation for dealing with the http protocol. I have used it to negotiate web servers and secure web servers in order to extract data. It might be the means by which your client interfaces with your web server.

2) Better yet, web services is the big thing now. You might want to take a look at AXIS.

http://xml.apache.org/axis/index.html

I have been reading about it but haven't had chance to use it. This could provide a ready made protocol on top of http for passing xml messages back and forth between client and web server. I believe they have a war file that you can drop into Tomcat /webapps dir and play with quickly. It uses SAX parser so it is fast. I assume there is a client.jar that you would add to the client.

3) If you are dealing with many many concurrent sessions, you might want to minimize the number of objects that you store in your session scope. For each session, try to make memory footprint as small as possible, so that memory overflow problems are less likely. I don't think you want to have the web server be completely stateless, in other words, instead of creating your own, I would think you want to use session functionality already provided by Tomcat, but only have it keep track of where user is in survey. Keep the bare minimum of information in the session object. Send all state directly/immediately to the database.

4) Check out the servlet 2.3 specification. There are serveral Session Listener APIs that you probably want to become familiar with. e.g. HttpSessionBindingListener, HttpSessionActivationListener

Best Regards, pfist

 

[abelleon]

1)Commons Httpclient useful.
Great! I was going to use the java.net classes, but this libraries will do a better job.

2)Better yet, web services is the big thing now. You might want to take a look at AXIS.

http://xml.apache.org/axis/index.html

I compared apache SOAP and object serialization before and serilization gives you a much better performance. I can see many cases in which AXIS would be a better option, but for my application performance is the big issue, and we will serialize objects and send them to the client Swing application.

3)Regargding the session scope,
we will do what you mention, we plan to keep very, very minimal session information in the server.

Thanks again
abel