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
there will be relatively few of those (at most one per client that is
experiencing lag) and while the client is experiencing lag we will be
trying to write their data once per pass through the sockets (which could
be hundreds of times a second) and we don't want each write attempt to
result in the creation of a temporary direct buffer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3345 542714f4-19e9-0310-aa3c-eee0fc999fb1
it's unlikely that the rabbit hole will surprise us with further depth.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3269 542714f4-19e9-0310-aa3c-eee0fc999fb1
period so that we can see what sort of funny business is going on with the
network thread when the process spikes up to 100% CPU.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3066 542714f4-19e9-0310-aa3c-eee0fc999fb1
milliseconds. I want to know what in the fuck those were.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2840 542714f4-19e9-0310-aa3c-eee0fc999fb1
through some well-timed disconnection early in the initialization phase),
we should consider it idle because then we'll catch it on the next tick
and flush it whereas otherwise it would just sit around forever until
someone logged in from that IP again.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2788 542714f4-19e9-0310-aa3c-eee0fc999fb1
being able to send a message immediately to the client due to it being too
large or the client's outgoing networking buffer being full for some other
reason (many messages sent very quickly or client that's reading messages
slowly).
I still need to add code to disconnect a client who fails to read messages
in a sufficiently timely manner.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2038 542714f4-19e9-0310-aa3c-eee0fc999fb1
managers can participate, reporting lies, damned lies and useful
statistics. Initial participants include the client manager, the
connection manager and the distributed object manager.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1894 542714f4-19e9-0310-aa3c-eee0fc999fb1
the server in 90 seconds. The client is set up to ping the server if it
has had nothing to say to it for other reasons in the last 60 seconds.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1860 542714f4-19e9-0310-aa3c-eee0fc999fb1
they needed to and when all that was stripped away, they didn't really
need their own config files.
Now what little config they need is provided by the users of these basic
services so that said users can make their own decisions about where to
obtain configuration information.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1820 542714f4-19e9-0310-aa3c-eee0fc999fb1
gracefully with failures; also no longer attempt to send messages to a
connection that has already been closed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1565 542714f4-19e9-0310-aa3c-eee0fc999fb1
between connections even on JVMs (like Linux's) that seem to feel no need
to actually return anything sensible from InetAddress.toString().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1564 542714f4-19e9-0310-aa3c-eee0fc999fb1
process so that it can be done by other entities than just the client
management services. Coordination between these parties is managed so that
no toes are stepped on in the course of loading and unloading clients and
everything is generally much nicer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1086 542714f4-19e9-0310-aa3c-eee0fc999fb1
longer maintained. Implementations can choose to create their own
authentication thread if they wish or use some existing combination of the
invoker and dobjmgr threads. Also added an invoker to the base server
class.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1085 542714f4-19e9-0310-aa3c-eee0fc999fb1
client object by way of passing the auth response data up to the client
after the completion of the authentication phase. This allows information
loaded by an authenticator (like a user record) to make its way into the
real world.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@722 542714f4-19e9-0310-aa3c-eee0fc999fb1
changed to Presents and Party changed to Crowd. Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@431 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell