well in standalone mode. We need a way to install a director on registration.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6413 542714f4-19e9-0310-aa3c-eee0fc999fb1
(not by its superclasses), we need to rise through its superclasses as well
in order to find the provider interface.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6411 542714f4-19e9-0310-aa3c-eee0fc999fb1
ProjectXZoneRegistry extends a class that is a ZoneProvider...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6409 542714f4-19e9-0310-aa3c-eee0fc999fb1
use JVM generated proxies, nix marshaller/dispatcher."
The idea was to use Proxy.newProxyInstance to magically create (at runtime)
proxies for FooService interfaces instead of generating a bunch of boilerplate
code. I figured something similar could be done for FooDispatcher on the server
side.
However, we also generate C++ and ActionScript marshallers, and those aren't
ever going away (AS might support some sort of dynamic magic to do what we
need, but C++ sure don't). So I decided to leave the marshaller side of things
as is.
I did revamp the dispatcher side of things to eliminate the need for
FooDispatcher on the server. This turned out not to even require the use of
something so magical as java.lang.reflect.Proxy, because in this case we're
just reading in method ids over the network (and arguments), and calling the
appropriate method. Such mundane activities are easily accomplished with the
regular reflection API.
The existing dispatcher stuff still works as well, of course, and though the
conversion from the old style to the new style is pretty simple:
< invmgr.registerDispatcher(new FooDispatcher(fooprov))
> invmgr.registerProvider(fooprov, FooMarshaller.class)
there's no burning need to convert things over. Fortunately, there's no
(compatibility) impact on client projects to converting Narya and Vilya, so
I'll be doing that shortly. There will be a miniscule performance impact, but I
think the cost of a single reflective method call, given that all of its
arguments were read and unmarshalled from the network, will be a good distance
south of immaterial.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6403 542714f4-19e9-0310-aa3c-eee0fc999fb1
calls on the Java side, to match this added convenience we introduced to the
ActionScript side some time ago.
Before arms are raised into the air and waved like they really do care, bear
the following in mind:
Nothing will change at all on your project until you take some action to do so.
That action could include any of the following:
1. Continue to use narya-tools-1.2 to run genservice and you'll get the old
style "pass a Client reference for every service method invocation" marshallers
and you can continue to live happily in the past.
2. Leave some of your stuff un-regenerated, but generate new stuff using the
new tools and use the Client-reference-free style for new services. This is
likely to engender some PITA if you're trying to use both styles in the same
project because genservice just wants to operate on everything, but I offer it
as an option in case some other PITA motivates the tolerance of this
(presumably smaller) PITA.
3. Embrace the brave new world of simplicity and wield your good friend sed for
fun and profit:
(make necessary build.xml updates to start using narya-tools-1.4-SNAPSHOT)
% find src -name '*Service.java' | xargs sed -i 's:Client client, ::g'
(this will remove the Client argument from most of your services, some manual
fixes may be needed)
% ant genservice
% find src -name '*.java' | xargs sed -i 's:_ctx.getClient(), ::g'
(this will fix most of the places that pass a client reference into an
invocation service, some manual fixes will probably be needed)
I did this on Vilya and it magically took care of like 95% of the places where
changes were needed. The remaining half dozen changes were painless. Clearly
something like Yohoho vastly dwarfs Vilya in scope, but someone looking for an
hour or two of mindless typing to distract them on a lazy Sunday afternoon
would likely breeze through even that vast codebase without breaking a sweat.
Two more notes:
1. I'm going to switch Narya and Vilya over to the new style, and I'll be
fixing all the projects that use their services.
2. I lied (a teeny bit) about nothing changing. I made the old Client-taking
sendRequest methods deprecated, so projects that don't switch to the new style
will be presented with a large number of deprecation warnings. If this is too
terrible a burden to bear, I can remove the deprecation annotations on those
methods.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6395 542714f4-19e9-0310-aa3c-eee0fc999fb1
duration a bit less far. And Ray will be pleased to know that we're doing much
less redundant arithmetic.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6385 542714f4-19e9-0310-aa3c-eee0fc999fb1
to suppress subscription failure events in addition to subscription success, as
well as event forwards (though those shouldn't, in theory, go out over a new
connection because subscribers are cleared when a connection is dropped).
Nothing else looked like it might result in a spurious message being sent if a
connection was dropped and reestablished, so none of the other calls were made
to supply an expected connection.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6376 542714f4-19e9-0310-aa3c-eee0fc999fb1
on one connection, then disconnects. While that request is in the
pipeline, it reconnects, then receives the subcription that the first
connection requested before it sends its own subscription requests. To
prevent this, make sure that the current connection is the same one
that made the request.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6375 542714f4-19e9-0310-aa3c-eee0fc999fb1
obtain containment and a stack of specifically typed outer class references to
accomplish what we need without misleading casts.
This will require changes to Yohoho which I shall make forthwith.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6320 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Rename PrefixServer.Module classes to PrefixModule. They all implement guice's Module, and it's
hard to pass a class around as its interface if they share a name.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6303 542714f4-19e9-0310-aa3c-eee0fc999fb1
The presents-specific portions of ConnectionManager like reading Message subclasses and sending
datagrams are now in PresentsConnectionManager. PresentsServer should behave identically, except
during shutdown. Before, connections would be accepted and datagrams would be read until the OMgr
thread exited. Now, both stop as soon as the server begins its shutdown. This seems like an
improvement to me, but let me know if it causes issues and I can rework it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6270 542714f4-19e9-0310-aa3c-eee0fc999fb1
touches the _handlers Map which should only be modified on the
ConnectionManager thread. Add transferAcceptedSocket for outside socket
acceptors to call. It sticks new sockets into a queue, which are then passed
to handleAcceptedSocket as part of ConnectionManager's iterate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6250 542714f4-19e9-0310-aa3c-eee0fc999fb1
since been replaced by using the secret undocumented JDK APIs for doing the
same thing. AFAIK that works on all of our servers and we're not shipping
libsignal.so with anything.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6225 542714f4-19e9-0310-aa3c-eee0fc999fb1
ActionScript bits remain belligerent, but the Java stuff is mostly shipshape.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6222 542714f4-19e9-0310-aa3c-eee0fc999fb1
Andrzej Kapolka