that authentication is processed on the dobjmgr thread rather than
requiring the caller to do the right thing (or not as the case happened to
be).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3433 542714f4-19e9-0310-aa3c-eee0fc999fb1
condition between the omgr thread and the conmgr thread. Now when the omgr
thread processes an event that is going out to the clients, it flattents
the message itself for each client that is to receive the message and the
flattened data is posted to the conmgr outgoing queue.
This means that once an event is finished processing, no further
modifications to any of the data associated with the event can effect the
data queued up to be sent to the client. This is a good thing, it will
eliminate or illuminate a very baffling class of bugs that we've sort of
been ignoring because we knew this could be the cause.
We used to take an event and flatten it directly into the direct buffer
from which we would do our socket write. Now we flatten it into a
temporary byte array. This means a metric shitload more garbage generation
and collection. We used to do the flattening on the conmgr thread, now we
do it on the omgr thread. This means a big redistribution of CPU demand.
Either of those things could result in a significant negative impact on
our performance, but we'll just have to deploy this stuff and find out.
Whee! If it turns out to be a serious problem, there are potential
optimizations that could be done by keeping a pool of direct buffers
around and flattening messages into them, relying on the fact that the
outgoing conmgr queue generally doesn't grow too large and we could
allocate tens to a hundred megabytes of memory for the outgoing queue if
we really needed to.
I'd also like to test the overflow handling stuff more. It didn't really
change in that everything just deals with arrays of bytes now instead of
unflattened messages, but I'll be more comfortable once I've seen all this
in action on ice where there may be few users, but they are just as likely
to experience lag and receive an overflow queue as users on the higher
traffic servers. There is code to log when overflow queues are created and
finally flushed and how much use they got while they were around, so that
should give us an indication of whether things are operating properly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3419 542714f4-19e9-0310-aa3c-eee0fc999fb1
flattens messages into a buffer and then passes that bucket to a
SocketChannel.write() method which is part of the NIO business. If said
buffer is a "direct" buffer, the write() method will in theory do
high-performance shit like DMA the data right to the network card. If it's
not a direct buffer, Sun apparently makes a temporary direct buffer,
copies the data into it and passes that on to the underlying socket send()
call. We weren't using direct buffers which means that we were copying
everything one more time than needed (not a huge deal) and that we were
allocating a direct buffer for every message (a much bigger deal). This
should take a serious load off of the I/O thread and fortunately we can
test it on Ice to make sure it doesn't do anything super crazy.
All this said, this whole business is going to change when I rearchitect
Presents to avoid the potential race conditions it suffers from now and we
won't be able to use a single direct buffer to write all of our outgoing
messages, but I believe we will be able to use a pool of direct buffers
with one used by every message in the queue waiting to be written
(hopefully that won't be too many at any given time) which we can keep
around to avoid the expense of allocating and freeing direct buffers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3336 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne