A balance between: This is obnoxious, I should fix it in my subclass
and/or we should be compositing functionality, not subclassing... but
adding a time zone to this old thing seems fundamental anyway and this
is an easy fix.
This is used on multi-noded servers so that I can have a service
interface for talking to the node in charge of a particular resource,
and use the same code path even if that node is the current node.
Perhaps this be more smoothly integrated in the future but for now it's
a static utility you need to manually set up.
ProjectX uses Guice to inject dependencies and this results in some random
manager having a dependency on the concrete server class, which invariably is
getting inject itself at the time this dependency has to be resolved, which
causes circular dependencies.
Guice was able to thread the needle with other sneaky business in some cases,
but also sometimes not. So let's give it a nice interface that it can proxy to
manage this particular circular dependency.
If the frame happens to be exactly the same size as the buffer capacity, we
will erroneously think that the last frame was complete because the limit is
normally at the buffer capacity.
This only exploded when we had both a perfectly sized frame and failed to read
it in a single call to read, which apparently took 17 years to happen, and many
billions of frames read.
Sometimes a present node uses a port to connect outwards that another
node is listening on.. I considered building-in some smarts for this
into the peer stuff, but for now at least I'll keep it simpler and
more flexible.
This reverts commit ec47182263.
Ummm? I misread the code? So embarassing. For some reason I thought it
was using the public hostname for all connections. Perhaps I misread
the 'hostName' local variable in a PeerNode method for the 'hostName'
in the record.
We can't include things with unpredictable iteration order (sets, maps) in our
wire test, but we still want to test those things in our GIANT STREAMABLE CLASS
OF DOOM test. So we now have a separate wire format test which just ensures
that we don't spuriously break the encoding of things that should be
predictable.
If we're going to tell you to use an ArrayList instead of toArray(), let's make
that easy. This would be unnecessary if there was an ArrayList constructor that
took Iterable, but there isn't. And DSet is not a Collection.
Every time a client logs on and back off, another DatagramReader thread
is left around. This seems to fix it, but this method should be called
when either the reader or writer shut down..
Also: the didExit methods look funny:
/**
* Callback called by the datagram writer thread when it goes away.
*/
protected synchronized void datagramWriterDidExit ()
{
// clear out our writer reference
_datagramWriter = null;
if (_datagramReader == null) {
closeDatagramChannel();
}
log.debug("Datagram writer thread exited.");
}
Why would it only try to shut things down if there's no reader?
Perhaps the idea here is that it won't shut down the channel until
both the reader and writer exit? It's not documented...
This has been happening for a while on PX and I've been meaning to track
it down. When a peer shuts down an object that's proxied on other peers,
the other peers receive an ObjectDestroyedEvent, and clear the object
from their omgrs. Other listeners may also receive the event and will need
to clear the proxying information, but that causes an unsubscribe to be
queued up, which when it runs will find the DObject already gone, and log
an error.
At first I considered not queuing up the unsubscribe action if the object
is no longer present in the omgr, but in the case that I'm working with
we have 2 or more objects that will all be destroyed simultaneously.
Even if I test to see if the first object is around or not, this same
test would always pass for the second object even though its death event
is next on the queue. The unsubscribe would be enqueued after THAT, so
there's no test to detect that the two objects are linked.
Instead, just suppress this message if we're a peer client. I didn't
want to suppress it altogether because we might want this message logged for
normal client connections. Maybe not.
Perhaps there is a better way. Maybe the PeerNode should add its own
ObjectDeathListener and clear out the proxy information and ensure that
the proxied object is also destoyed, and clients need not unproxy manually
in that case.
RFC.
Consolidate warnings and interval scheduling in doWarning().
Don't let the reboot time drift because of delays on the RunQueue.. each
warning is scheduled based on absolute time from _nextReboot.
doWarning() now takes two args so any subclasses that had overridden
it (unlikley beyond PX) will break...
PendingShutdownObservers will now get the actual milliseconds until reboot.
Basically: after all this, things should essentially work the same except
now there is a protected three-arg version of scheduleReboot that lets you
schedule an exact time, bypassing the normal round-up to the next highest warning time.
Ray J. Greenwell