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
isometric rendering) and modified it to allow it to consider different
potential move sets than just moving by one in the eight cardinal
directions.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3411 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
new turn holder. Log a warning. This is how we do things here.
Additionally, something I didn't change that is redundant is checking
to see if the player name is null, when the default implementation of
the active player check will return false if the name is null. It seems
to me that the movement of the active player business into the base game
package can result in some cleanup that hasn't been done, but I don't
want to look into it any further.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3398 542714f4-19e9-0310-aa3c-eee0fc999fb1
to write a simple board game for gamegardens, they shouldn't have to
explicitly set up an array indicating that all the players are active
(or worse, waste 45 minutes tracking down why the game is freezing up
suddenly).
If the playerStatus array is null, all players are active.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3397 542714f4-19e9-0310-aa3c-eee0fc999fb1
load resources to load from the default sets.
(A normal url would be "resource://<set>/<path>", one using the default set
would be "resource:///<path>". Goofy.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3396 542714f4-19e9-0310-aa3c-eee0fc999fb1
because we'd like to use the same TileSet over again when possible, but
we don't want to forevermore hold onto a TileSet if it could be gc'd.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3392 542714f4-19e9-0310-aa3c-eee0fc999fb1
is still actively playing the game. The delegate now uses this when
incrementing turns to skip over players not a part of the game (rather
than needing this same code in the derived classes).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3390 542714f4-19e9-0310-aa3c-eee0fc999fb1
for an error icon, just whip one up on the fly when needed (almost never).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3389 542714f4-19e9-0310-aa3c-eee0fc999fb1
value to observers when an OccupantInfo was updated or removed. This
functionality is now built-in to the dobj system, so just use
getOldEntry() on those two events.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3387 542714f4-19e9-0310-aa3c-eee0fc999fb1
games. Updated the PLAYER_KNOCKED_OUT variable name to prevent some
namespace contention issues.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3386 542714f4-19e9-0310-aa3c-eee0fc999fb1
you had logged on to one ocean and then moved to another, the previous
ocean's sceneIds are still in the scene cache.
Fix: Clear the scene cache both when we log off and when the scene repo is set.
Also, I made the cache be a LRUHashMap holding a measly 5 scenes.
Why are we filling up memory on the client with scenes that may or may not
ever be revisited?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3385 542714f4-19e9-0310-aa3c-eee0fc999fb1
sounds.properties lest we lose the needed info specified in the parent
properties files.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3384 542714f4-19e9-0310-aa3c-eee0fc999fb1
packages properly into client, data and server subpackages. This
eliminates a bunch of hackery I had to do to properly handle dead code
removal when building the Game Gardens client and games and it simplifies
things and sets a good example to follow the standard procedure as much as
possible.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3381 542714f4-19e9-0310-aa3c-eee0fc999fb1
CommunicationAuthorizer and rolled that into the BodyObject-based
permissions system. A victory for consolidation and elegance.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3380 542714f4-19e9-0310-aa3c-eee0fc999fb1
loads, but the sound manager wants to load things directly from the
classpath, so we need to allow it to use the classpath that the resource
manager was configured with to ensure that it did the right thing.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3379 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
day values to incorrectly always display as 0. I'm surprised nobody
else noticed this, it's right there on the blockade panel.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3372 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne