synchronization problems and decided it would be a lot easier to just fix them.
The interval thread and the communication writer thread need to be properly
coordinated to avoid funny business.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4229 542714f4-19e9-0310-aa3c-eee0fc999fb1
on multiple ports, falling back from one to the next as appropriate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4158 542714f4-19e9-0310-aa3c-eee0fc999fb1
These are the preferred way to get instances of Boolean, Byte,
Short, Character, Integer, Long, Float, and Double object.
It's always made sense for Boolean objects, and with 1.5 these factory
methods were blessed as the proper way to get instances unless one
absolutely needed a distinct object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4145 542714f4-19e9-0310-aa3c-eee0fc999fb1
genericize Narya data structures, nor make the existing code type safe. That's
going to be an extremely large project.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4007 542714f4-19e9-0310-aa3c-eee0fc999fb1
- if a pong response took more than 5 seconds to receive, another ping
would be sent. When the pong finally arrived the delta would be
calculated using the most recently sent ping.
Fix: don't send more pings while waiting on a pong.
- After a pong is received, the _deltas array is mangled while
calculating the server delta, making subsequent pongs possibly
overwrite earlier calculated deltas.
Fix: calculate using a copy.
Also, changed the delta calculation to be the mean of the deltas rather
than the median. Left code in to do it both ways if this change was not
kosher...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3990 542714f4-19e9-0310-aa3c-eee0fc999fb1
one event when our run() method is called and then let other (non-distributed
object) things get their chance to run in proper order.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3795 542714f4-19e9-0310-aa3c-eee0fc999fb1
completely cleaned up so that an immediate attempt to logon using a
different configuration will not fail due to the client thinking it's
still logged on from the previous failed attempt.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3658 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
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 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
Michael Bayne