scalability of JMS on JBoss

[khristopher]

I'm developing a desktop client application that includes instant message functionality with other users. The end goal is for an application that supports millions of users online at the same time sending messages.

Would it be more scalable if I were to have each client use simple socket connections or JMS? Can you explain the reasons why?

How scalabe is JMS? How many topics/queues and users will it be able to support before performance is affected?

Thanks.

[genman]

If you have on Queue per user login, and 1,000,000 users are concurrently connected to JMS, JBoss will at least create one socket and thread per queue. Depending on your operating system and your machine, it might be okay. Or might not work at all.

If you're writing such an application, the first thing I would be to do would write a test harness.

Java historically has used the one-client-one-socket-one-thread processing model. The java.nio library allows you to write code that requires less threads. Theoretically, you could write a JMS system that used a thread processing pool that could handle a million JMS clients. This is not the design JBoss/JMS uses, however.

If you go with a load-balanced, multi-node configuration, JBoss/JMS doesn't have true load balancing yet.

[khristopher]

I think I remember hearing that the maximum number of socket connections on windows is around 2000 which is way too low for what I need.
Can someone explain why JBoss creates a new thread and socket for every connection? Wouldn't it be better to have all messages sent as data packets to the same socket and include some information on who sent the packet and which packets belong together? In this case the limiting factors would be bandwidth and how fast the server can process messages.
I'm looking at implementing my own solution with DatagramPackets now. A single thread can use one instance of DatagramSocket to receive packets from different clients.

[khristopher]

http://www.swiftmq.com/products/kernel/netnio/index.html

SwiftMQ provides the network nio swiftlet that "Uses only a few threads to handle thousands of concurrent connections." and "Provides scalability with no limits!"
I hope JBossMQ plans to provide something like this in the future.