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
the first 80 characters if this every actually discovers an anomaly rather
than just dutifully reporting every time someone updates really lengthy
crew news.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3409 542714f4-19e9-0310-aa3c-eee0fc999fb1
'iterator()' name and deprecate the old 'entries()' method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3405 542714f4-19e9-0310-aa3c-eee0fc999fb1
the PresentsClient which can then use it to fill in things like access
control information for the user. We could use this to replace the
UserStash mechanism we use on Yohoho, but that works so I doubt I'll do
that. However, this is needed to do things the more elegant way on future
projects, like Game Gardens.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3374 542714f4-19e9-0310-aa3c-eee0fc999fb1
that were using the old default (usually null) to use the new default.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3369 542714f4-19e9-0310-aa3c-eee0fc999fb1
together in one JVM and both interoperate with the AWT thread in a manner
so harmonious as to bring a tear to the eye. This was surprisingly much
easier that I expected, thanks to my eminently sensible initial design,
I'm sure. ;)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3360 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
the throes of a previous connection. Also don't spuriously recreate our
ticker because it's very possible for logon() to be called and not
logoff(), logon() might fail, for example.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3321 542714f4-19e9-0310-aa3c-eee0fc999fb1
changed the output format to be the same as the one for DObjectManager
profiling output.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3309 542714f4-19e9-0310-aa3c-eee0fc999fb1
actually dispatching the event to subscribers. We can't trust anyone.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3308 542714f4-19e9-0310-aa3c-eee0fc999fb1
objects (DSet, arrays) in a DEvent (which should not change as a result of
other events being applied) and those in the object itself (which do
change and evolve as events are applied to the object).
This is important both because the DEvent is passed on to another thread
for delivery to remote clients, thus changes to the values in the event
could take place before they were serialized and sent over the network,
and because compound events are applied to an object before they are sent
to the other thread for delivery and thus, for example, setting a DSet and
then adding a few entries to it in a compound event would result in the
DEvent copy of the DSet becoming corrupted.
Two problems remain (note, neither of these are new, the one issue
introduced when I rewrote the DObject stuff is fixed by these checkins):
1. Object subscription requests are supposed to deliver a snapshot of the
object at the point in the event stream at which the subscription
request was processed, but presently we pass only a reference to the
object off to the networking thread which means that before the object
is serialized and sent to clients, subsequent events could be applied
to it and then those events would be sent to the client as well
resulting in funny business (probably nothing more than duplicate DSet
entry warnings, but imagination and Chapter 17 tell us that worse
things could happen).
2. The use of Streamable instances could result in badness. If a field in
a Streamable is modified and the whole Streamable set() back into the
object to broadcast the update, then further changes were made to the
Streamable before the attribute change event was serialized and sent
over the network, the second modifications would be reflected in the
event triggered by the first modifications.
The first problem may be solvable (albeit inefficiently) by serializing
the DObject on the event dispatcher thread and sending that serialized
copy off to the network thread for delivery to the client. It would be
much less efficient as we would be unable to make use of the client's
already "primed" ObjectOutputStream which may have already mapped many of
the classes in the object to two byte codes, but object subscription is
fairly uncommon compared to delivery of events, so inefficiency might not
be a big problem in this case.
The second problem might be solved by requiring that all Streamable
implementations implement clone() and then cloning any Streamable
attribute just as we do an array or DSet during an attribute, array
element or DSet entry change. This would be a more significant performance
hit as well as require a review of all of our Streamable classes (to
determine if they need a custom clone() implementation), and it has up to
now not actually manifested as a problem.
In any case I'm not going to tackle either of these remedies at the moment
because I'm on vacation, dammit.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3294 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne