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.

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.)

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.