files every time, so it'll get in the way of version control. Mrmph.
So: make the date optional, and leave it out for now.
Other comments?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6051 542714f4-19e9-0310-aa3c-eee0fc999fb1
and various dobj bits. The @Generated annotation is "@Documented" and
retained at source only.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6049 542714f4-19e9-0310-aa3c-eee0fc999fb1
At least call super() in a finally block, but I'll see if this can
be cleaned.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6039 542714f4-19e9-0310-aa3c-eee0fc999fb1
constructor and then never use it. This is almost a noop, except that
ClientDObjectMgr registers and starts a flusher interval that will never be
shutdown. Since ServerCommunicator lives for the lifetime of the server, this
has not caused problems.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6034 542714f4-19e9-0310-aa3c-eee0fc999fb1
pointless. Let's deprecate it and auto-generate DObjects that just use clone().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6028 542714f4-19e9-0310-aa3c-eee0fc999fb1
we're not running in a peered environment. Technically it might be
better to add the PeerManager to the lifecycle in init, but I don't
want to screw with the shutdown order, and this is the lowest-impact
solution.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6021 542714f4-19e9-0310-aa3c-eee0fc999fb1
Apologies for the redundant cast warnings this is sure to introduce.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6015 542714f4-19e9-0310-aa3c-eee0fc999fb1
when posted to a shutdown queue. There's a method we can override for that now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6013 542714f4-19e9-0310-aa3c-eee0fc999fb1
interdependents have indicated they're blocking to check. Otherwise the unit running before the
last BlockingUnit can post to the presents invoker and those newly posted units will be skipped.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6006 542714f4-19e9-0310-aa3c-eee0fc999fb1
- PresentsInvoker decides it's empty
- It waits on other dependencies
- During the wait, something (probably from one of the other dependencies) posts to the PresentsInvoker
- We loop back around, the dependencies are empty
- We end early, with the posted bit still to be done...
So... after waiting, do a quick check for emptyness and if not satisfied, start the whole dern cycle over.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6005 542714f4-19e9-0310-aa3c-eee0fc999fb1
NamedSetAdapter on autopilot; there you have multiple things that you might not want
to bother with, but here you damned well BETTER implement that one method yourself.
Also, while I'm at it, make that protected since I really doubt you're going to find
yourself sitting on top of an EntryAddedEvent that you're REALLY SURE is the right
one & want to pass it in to one of these by hand. And if you do, suck it up and let
the string compare burn the couple extra cycles to make sure. (I feel like making
the same change to the other Named* things here real quick, but I should really
double check that I don't break anybody's stuff/change anything I see using it that
would now be making the named versions more visible for now good reason)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6004 542714f4-19e9-0310-aa3c-eee0fc999fb1
listen for ElementUpdatedEvents on specific bits on dobjs.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6003 542714f4-19e9-0310-aa3c-eee0fc999fb1
actually reduce latency, but wouldn't it be cool if it did?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5985 542714f4-19e9-0310-aa3c-eee0fc999fb1
injected handling by subclasses.
I had a nice version of this that allowed user controlled handling for any signal to be injected.
Unfortunately it used multibindings from guice, and I'm loathe to add a dependency to narya just for
that.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5980 542714f4-19e9-0310-aa3c-eee0fc999fb1
logs that it's listening on its configured ports, when start() is called. It
does so on a separate thread, but I don't believe the subtle ordering
possibilities there are something that's actually causing/likely to cause
problems and/or needs to be called out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5947 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell