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
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
There is no more SafeInterval, instead Intervals can be constructed with a RunQueue to use for expiring.
PresentsDObjectMgr implements RunQueue.
Client has a getRunQueue() method to get the client side RunQueue.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3283 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
more discipline when handling names in our code base. Any user entered
name should find its way into a Name object as soon as it comes out of a
text field or whatnot, and stay that way until it makes its way into a
text field or into a database record (for which String objects are vastly
simpler because of JORA magic).
Dear God, let me never again make a change this large for the rest of my
mortal life.
Unfortunately, this means we have to keep an eye out for funny business
pretty much everywhere. However, since we will absolutely want to test
market stalls and so forth on Azure, we'll have an opportunity to iron out
any funny business that might fall under the radar during our internal
testing.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2980 542714f4-19e9-0310-aa3c-eee0fc999fb1
client is disconnected, unsubscribe immediately. We normally unsubscribe
when the client loses its connection but it's possible for a subscription
request to come in and the client to lose connection before we can
communicate the object available response.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2824 542714f4-19e9-0310-aa3c-eee0fc999fb1
erroneously decide that we have stale subscriptions around, and log stale
subscriptions if we do end up clearing them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2817 542714f4-19e9-0310-aa3c-eee0fc999fb1
pirate selection and the time we manage to load up their pirate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2816 542714f4-19e9-0310-aa3c-eee0fc999fb1
loc by combining message dispatch into one method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2397 542714f4-19e9-0310-aa3c-eee0fc999fb1
they arrive at the client. Mmm... network efficiency++.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2396 542714f4-19e9-0310-aa3c-eee0fc999fb1
warning messages saying that we couldn't deliver events on the client that
come in after all client-side subscribers have been removed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2204 542714f4-19e9-0310-aa3c-eee0fc999fb1
wide variety of fucked up situations that might occur:
- Client authenticates and disconnects before their client object is
resolved.
- Client authenticates and requests to end their session before their
client is resolved.
- Client does one of the two previous actions and then attempts to
reestablish a session before the client object is resolved from their
first connection attempt.
- Client establishes a session in any of the previous or a normal
circumstance but their client object fails to resolve.
Goddamned distributed programming, race-condition cluster fuck, strange
shit happening once in a blue moon business.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2086 542714f4-19e9-0310-aa3c-eee0fc999fb1
user's session if their client object is not yet resolved. When it does,
their session will be "started" for the first time and everything will
work itself out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2068 542714f4-19e9-0310-aa3c-eee0fc999fb1
call super.sessionDidEnd() and still do things with the client object at
the termination of the session.
Also removed the passing of the client object to sessionConnectionClosed()
because it's still possible that it won't be avaiable when that method is
called and whatever is being done there should also be done in
sessionDidEnd() if it is to work when the user ends their session as well
as when they disconnect.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2027 542714f4-19e9-0310-aa3c-eee0fc999fb1
because it will have been cleared out of _clobj by the time said method is
called if it is called as a part of a terminated session.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2021 542714f4-19e9-0310-aa3c-eee0fc999fb1
connected or disconnected. Use this to determine if a client has "expired"
(meaning they've been disconnected for too long).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1871 542714f4-19e9-0310-aa3c-eee0fc999fb1
react to player disconnection, idle (implementation still pending), and
reconnection appropriately. Added PlaceManager.bodyUpdated().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1831 542714f4-19e9-0310-aa3c-eee0fc999fb1
method invocation services and converted everything to the new style.
Could this be my biggest checkin ever?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1642 542714f4-19e9-0310-aa3c-eee0fc999fb1
session so that fake sessions can effect their own locking.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1294 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
Ray Greenwell