| java.lang.Object
 org.cougaar.tools.server.OutputPolicy
| OutputPolicy | | final public class OutputPolicy implements java.io.Serializable(Code) | | Immutable class that allows the client to indicate its listening
preferences to the server (buffering, frequency, etc).
The client can send a OutputPolicy to the RemoteHost when
it creates the RemoteProcess or can later send a new
OutputPolicy to a running RemoteProcess to alter its
preferences.
See Also: OutputListener
See Also: RemoteProcess |
| Method Summary | |
| public int | getBufferSize()
NodeEvent buffering size and policy:
> 1: The server will buffer process output until at most that many
are ready to be sent in a
OutputListener.handleAll(..) --
The server can impose an upper-bound that is less than
Integer.MAX_VALUE at it's discretion (For example, never
buffer more than 1000 NodeEvents) and/or flush a smaller
number of buffered NodeEvents at any time (For example, the
server can send if it's memory is running low)
1 or 0: No buffering -- the server will use
OutputListener.handle(..) to send each NodeEvent
separately, which is significantly less efficent than "> 1"
but allows for continual updates
< 0: Similar to the "> 1" case, but the server will discard
buffered NodeEvents in excess of the Math.abs(..) of the
specified amount instead of pushing them on the Client,
which means that the Client must use
RemoteProcess.flushOutput() to periodically
request the buffered NodeEvents -- For example, "-100" tells
the server to buffer at most 100 output and then discard
to prevent overflow, where the server might decide to throw
away the oldest 25 NodeEvents in the buffer if the buffer
size grows over 100
.
These definitions are intentionally ambiguous to prevent the Client
from burdening the server. | | public String | toString()
|
| OutputPolicy | | public OutputPolicy()(Code) | | |
| OutputPolicy | | public OutputPolicy(int bufferSize)(Code) | | |
| getBufferSize | | public int getBufferSize()(Code) | | NodeEvent buffering size and policy:
> 1: The server will buffer process output until at most that many
are ready to be sent in a
OutputListener.handleAll(..) --
The server can impose an upper-bound that is less than
Integer.MAX_VALUE at it's discretion (For example, never
buffer more than 1000 NodeEvents) and/or flush a smaller
number of buffered NodeEvents at any time (For example, the
server can send if it's memory is running low)
1 or 0: No buffering -- the server will use
OutputListener.handle(..) to send each NodeEvent
separately, which is significantly less efficent than "> 1"
but allows for continual updates
< 0: Similar to the "> 1" case, but the server will discard
buffered NodeEvents in excess of the Math.abs(..) of the
specified amount instead of pushing them on the Client,
which means that the Client must use
RemoteProcess.flushOutput() to periodically
request the buffered NodeEvents -- For example, "-100" tells
the server to buffer at most 100 output and then discard
to prevent overflow, where the server might decide to throw
away the oldest 25 NodeEvents in the buffer if the buffer
size grows over 100
.
These definitions are intentionally ambiguous to prevent the Client
from burdening the server. If the Client requires a more strict
definition (time-frequency, etc) then it must poll.
The Client can use RemoteProcess.flushOutput() to
flush all buffered NodeEvents.
Note that NodeEvent's of type NodeEvent.HEARTBEAT are
not buffered -- these simply allow the server to track the
existence of the Client and destroy itself if the Client dies!
|
|
|