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 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
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
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
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
classloader to use when unserializing objects off the network. Also fixed
the way custom classloaders were used as Class.forName(class, true,
loader) seems to be the proper way to go to have caching work and whatnot.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3268 542714f4-19e9-0310-aa3c-eee0fc999fb1
Windows where it wigs out and behaves as if the connection was reset by
the peer ("An existing connection was forcibly closed by the remote host")
if one writes messages bigger than about 25k. I can't imagine how we would
be sending such big messages to the server, but it's worth a check.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3159 542714f4-19e9-0310-aa3c-eee0fc999fb1
the math appears to work out even though time stopped. We can use
RunAnywhere.currentTimeMillis() which will warn if time goes backwards but
since when that happens the IntervalManager stops dead in it's tracks,
we'll never get ticked to find out about it. Fucking Windows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2911 542714f4-19e9-0310-aa3c-eee0fc999fb1
client object has been updated so that the 90% of the directors that just
need to know any time that sort of thing happens so that they can listen
on the current client object can easily and robustly do so.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2907 542714f4-19e9-0310-aa3c-eee0fc999fb1
and refuse subscriptions to invalid oids (it's not out of the realm of
possibility that the clients were somehow subscribing to oid 0 and funny
things were happening).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2778 542714f4-19e9-0310-aa3c-eee0fc999fb1
seconds to pass in between ping/pong latency samples. Additionally, we
resync the clock every 10 minutes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2748 542714f4-19e9-0310-aa3c-eee0fc999fb1
is a problem with starting a transaction, we don't get an exception
for failing to commit the transaction.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2712 542714f4-19e9-0310-aa3c-eee0fc999fb1
in the low-level invocation services whereby after a disconnect, any
InvocationReceiver registration would be wholly ignored due to the
previous registrations being left in the receivers set and DSet refusing
to add duplicate instances of the registration. This wasn't immediately
apparent because the initial set of registrations always happens in the
same order and thus are equally useful after the reconnect and any other
registrations are removed during the normal course of affairs. But if a
user disconnects *during* a puzzle, they will leave that puzzle's
registration around and be unable to play that (or any) puzzle again until
they log off and back on.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2707 542714f4-19e9-0310-aa3c-eee0fc999fb1
circumstances where they aren't around when they should be.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2702 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
observed after the last subscriber of a matching distributed object has
been removed. Our client's subscription will not be flushed until after
the delay has expired, and only then if no other subscriber has come along
requesting the object in the meanwhile.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2303 542714f4-19e9-0310-aa3c-eee0fc999fb1
applied immediately on the authoritative copy of the object (the one on
the server). We already do this for all other object modifications (except
OidList which is kind of special anyway), but we should be wary of
potential wickosity.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2302 542714f4-19e9-0310-aa3c-eee0fc999fb1
subscriber so that we don't hand them out as happily proxied objects to
subsequent subscribers that might come along before we receive our unsub
ack. We do still maintain non-acked objects in a dead table so that we
know when to warn about undispatchable events and when to ignore them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2210 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
Ray Greenwell