initiated by the client, but we always want to stop our ticking.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5519 542714f4-19e9-0310-aa3c-eee0fc999fb1
think it should be needed but I need to do more testing, post-bling.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5517 542714f4-19e9-0310-aa3c-eee0fc999fb1
Don't wait up to 60 seconds for the next peer refresh interval.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5514 542714f4-19e9-0310-aa3c-eee0fc999fb1
polled socket system. This much more cleanly and efficiently integrates peer
(and other server to server) connections into the normal server I/O framework
and should also eliminate for good the annoying server hangs that result when
our old blocking client I/O threads got their pants wedged.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5510 542714f4-19e9-0310-aa3c-eee0fc999fb1
accept new connections or read incoming messages from any of our extant
connections. Do send outgoing messages to those connections, but nothing else.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5493 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Throw an exception if any events, runnables or messages are posted after shutdown. These were previosuly being silently ignored. We really should know about them.
* Don't exit the connection manager thread until the object manager thread exits. This fixes a race condition where the wakeup time of the conmgr thread would determine if it shutdown before or after the object manager, meaning it would sometimes ignore messages around shutdown time.
* Add a shutdown constraint to make the client manager shutdown before the invoker/event/conmgr threads. This gives a single point in the shutdown sequence that applications can use as a constraint (TODO: shutdown groups?)
* Emit a log message for each shutdown method call. This could be very useful in production.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5491 542714f4-19e9-0310-aa3c-eee0fc999fb1
to the subscribed object when it becomes available and will stop listening when
we unsubscribe.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5486 542714f4-19e9-0310-aa3c-eee0fc999fb1
the local JVM (in general we'll use them on the server). The idea is to get rid
of all of our messy transients in BodyObject on down (and possibly other
places) and encapsulate them in a nice ClientLocal object (extended to
BodyLocal and on down).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5472 542714f4-19e9-0310-aa3c-eee0fc999fb1
the wall. There are vagaries of timing that simply cannot be accounted for and
a client that spends too much time with its balls up against a proverbial hard
flat surface will eventually get disconnected, but we are now a bit more
lenient in handling ~10 second sustained bursts of activity.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5459 542714f4-19e9-0310-aa3c-eee0fc999fb1
my javadoc stuff freaked out since PresentsServer isn't allowed to
see them. Point back to the right place.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5448 542714f4-19e9-0310-aa3c-eee0fc999fb1
second rate (10 messages per second), and to do the same 10x buffer on the
server that we were doing before so that we avoid disconnects due to network
congestion (which might "save up" some throttled messages and then end up
delivering them in a bunch with some later messages).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5424 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne