had the capability to add targets (with their own module / log-level).
Add back in this capability, in very simple form for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4584 542714f4-19e9-0310-aa3c-eee0fc999fb1
objects so was not seeing NPEs that others were.
Fixed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4581 542714f4-19e9-0310-aa3c-eee0fc999fb1
peer sign-on to be the connecting server's node name.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4580 542714f4-19e9-0310-aa3c-eee0fc999fb1
Take the lock immediately if there are no subscribers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4576 542714f4-19e9-0310-aa3c-eee0fc999fb1
make life harder for Yohoho, but making life easier for Yohoho should not come
at the expense of baffling default behavior.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4574 542714f4-19e9-0310-aa3c-eee0fc999fb1
Make Long not wrapped for now.
Don't svn update until after mdb regenerates everything..
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4569 542714f4-19e9-0310-aa3c-eee0fc999fb1
for element types other than String.
- Changed streamer init to prevent the above change from triggering
a re-init when the delegate is looked-up.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4568 542714f4-19e9-0310-aa3c-eee0fc999fb1
I was looking up streamers by java name, but passing in the actionscript
name. This was only affecting Object[]'s containing String elements
due to the addition of String to Translations.
Previously, 'java.lang.String' wasn't getting translated into the
actionscript equivalent, so it just worked. Two bugs can cancel each other out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4567 542714f4-19e9-0310-aa3c-eee0fc999fb1
to fail if a director tries to register services groups but was not created
until after the client was logged on.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4557 542714f4-19e9-0310-aa3c-eee0fc999fb1
I write two lines in the afternoon and it makes me feel alright.
I write two lines in times of peace, I write two in times of war.
I write two lines before I write two lines, and then I write two more.
Bringing ActionScript world into line with the Javver.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4556 542714f4-19e9-0310-aa3c-eee0fc999fb1
notion of a global group (though we implicitly define one in InvocationCodes)
added a mechanism for directors (which generally handle the client side of
invocation services) to register their interest in bootstrap service groups so
that the whole goddamned complex business can happen magically behind the
scenes.
If you instantiate a director, it will automatically register interest in the
service group it needs and everything will work. If you don't use the director
code, you don't get the services and you can safely exclude all of that code
from your client even though the services are still in use on the server (and
presumably used by some other types of clients).
This is going to break all the builds, which I'll soon fix. Then I'll go write
all this in ActionScript. Yay!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4552 542714f4-19e9-0310-aa3c-eee0fc999fb1
MetaSOY clients (Swiftly, World, and soon Admin Dashboard) don't have to know
about a bunch of unrelated crap. Fricking complexity++, grumble.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4551 542714f4-19e9-0310-aa3c-eee0fc999fb1
There is no recent (~years) modification of this line, but at the same
time it appears that none of our products use the LocationProvider.moveBody()
method, so maybe this bug has just never been tickled.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4549 542714f4-19e9-0310-aa3c-eee0fc999fb1
subinterfaces of InvocationProvider and forward requests to peer nodes
in order to use the same methods on owning peers and cloning peers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4546 542714f4-19e9-0310-aa3c-eee0fc999fb1
queue up an invoker unit which would go off and do some database stuff and then
by the time it came back and was ready to publish its results to a distributed
object, the object in question would have been destroyed for any of a variety
of fairly natural reasons (client disconnected or logged off, game was
abandoned, dog ate homework).
One "solution" to this problem would be to litter our games' code with
thousands of calls to isActive() in the handleResult() methods of our invoker
units. We've done a bit of that in Yohoho but I've resisted starting down that
path in our other games.
Another solution would be to create an Invoker.Unit wrapper that takes a
reference to the distributed object (or objects) that it will be modifying and
have the common unit code check that the object(s) in question are still alive
at the end of the asynchronous operation and not call handleResult() if they
are not. This has numerous problems: what do you do if one object is alive but
not another, how do you incorporate this functionality in with the numerous
other Invoker.Unit derivations we have that simplify our lives in other ways
(without getting crazy and starting to use something like AOP), do you silently
abort the operation or log something?
So instead, I've come around to the idea that this is simply a dirty fact of
life in asynchronous programming and the fact that we can accept modifications
to distributed state after the distribted object in question is dead is a good
thing. We used to log a warning every time this happened and freak out even
more substantially if one tried to start a transaction on a dead object. Now we
will simply log an informational message (I don't think this sort of thing
should be silently ignored because there are some cases where it is an
indication of incorrect code, those are simply more rare). We will also allow a
transaction to be started on a dead object and when the transaction is
committed, all the events involved will be dropped just like a single
modification would have been dropped on that object.
This allows the most sensible thing to happen which is any results that are
published to still live objects will actually be published and results
published to dead objects will be dropped without making a big fuss. Since a
dead object by definition cannot have subscribers, no one could possibly have
cared about the dropped events anyway.
Also widened.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4545 542714f4-19e9-0310-aa3c-eee0fc999fb1
(Put the user content as a child of the system ApplicationDomain).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4544 542714f4-19e9-0310-aa3c-eee0fc999fb1
acquire and release locks, and to use handler objects to manage locks in
the process of resolution.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4542 542714f4-19e9-0310-aa3c-eee0fc999fb1
I thought I was casting: Function(myObject)
I gotta remember that the function-looking variants do more than cast.
For example:
var o :Object = null;
var s :String = String(o);
trace(s.length); // outputs 4. (s === "null", now)
Apparently Function(args) tries to evaluate the arguments as if they were
code. Switched to casting like (args as Function);
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4539 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell