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
changed the output format to be the same as the one for DObjectManager
profiling output.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3309 542714f4-19e9-0310-aa3c-eee0fc999fb1
actually dispatching the event to subscribers. We can't trust anyone.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3308 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
it's unlikely that the rabbit hole will surprise us with further depth.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3269 542714f4-19e9-0310-aa3c-eee0fc999fb1
generator. It handles inner classes slightly differently and prepends a
project-specific header to the generated classes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3239 542714f4-19e9-0310-aa3c-eee0fc999fb1
mapped into the client table without mogrified names.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3226 542714f4-19e9-0310-aa3c-eee0fc999fb1
both destroyed without any intervening event processing.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3186 542714f4-19e9-0310-aa3c-eee0fc999fb1
period so that we can see what sort of funny business is going on with the
network thread when the process spikes up to 100% CPU.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3066 542714f4-19e9-0310-aa3c-eee0fc999fb1
let's just not do it. We can accomplish our earlier goals, though with
slightly less distinction making capability, in a different way.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3050 542714f4-19e9-0310-aa3c-eee0fc999fb1
after things have already been processed and cleaned up on the server.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3047 542714f4-19e9-0310-aa3c-eee0fc999fb1
was once alive but is now gone. Catch attempts to start a transaction on a
destroyed object and log them as such. Made isDestroyed() and isActive()
final for wholly unfounded performance reasons.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3045 542714f4-19e9-0310-aa3c-eee0fc999fb1
more discipline when handling names in our code base. Any user entered
name should find its way into a Name object as soon as it comes out of a
text field or whatnot, and stay that way until it makes its way into a
text field or into a database record (for which String objects are vastly
simpler because of JORA magic).
Dear God, let me never again make a change this large for the rest of my
mortal life.
Unfortunately, this means we have to keep an eye out for funny business
pretty much everywhere. However, since we will absolutely want to test
market stalls and so forth on Azure, we'll have an opportunity to iron out
any funny business that might fall under the radar during our internal
testing.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2980 542714f4-19e9-0310-aa3c-eee0fc999fb1
stack trace if we're not going to rethrow the error.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2958 542714f4-19e9-0310-aa3c-eee0fc999fb1
listener tries to 'new int[Integer.MAX_VALUE]' or infinitely loop, they
will get the smack down and we will go on about our business.
If things have actually gone pear shaped and we are failing on every
event, we'll hit the 30 fatal events in 60 seconds cap and stick a fork in
ourselves.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2957 542714f4-19e9-0310-aa3c-eee0fc999fb1
sometimes (never on my server!) released twice. This will save the stack
trace from the first release and spit it out after the "normal" error-reporting
stack trace from the second release.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2955 542714f4-19e9-0310-aa3c-eee0fc999fb1
milliseconds) and same every 100th event instead of profiling every event.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2951 542714f4-19e9-0310-aa3c-eee0fc999fb1
milliseconds. I want to know what in the fuck those were.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2840 542714f4-19e9-0310-aa3c-eee0fc999fb1