This has been happening for a while on PX and I've been meaning to track
it down. When a peer shuts down an object that's proxied on other peers,
the other peers receive an ObjectDestroyedEvent, and clear the object
from their omgrs. Other listeners may also receive the event and will need
to clear the proxying information, but that causes an unsubscribe to be
queued up, which when it runs will find the DObject already gone, and log
an error.
At first I considered not queuing up the unsubscribe action if the object
is no longer present in the omgr, but in the case that I'm working with
we have 2 or more objects that will all be destroyed simultaneously.
Even if I test to see if the first object is around or not, this same
test would always pass for the second object even though its death event
is next on the queue. The unsubscribe would be enqueued after THAT, so
there's no test to detect that the two objects are linked.
Instead, just suppress this message if we're a peer client. I didn't
want to suppress it altogether because we might want this message logged for
normal client connections. Maybe not.
Perhaps there is a better way. Maybe the PeerNode should add its own
ObjectDeathListener and clear out the proxy information and ensure that
the proxied object is also destoyed, and clients need not unproxy manually
in that case.
RFC.
Consolidate warnings and interval scheduling in doWarning().
Don't let the reboot time drift because of delays on the RunQueue.. each
warning is scheduled based on absolute time from _nextReboot.
doWarning() now takes two args so any subclasses that had overridden
it (unlikley beyond PX) will break...
PendingShutdownObservers will now get the actual milliseconds until reboot.
Basically: after all this, things should essentially work the same except
now there is a protected three-arg version of scheduleReboot that lets you
schedule an exact time, bypassing the normal round-up to the next highest warning time.
Previously a reboot time was only exact if it was further away than
the first warning. Otherwise, the time was rounded upwards to
the next warning time. This is probably still desired for manually
scheduled reboots, but when trying to coordinate reboots between
nodes we need to be able to schedule them exactly even if we're
already in the warning phase.
- Previously if you scheduled a reboot for 5am every day, but the
server came up at 3am, it would schedule the reboot for 5am the next
day. Subtract a day if the current time is before the rebootHour.
- When skipping weekends always push the time out rather than
pulling it in. Questionable, but so was the previous behavior.
If you set it to reboot daily but skip weekends, it would not
skip weekends.
This avoids a needless wait in the run queue for most notifications. Only
notifications that result directly from something one of the communicator
threads did will need to do a loop de loop.
This should close the hole where ClientObserver could be told that the
ClientObject was available *after* some events have come in on the ClientObject
(which they then miss). Now when the subscription response comes in for the
ClientObject, observers are notified immediately, and will be wired up and
ready for any messages that are themselves already in the queue ready to be
dispatched.
- Put "/help " (with a space after it) in the history so that it's useful.
- Don't return the usage as an error, or the chat entry field
won't clear. What the fucking fuck? Seriously, there was a 3-fucking-line
comment in here about doing the right thing and someone ignored it
and made it do the wrong thing.
SK has been doing the wrong thing in response to chat errors, and now I worry
that games that used to do the right thing have changed to do things
incorrectly because the fucking help command has been fucked up for 2 years.
The hostname being null interfered with peer locks.
Instead let's just allow ourselves to be inited in
"adHoc" mode.
init()'s overloads are becoming overloaded...
populating a properties object might be better...
When a NodeAction was queried for which nodes were applicable, it
filtered out nodes that didn't have a nodeObject.
However, when a NodeRequest is similarly queried, null nodeObjects
were not filtered out and I guess it was up to the NodeRequest to
say "no" to null nodeObjects. This is not part of the API specification
for NodeApplicant, and in Spiral Knights we have various requests/actions
that simply return true without regard to the contents of the nodeObject.
So that's fucking retarded. Do the null check just like it's done
for NodeActions. In addition, do an extra check if one of single-node
methods is called for an action or request, to make sure that one
pre-determined node has a nodeObject set up. If not, log a warning,
and return an error response in the NodeRequest case.
This is to support running in ad-hoc, single-node noded mode.
However, it appears some code in here will choke on a null
node name.
This is for something in Spiral Knights, where we used to run
in non-noded or noded mode, and so we already cope with the
nodeName being null. Now we want to always run noded, so that
we can DRY and not check various local variables before checking
the (other) NodeObjects: now we can just check against all
the node objects.
So I may need to return here and make safe various equality
checks against the nodeName.
This closes a giant security hole, but may break existing code.
PlaceObject.ManagerCaller is a poor-man's InvocationService, allowing
one to easily make a call to a method on the PlaceManager. The problem
is that this is turned on by default and any matching method is run.
This change disables it by default, but you may re-enable it by
overriding PlaceManager.handleManagerCalls() and returning true.
I also went ahead and made the ManagerCaller.invoke() method deprecated
so that you'll see a nice warning during compile time. You should
really consider just using a standard InvocationService to communicate with
the server. That way you effectively create a whitelist of client-callable
methods and there will be no surprises.
This is much simpler than requiring customizers to extend and override a bunch
of classes just to poke their fingers into the un/serialization process.
Premature optimization the fun side effect of rendering the
exception's attached stack trace completely useless.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6794 542714f4-19e9-0310-aa3c-eee0fc999fb1
The ActionScript code is now under aslib and is built via Maven (and Ant). The
CPP code is under cpplib and is ignored by everything (other than service
generation), but now at least it's not crufting up the Java submodule with its
XCode project.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6783 542714f4-19e9-0310-aa3c-eee0fc999fb1
This will allow us to properly ship narya-tools.jar to Maven Central which is
necessary for Nenya and Vilya (and any other Narya-using project) to themselves
be built.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6776 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray J. Greenwell