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
before it has a chance to bring everything to a screeching halt.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3051 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
so that things go smoothly if they decide in requestFailed() to call
unsubscribe() in the course of their normal shuttings down.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2920 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
on the heels of a requestFailed(). They don't have to do it, but it's
easier to just always call unsubscribe() whether things succeeded or
failed, so we'll quietly allow an unsubscribe() even if we have no object
or nothin'.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2905 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne