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
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
field/method names for the ActionScript version of a class (or to omit
something entirely). This removes the need for special case hackery for
toStringBuilder().
In order for annotations to work, however, we have to require that the
GenActionScriptTask be loaded from the same classloader that loads the classes
to be reflected upon. Before we only reflected on the target classes, never
instantiated them. Annotations are actually instantiated, so we have to be able
to create an instance of the ActionScript.class that is compiled into our
target classes and assign it to a reference that is compiled into
GenActionScriptTask. Beware the complexities of dealing with multiple class
loaders.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4405 542714f4-19e9-0310-aa3c-eee0fc999fb1
unmarshalled into an ArrayList on the receiver. Along the way, I improved
support for generic types as arguments to invocation services (which required
one unfortunate "sweeping" warning suppression, but since this is in generated
code, I think we can be sure it won't be doing anything untoward).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4375 542714f4-19e9-0310-aa3c-eee0fc999fb1
around of the interface (I wanted to automatically call getStreamerClass() for
the caller but that turns out not to be possible when unstreaming so fuck it).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4373 542714f4-19e9-0310-aa3c-eee0fc999fb1
are now correct, but unfortunately a little more complicated.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4371 542714f4-19e9-0310-aa3c-eee0fc999fb1
type, but we don't really want to pollute our class <-> id mapping with a bunch
of extra fiddly enum classes, so we stream all enums as instances of their
declared type and let Enum.valueOf() map back to the custom derived type when
it creates an instance during deserialization.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4370 542714f4-19e9-0310-aa3c-eee0fc999fb1
value to avoid future compatibility problems if someone saves an object to a
database and then later adds a new enum anywhere but at the end of the list,
thereby changing the ordinals.
If you want maximal network efficiency, don't use enums. For most of what we'll
do with them, it doesn't merit having the future incompatibility hitch of
sending the ordinal.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4369 542714f4-19e9-0310-aa3c-eee0fc999fb1
ObjectInputStream works in conjunction with a ObjectOutputStream on the
other end. The ObjectOutputStream will always assign class codes starting
at 1 and increasing sequentially from there, so we can look up a class
by index rather than hashing.
Uses less memory and is faster.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4365 542714f4-19e9-0310-aa3c-eee0fc999fb1
otherwise we'll just get the name. I'm killing StringUtil.getMessage().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4304 542714f4-19e9-0310-aa3c-eee0fc999fb1
I was getting an IllegalArgumentException and the message was "null",
so this will at least log the name of the exception.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4263 542714f4-19e9-0310-aa3c-eee0fc999fb1
make connections to other servers in the cluster and can exchange events (in a
limited fashion).
This is different than Liz's project wherein servers share an oid space and one
can interchangably work with distributed objects from any server. This package
provides a means by which certain services (by default, presence and chat) can
be communicated between servers to allow communication between players
scattered around a bunch of otherwise independent server instances.
This is less general purpose but also less likely to encourage people to write
code that tightly couples multiple servers and then falls over because it
generates gobs of network traffic as events are flung willy nilly behind the
scenes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4238 542714f4-19e9-0310-aa3c-eee0fc999fb1
These are the preferred way to get instances of Boolean, Byte,
Short, Character, Integer, Long, Float, and Double object.
It's always made sense for Boolean objects, and with 1.5 these factory
methods were blessed as the proper way to get instances unless one
absolutely needed a distinct object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4145 542714f4-19e9-0310-aa3c-eee0fc999fb1
our streaming system should work with multidimensional arrays: in fact it
kinda already did, if the element type of the outermost array was something
for which we already had a streamer. Thus, int[][] worked, Object[][] worked,
etc. One small method change and now arbitrary multidimensional arrays
will work.
Why bother? Consistency, and the way I'm working on doing even the int[][]
arrays in actionscript supports unlimited dimensions, so why not?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3921 542714f4-19e9-0310-aa3c-eee0fc999fb1
that you're sending a giant array and having it try to allocate it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3820 542714f4-19e9-0310-aa3c-eee0fc999fb1
String marshaller as a StreamerMarshaller is used for String fields.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3651 542714f4-19e9-0310-aa3c-eee0fc999fb1
ObjectInputStream to facilitate conversion of serialized data when classes
are repackaged.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3642 542714f4-19e9-0310-aa3c-eee0fc999fb1
that authentication is processed on the dobjmgr thread rather than
requiring the caller to do the right thing (or not as the case happened to
be).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3433 542714f4-19e9-0310-aa3c-eee0fc999fb1
condition between the omgr thread and the conmgr thread. Now when the omgr
thread processes an event that is going out to the clients, it flattents
the message itself for each client that is to receive the message and the
flattened data is posted to the conmgr outgoing queue.
This means that once an event is finished processing, no further
modifications to any of the data associated with the event can effect the
data queued up to be sent to the client. This is a good thing, it will
eliminate or illuminate a very baffling class of bugs that we've sort of
been ignoring because we knew this could be the cause.
We used to take an event and flatten it directly into the direct buffer
from which we would do our socket write. Now we flatten it into a
temporary byte array. This means a metric shitload more garbage generation
and collection. We used to do the flattening on the conmgr thread, now we
do it on the omgr thread. This means a big redistribution of CPU demand.
Either of those things could result in a significant negative impact on
our performance, but we'll just have to deploy this stuff and find out.
Whee! If it turns out to be a serious problem, there are potential
optimizations that could be done by keeping a pool of direct buffers
around and flattening messages into them, relying on the fact that the
outgoing conmgr queue generally doesn't grow too large and we could
allocate tens to a hundred megabytes of memory for the outgoing queue if
we really needed to.
I'd also like to test the overflow handling stuff more. It didn't really
change in that everything just deals with arrays of bytes now instead of
unflattened messages, but I'll be more comfortable once I've seen all this
in action on ice where there may be few users, but they are just as likely
to experience lag and receive an overflow queue as users on the higher
traffic servers. There is code to log when overflow queues are created and
finally flushed and how much use they got while they were around, so that
should give us an indication of whether things are operating properly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3419 542714f4-19e9-0310-aa3c-eee0fc999fb1
flattens messages into a buffer and then passes that bucket to a
SocketChannel.write() method which is part of the NIO business. If said
buffer is a "direct" buffer, the write() method will in theory do
high-performance shit like DMA the data right to the network card. If it's
not a direct buffer, Sun apparently makes a temporary direct buffer,
copies the data into it and passes that on to the underlying socket send()
call. We weren't using direct buffers which means that we were copying
everything one more time than needed (not a huge deal) and that we were
allocating a direct buffer for every message (a much bigger deal). This
should take a serious load off of the I/O thread and fortunately we can
test it on Ice to make sure it doesn't do anything super crazy.
All this said, this whole business is going to change when I rearchitect
Presents to avoid the potential race conditions it suffers from now and we
won't be able to use a single direct buffer to write all of our outgoing
messages, but I believe we will be able to use a pool of direct buffers
with one used by every message in the queue waiting to be written
(hopefully that won't be too many at any given time) which we can keep
around to avoid the expense of allocating and freeing direct buffers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3336 542714f4-19e9-0310-aa3c-eee0fc999fb1
Dave Hoover