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
classloader to use when unserializing objects off the network. Also fixed
the way custom classloaders were used as Class.forName(class, true,
loader) seems to be the proper way to go to have caching work and whatnot.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3268 542714f4-19e9-0310-aa3c-eee0fc999fb1
code did that due to eventuall getting out of the loop, the "fixed" code
failed to do it if we failed to fill our buffer up on the first read.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2695 542714f4-19e9-0310-aa3c-eee0fc999fb1
the loop, so I'm rolling back to the previous version since I can't even
log in to my server with this change. Mike if you want to take a look or
tell me what jimmyjamming needs to be done to make this change work, that
would be great.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2694 542714f4-19e9-0310-aa3c-eee0fc999fb1
frame size was exactly the same size as the buffer and no future messages
came down the pipe to wake us up again. This probably would have had to
happen very early in the session as the buffer gets bigger and bigger to
accomodate the largest frame seen during the entire session and
asynchronous messages are coming in more frequently as well. Thus it's
extremely unlikely that this ever actually hung. In any case, we now log
that circumstance (and do the right thing) so we can see if the log
message turns up in future bug reports.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2693 542714f4-19e9-0310-aa3c-eee0fc999fb1
field or fields of a streamed object. This allows us to add new fields to
the end of a streamable without causing all existing serialized versions
to become unreadable.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2629 542714f4-19e9-0310-aa3c-eee0fc999fb1
one instance of the nested exception failing to log anything useful when
it is reported at a higher level and we're seeing failures in the
low-level streamable decoding code which need debugging.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2087 542714f4-19e9-0310-aa3c-eee0fc999fb1
them assuming they'll contain either a primitive type or an instance of
Streamable.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2076 542714f4-19e9-0310-aa3c-eee0fc999fb1
the object serialization code which means that we can automatically
serialize said data members. Hooray!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2075 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne