If there's an error when calling the callback function,
we were assuming it was an argument-related error and trying again.
However, this is sorta bad behavior as we don't want to call
twice into a callback. In the case I was seeing, the first time
in caused an NPE, but popped up a panel, and the second try
was no-opping because the panel was already up (but misconfigured).
So: don't even try a second call, because it looks like
flash will accept args to an argless function.
We'll have to try this out for a while and see if it works.
If so, I can neaten this code. If not, I'll uncomment
some of this and try a more surgical approach (only catch
ArgumentError, only retry if we had 1 boolean arg.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5585 542714f4-19e9-0310-aa3c-eee0fc999fb1
This has been wacked-out like this ever since I first wacked it out.
Since the base class is ResultAdapter and it only takes failure, and the
'processed' function for ConfirmAdapter is optional, it seemed to make
sense this way.
But, we have another ResultAdapter (for non-invocation ResultListener)
and it expects success first.
So Mike noticed this today (I swear there was a big brouhaha about this
over the summer) and beat me with my own rubber chicken.
I'm not sure why I had a mental block about reordering, but let's do it!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5583 542714f4-19e9-0310-aa3c-eee0fc999fb1
bodyWillEnter() where the PlaceManager can do whatever they want when the body
enters, before or after the occupant info creation process.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5579 542714f4-19e9-0310-aa3c-eee0fc999fb1
old dangerous way of updating. We will now use only the timeless way.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5574 542714f4-19e9-0310-aa3c-eee0fc999fb1
a very similar message in the yohoho reboot manager.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5570 542714f4-19e9-0310-aa3c-eee0fc999fb1
There is a registerReporter() that doesn't take a type, so this
seemed like the way to go, rather than changing msoy to
pass in DEFAULT_TYPE.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5565 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Track the exception that occurred, if any, when launching the bureau in each agent
* Guarantee agent object is always destroyed. This was probably also a memory leak.
* Destroy the agent object immediately if the launcher raised an exception rather than waiting for timeout
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5560 542714f4-19e9-0310-aa3c-eee0fc999fb1
need to first construct an instance with nulls. Also added newTuple(). Opted
not to make newStreamableTuple() as that would make more sense in a Tuples
class, but this method can only be accessed by calling StreamableTuple.newTuple
which seems to me to already tell the whole story.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5556 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Use _writer != null iff the socket is open and the authrequest has been sent
* Warn when posting messages prior to socket connect
* Clear the outgoing queue prior to sending the auth request, the servers authing connection expects this
* If a logoff is encountered prior to the socket opening, just shut down without sending auth request
* Driveby unused variable removal
This should fix the log warning "AuthingConnection$1: Received non-authreq message during authentication process"
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5548 542714f4-19e9-0310-aa3c-eee0fc999fb1
peer disconnects for any reason, end its session immediately.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5546 542714f4-19e9-0310-aa3c-eee0fc999fb1
something friendly and drop the request. The server is about to go away.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5545 542714f4-19e9-0310-aa3c-eee0fc999fb1
utility in sending pings before we're authenticated.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5543 542714f4-19e9-0310-aa3c-eee0fc999fb1
ClientManager and it is already pretty tightly coupled to the ConnectionManager
so we weren't really fooling anyone with that ham-fisted attempt at
abstraction.
Also cleaned up more mid-shutdown behavior. If a session is unmapped after the
omgr exits, avoid generating a warning by trying to hop onto the omgr thread to
clean up after ourselves. We still do all the actual socket related closing so
that the party on the other end of the socket benefits from a clean shutdown
where possible.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5537 542714f4-19e9-0310-aa3c-eee0fc999fb1
we fail to bind to any of our desired ports. We'll just do that automatically
because no one wants a totally hapless server sitting around unable to actually
accept any connections.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5536 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell