Re: Control flow design question
Robert Klemme wrote:
On 22.06.2009 15:05, Eric Sosman wrote:
JannaB wrote:
I have a sockets server, listening on a single port for connections of
from 1 to 400 different terminals on the internet.
These terminals are grouped into what I call "channels." That is,
terminal 1,5 and 119 may be all from channel "A."
I only want to process 1 channel at a time. In other words, if I get a
signal from terminal 5, and one from 119, the latter must wait until
the former is processed. (Incidentally, I don;t write out from the
sockets server, rather, it writes some JSON data that is ultimately
transmitted back to the appropriate channel terminals).
Each connection to my sockets server will be making some JDBC inserts
and undates.
I am wondering, structurally, how best to handle this, realising that
archtiectural questions such as this are best handled properly from
the outset. Thank you, Janna B.
My first thought would be to use a different incoming
socket for connections on each channel, then write what
amounts to an ordinary single-threaded one-request-at-a-time
server for each channel's socket. But if you've got to use
the same IP/port for all the clients, that won't work.
That does not exactly meet the requirement as stated above: OP said that
he wanted to process only one channel at a time. It may be though that
he meant that he wants to process only one event at a time _per channel_.
The latter is the meaning I took, in light of the "In other
words ..." in the original post. At any rate, a follow-up by the
O.P. seemed content with the approach.
Another approach would be to maintain N queues of requests,
one for each channel. A single thread accepts incoming
requests on the single port, figures out which channel each
belongs to, and appends each request to its channel's queue.
Each queue's requests are processed by one dedicated worker
thread.
Yep. That would be my favorite although I have no idea how the channel
is obtained from the connection.
Neither do I, since the O.P. didn't explain it. The means
seem unimportant, though, as long as there's *some* way to assign
requests to channels (if there's not, the entire exercise goes
up in smoke ...)
A disadvantage of the second approach is that it forces
you to have the same number of worker threads as channels,
which might not be convenient (the one-request-per-channel
requirement means you can't have *more* workers than channels,
but if the channel count is large compared to the "CPU count"
you might well want to have fewer). Instead, you could have
N queues as above but just M worker threads: A worker finds
the queue with the oldest (or highest-priority) request at
the front and processes that request, but during the processing
it marks the queue "ineligible" so no other worker will look
at it. When the queue's first request is completed, the queue
becomes "eligible" again and the worker repeats its cycle.
In that case I'd rather have M queues and M workers and put something
into the event that is enqueued which allows detection of the channel.
Then place events for multiple channels in one queue.
If I understand you, requests would be sprayed across all M
queues and thus be eligible for processing by any of the M workers.
But if worker W1 is processing a request from channel A, worker W2
must not start work on another channel A request until W1 finishes.
Also, if it is important to process A's requests in the order they
arrived or in order by their priorities (the O.P. didn't address
the matter, but an ordering discipline of some kind is often wanted),
spraying A's events across multiple queues will make it harder
to keep their relative order intact.
At any rate, it seems we've given the O.P. sufficient food
for thought.
--
Eric.Sosman@sun.com