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