not be generated. Cleaned up the generated provider interface formatting a bit.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3715 542714f4-19e9-0310-aa3c-eee0fc999fb1
and FooDispatcher. This means we will no longer be able to make FooProvider a
class that directly handles FooService methods, but the savings in confusion
for first time users of the framework will more than make up for the minor
inconvenience.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3714 542714f4-19e9-0310-aa3c-eee0fc999fb1
NoSuchMethodError) sticks a fork in the event dispatcher thread?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3712 542714f4-19e9-0310-aa3c-eee0fc999fb1
to using the class name but get the appropriate class in the case of
RunQueue queued intervals.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3695 542714f4-19e9-0310-aa3c-eee0fc999fb1
of codes. Currently the unit dump that is done once every 15 minutes is
chock-full of one-off units. Let us report the short class name of
the dispatcher, rather than the code with which an instance is registered.
Also: Thou shalt always iterate over the entrySet of a Map if thou planneth
to utilize both the key and the value.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3694 542714f4-19e9-0310-aa3c-eee0fc999fb1
object that can be (and is) provided to external callers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3688 542714f4-19e9-0310-aa3c-eee0fc999fb1
completely cleaned up so that an immediate attempt to logon using a
different configuration will not fail due to the client thinking it's
still logged on from the previous failed attempt.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3658 542714f4-19e9-0310-aa3c-eee0fc999fb1
longer know about, request that it be given the boot when it rears its
ugly head.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3643 542714f4-19e9-0310-aa3c-eee0fc999fb1
presents level as it is of interest in pretty much any system. This allows
us to do away with one of the time stamps as well.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3624 542714f4-19e9-0310-aa3c-eee0fc999fb1
optimization in the process.
Previously, we dumped stack on the server if a entry add was illegal but
did nothing for update/remove.
On the client, we complained for updates and (indirectly) adds, but not
removes.
Now we complain everywhere.
And- as an added bonus, on the server we now do only one binary search for
updates and removals. Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3528 542714f4-19e9-0310-aa3c-eee0fc999fb1
(in fixed framerate format) with the Presents event queue in what will
hopefully be happy harmony. Also made some edits to the Presents code to
not sound like we assume things run on the AWT thread which we don't and
which is not the case in this framework.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3510 542714f4-19e9-0310-aa3c-eee0fc999fb1
what I believe to be a race condition in SocketChannel.toString()
(ultimately sun.nio.ch.Net.localAddress()) on FreeBSD.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3471 542714f4-19e9-0310-aa3c-eee0fc999fb1
methods they were looking for.
Since it's probably impossible to have proguard generically skip renaming
for these generated method names, let's update the fields in a different way.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3434 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
freaking out in standalone mode where the server is started, and shutdown
and started again repeatedly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3418 542714f4-19e9-0310-aa3c-eee0fc999fb1
whether or not we're already shutdown as it may have shutdown
unexpectedly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3415 542714f4-19e9-0310-aa3c-eee0fc999fb1
response telling them to upgrade. Note to self, do the thing where the
server immediately writes the version number to the auth stream so that we
don't have to worry about this sort of legacy crap.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3410 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne