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
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
CheckStyle. The checks are slightly looser than I'd like but way better than
nothing and we get a bunch of other useful warnings like shadowed names and
other handy bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5253 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Inject the auth Invoker.
- Inject the Authenticator and formalize the chaining authenticator pattern.
- Simplify PeerNode creation and make the PeerAuthenticator a chainer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5162 542714f4-19e9-0310-aa3c-eee0fc999fb1
subclasses provide PresentsServer "services" we'll just have no PresentsServer
services. All services will be provided by components and the server will
disappear in a puff of inversion of control.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5155 542714f4-19e9-0310-aa3c-eee0fc999fb1
dependency resolution and management. Things are currently in a state of
transition, but the important patterns have been established and I'll aim to
sweep through all of Narya, Nenya and Vilya in the near future and do
everything properly.
Going through the other million-odd lines of code we have scattered across our
various projects that use these libraries is not something I plan to do, so
we'll be maintaining backward compatibility with the old static member method,
though I hope to strive toward eradication of that usage entirely in MSOY while
we still have a fighting chance.
Given that some of our projects will continue to use the static member method
in perpetuity, I'm not going to @Deprecate those fields because that would fill
their logs with so much spam that they'd have to turn off deprecation warnings
which would make life worse for them. So instead we'll settle for the big scary
comment warning people away from the old bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5153 542714f4-19e9-0310-aa3c-eee0fc999fb1
allowing the use of annotations to customize transport for
DObject fields and service/receiver methods.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5099 542714f4-19e9-0310-aa3c-eee0fc999fb1
can't ever be false. (And just above, we've already confirmed that channel != null, so this
check wasn't falling back to protecting us from that)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4867 542714f4-19e9-0310-aa3c-eee0fc999fb1
the shutdown sequence out to our clients where desired.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4807 542714f4-19e9-0310-aa3c-eee0fc999fb1
looks like it should be running on the dobjmgr thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4653 542714f4-19e9-0310-aa3c-eee0fc999fb1
if it is called from any thread except the distributed object dispatch thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4647 542714f4-19e9-0310-aa3c-eee0fc999fb1
in case we freak out in the middle of writing a message.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4645 542714f4-19e9-0310-aa3c-eee0fc999fb1
required some serious bending and folding of the generic type system, but for
the most part we managed to avoid any mutilating. The gendobj task now
generates properly typed "addToXXX" and "updateXXX" DSet methods based on the
parameterized type of the DSet. This might cause unrecompiled code to break,
but I don't think there are many cases in the base toolkit where people call
DSet adders or updaters. We'll see and I'll add backwards compatibility
versions for cases where we need them to support GG games (everything else we
can just recompile).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4245 542714f4-19e9-0310-aa3c-eee0fc999fb1
inheriting a socket channel inetd style. It doesn't actually work for annoying
reasons, but I figured I'd get the code in there and the type safety fixes and
maybe Sun will fix their stupid bug at some point (I should create a test case
and actually submit a bug report...).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4230 542714f4-19e9-0310-aa3c-eee0fc999fb1
AuthingConnection is replaced by a RunningConnection we need to transfer
over any associated overflow queue to the new connection object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3989 542714f4-19e9-0310-aa3c-eee0fc999fb1
a year since the refactor that inspired leaving this logging in.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3961 542714f4-19e9-0310-aa3c-eee0fc999fb1
longer know about, request that it be given the boot when it rears its
ugly head.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3643 542714f4-19e9-0310-aa3c-eee0fc999fb1
what I believe to be a race condition in SocketChannel.toString()
(ultimately sun.nio.ch.Net.localAddress()) on FreeBSD.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3471 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
there will be relatively few of those (at most one per client that is
experiencing lag) and while the client is experiencing lag we will be
trying to write their data once per pass through the sockets (which could
be hundreds of times a second) and we don't want each write attempt to
result in the creation of a temporary direct buffer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3345 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne