Re: JMS vs Sockets -- bandwidth, size, speed, etc.
me2 wrote:
Has anyone compared JMS to socket programming? If I have N number of clients
that need to connect to and send messages to 1 server, what is the
comparison? I would guess that sockets--direct from a client to the server--
would be the fastest for speed and maybe take the least bandwidth. But I
would expect that
Beware expectations.
there would only be negligible size increases for the JMS overhead once the
connection was established and I would expect that a pub-sub topic would be
able to smoke through sending the N number of clients messages, rather than
loop through the connections/sockets and sending the message to each of them.
Apples vs. oranges.
JMS uses what under the hood?
Well, sometimes sockets but that depends. For certain processes you might
see in-memory transfers.
Or shared memory.
And how much speed do you need, and do you need it in development to get
correct operation, or at runtime to get wrong operation quicker?
How much time and money and aggravation are you willing to spend re-inventing
messaging?
Has anyone else looked at this? I'm going through the exercise to set up a
JMS server, but I thought maybe someone else could point me in the right
direction.
The only way to compare speed is to measure actual implementations.
And you might be measuring the wrong thing.
Plus, socket implementations can be very naive. NIO or threads?
Under what loads? How much competition for resources? With what latencies?
How much speed do you need? How much safety?
Who pays for support when there are problems?
How will it scale? How much does it even need to scale?
You've been asking the wrong questions for this stage, I'm advising.
--
Lew