invoker and dobj threads are well and truly finished.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4737 542714f4-19e9-0310-aa3c-eee0fc999fb1
after it's) logging off which comes in after we've cleared out the client
object and causes annoyance. Now we drop the message and we'll log a notice for
the time being.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4735 542714f4-19e9-0310-aa3c-eee0fc999fb1
lose connection with a peer for any reason, it will notice that we're still
alive and reconnect.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4732 542714f4-19e9-0310-aa3c-eee0fc999fb1
and the ProxySubscriber mechanism by which the server proxies for the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4730 542714f4-19e9-0310-aa3c-eee0fc999fb1
another server. The PeerManager needs both to rewrite the oid of the events
before dispatching them and to assign an eventId to them so that they will not
be filtered by PresentsClient when deciding whether or not to send them along
to its client. Also fixed compound event dispatch in the process. Now proxy
subscribers will be notified once of a compound event rather than of each
individual internal event.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4729 542714f4-19e9-0310-aa3c-eee0fc999fb1
(pre-applied and) posted before we received our object but processed (and hence
dispatched to us) after we received our object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4715 542714f4-19e9-0310-aa3c-eee0fc999fb1
provided to the object when it was created, have the LocationDirector
initialize the manager caller when it receives the PlaceObject and have it use
its client distributed object manager which tags events with the proper
clientOid. This still prevents us from running multiple clients in the same VM,
so this will probably all have to change again but this works for now.
Also some widening.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4712 542714f4-19e9-0310-aa3c-eee0fc999fb1
instead of our native library. I've left the native library support in in case
the Sun stuff is not available, but that's so extremely unlikely in a server
environment (IBM recreates Sun's signal handling in their VM because it's so
dang useful) that I should probably just nix it altogether and simplify things.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4710 542714f4-19e9-0310-aa3c-eee0fc999fb1
sandbox. They should work exactly the same but there seem to be remaining
niggles, so we'll iron those out without impacting other projects.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4706 542714f4-19e9-0310-aa3c-eee0fc999fb1
writeObject() as that handles nulls for us (and of course because that's how
it's done when streaming using reflection).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4704 542714f4-19e9-0310-aa3c-eee0fc999fb1
altogether as that also solves the "Class.getDeclaredFields() is not required
to return fields in declaration order" problem which has been looming. However,
this should work for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4701 542714f4-19e9-0310-aa3c-eee0fc999fb1
and writer methods for private and protected fields. This will allow us to
preserve the current read and write ordering and in the future when we "fix"
read and write ordering, we won't be fucked by a bunch of generated methods
that force the ordering. (Someone is using Presents on the CLR which turns out
to take advantage of the loose specification of Class.getDeclaredFields() and
not return them in declaration order, yay!).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4692 542714f4-19e9-0310-aa3c-eee0fc999fb1
readObject()/no-readObject() havers otherwise everyone everywhere will have to
generate streamer methods which is way too big a PITA. Grumble.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4690 542714f4-19e9-0310-aa3c-eee0fc999fb1
use in non-sandboxed environments). Unfortunately we have to do this for all
Streamable classes, not just the ones that have protected/private members
because we need to be able to call super.readObject() and have that exist even
if our superclass contains only public members.
Doing magic streaming with combinations of classes that do and don't have
readObject() would start to get extremely complicated, particularly if the base
class had readObject() an intermediate class had none, then a later class had
one again. Madness. Doing things with compiled methods will be faster anyway...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4686 542714f4-19e9-0310-aa3c-eee0fc999fb1
clientSessionDidEnd() which is called on the dobjmgr thread directly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4680 542714f4-19e9-0310-aa3c-eee0fc999fb1
been disconnected (in which case there may be conflicts in lock
ownership) or are connected asymmetrically (A is subscribed to B, B is
not yet subscribed to A).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4674 542714f4-19e9-0310-aa3c-eee0fc999fb1
fake Entry implementation. This also avoids breakage if a DSet entry's key
itself implements DSet.Entry (which just happened for the first time in Narya
history).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4673 542714f4-19e9-0310-aa3c-eee0fc999fb1
- handle // @Override // blah style comments
- deal with fields that are assigned to anonymous inner classes (actually
anything with braces, which would also include array literals).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4667 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne