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
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
communicates that limit to the client which queues outgoing messages so that it
does not exceed the limit. When the throttle is changed, the server does not
apply the new throttle until the client has ACKed it to avoid edge cases where
the client is up against the limit when the throttle changes.
ActionScript side of all of this forthcoming as well as more testing.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5422 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Subclasses use setOverflowLimit to enable
* handleMessage appends to overflow queue and starts interval if overflow is currently active or if the throttle fails a message
* handleMessage ends session if overflow limit is reached
* New handleOverflowMessages dispatches messages from the overflow queue until none are left or throttle fails
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5417 542714f4-19e9-0310-aa3c-eee0fc999fb1
that read and write it, and we need to cope if a client manages to go away
before we can send it its bootstrap response.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5412 542714f4-19e9-0310-aa3c-eee0fc999fb1
thing before committing instead of just going "oh yeah, I've been having this stuff
sitting around uncommitted for a while waiting on it to be blessed" and missing
out on things that'd changed in the meantime.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5400 542714f4-19e9-0310-aa3c-eee0fc999fb1
Note: this involves generated code from a samskivert patch I only just sent to mdb,
but he's in a meeting, so that won't show up for a little.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5369 542714f4-19e9-0310-aa3c-eee0fc999fb1
importing receivers from their senders to satisfy their links.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5333 542714f4-19e9-0310-aa3c-eee0fc999fb1
directly to stderr. Logging an exception with the associated warning does the
right thing and logs the stack trace via the logging system.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5318 542714f4-19e9-0310-aa3c-eee0fc999fb1
server initialization phase. Only after the event thread is established is it
unsafe to be wild and wooly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5315 542714f4-19e9-0310-aa3c-eee0fc999fb1
clearDispatcher() as I saw some craziness in the wild.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5314 542714f4-19e9-0310-aa3c-eee0fc999fb1
into the thousands of "Missing subscription in unmap" errors that we have been
getting as a matter of course.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5293 542714f4-19e9-0310-aa3c-eee0fc999fb1
was necessary (javac claimed it was, Eclipse claimed it wasnt'). Fortunately,
we can do everything with Class<FooClient> methods that avoid the need for
supression entirely.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5275 542714f4-19e9-0310-aa3c-eee0fc999fb1
generic array type handling and other niggling bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5267 542714f4-19e9-0310-aa3c-eee0fc999fb1
Jamie Doornbos