Hi,

We want to design java chat servet that can support 5000-10000 concurrent connection.

What factor need to consider?

Do we need to using EJB?

Thanks
John

Best thing to consider is if you really want to do it at all. If you're looking at developing a product for sale, then obviously you'll want your question answered, but if all you want is a Java product for doing chat over a web site, check out DigiChat (http://www.digichat.com). They do both hosted and roll-your-own solutions. We've been using them for all of our sites for years and have had no problems.

Of course, given how badly Microsoft has borked Java Applets in XP, DigiChat requires all users to download the Sun java Plugin. For me (and you), this is problem already done... but for the average joe six-pack this is a huge ordeal.

That said... you might want to look into Flash based chat instead... it's a little more reliable browser to browser these days.

We want to design java chat servet that can support 5000-10000 concurrent connection.

If those are TCP/IP connections (particularly for a single server,) that will be a lot of connections to support. You'll definitely want to look at the NIO features, and especially Mike Spille's writings on it.

If you need to cluster it, take a look at Coherence. In fact, Jive Software used Coherence to do just that.

Do we need to using EJB?

Personally, I would avoid it for a chat server.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

I will assume it has nothing to do with applets, unlike the other reply.
I will suppose you want to generate gifs or png images server side.

First, be realist:
Java servlet container do not easily sustain 5000 concurrent connections, because the servlet model rely on threads.

If you get out of the servlet model to an asynchronous i/o dedicated http stack, you 'might' get this performance, but you would serialize your requests and chart generation anyway so you don't exceed 200 threads at anytime (limit context switching).
Try Sandstorm (SEDA) 'Haboob' http server.

Second, think about memory: offscreen images required to generate file images will probably suck memory, depending on the image size. Also figure out if you want in-memory buffering of this image, or disk buffering, in which case you will need very good r/w disk i/o for that much concurrent queries.

Third, about queries: a chart server is about representing data. Either you received simple data from the request, or you query a DB, in which case your bottleneck isn't anymore the image generation but the data retreival (DB connections).

Fourth, If number of threads is critical, aim for NPTL in linux (new or native ? posix thread library, which scales much better).

Finally, it is always good to think about load-balancing among many servers. Start with dual or quad CPU. Then split the work on many servers (but that is another topic I cannot help on.)

...not CHART.

SCNR,

René Zanner

Oops...
A chat server is so trivial, subconsciously I wanted to help on the more challenging chart servlet (a far more complex topic).
Sorry.

But, you also wrote 'servet', which is misleading to servlet...
Anyway, all the comments about threads are still true: seda, nio, ntpl...