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
unregistered. Flush invocation listener mappings after an expiry period if
they were not already removed by virtue of receiving a response.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2040 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne