public class

ConfiguredServer

extends Object
implements OnAccept OnClose OnData
java.lang.Object
   ↳ com.ericsson.research.trap.examples.ConfiguredServer

Class Overview

This example focuses on tweaking a server's configuration. Not all options here are applicable to all applications, but they should provide a good overview of how a listener can be tweaked. 

INCLUDE_ERROR

Summary

Public Constructors
ConfiguredServer()
Public Methods
void incomingTrapConnection(TrapEndpoint endpoint, TrapListener listener, Object context)
Called on an incoming Trap connection.
static void main(String[] args)
Creates a new configured server
void trapClose(TrapEndpoint endpoint, Object context)
Called when the endpoint changes state from OPEN or CLOSING to CLOSED, that is, when Trap orderly disconnects.
void trapData(byte[] data, int channel, TrapEndpoint endpoint, Object context)
Called when the Trap endpoint has received byte data from the other end.
[Expand]
Inherited Methods
From class java.lang.Object
From interface com.ericsson.research.trap.delegates.OnAccept
From interface com.ericsson.research.trap.delegates.OnClose
From interface com.ericsson.research.trap.delegates.OnData

Public Constructors

public ConfiguredServer ()

Public Methods

public void incomingTrapConnection (TrapEndpoint endpoint, TrapListener listener, Object context)

Called on an incoming Trap connection. The new endpoint is in OPEN, and can immediately be used to send messages. Messages will not begin to be dispatched to this endpoint until after this method has returned. Like most other callbacks, this should execute and return quickly.

The endpoint received using this method is only weakly referenced by Trap, and is thus eligible for garbage collection. Delegates must store a strong reference to the endpoint if they wish to use it.

While the endpoint is ready-to-use, it is blocked until the method returns. Consequently, all potentially-destructive operations on the endpoint, such as TrapEndpoint#setQueue(com.ericsson.research.trap.spi.MessageQueue) can safely be performed at this time. These methods should not be called after this method has returned, however.

Parameters
endpoint The new TrapEndpoint representing the created connection.
listener The TrapListener that called this delegate. Useful for when a delegate manages multiple listeners.
context Caller-specific context that was supplied when the delegate was registered.

public static void main (String[] args)

Creates a new configured server

Parameters
args Ignored
Throws
Throwable Hopefully not

public void trapClose (TrapEndpoint endpoint, Object context)

Called when the endpoint changes state from OPEN or CLOSING to CLOSED, that is, when Trap orderly disconnects. If OnError is not specified, this method will also be called should the endpoint change state to ERROR from any state.

Parameters
endpoint The endpoint that changed state to CLOSED.
context The delegate context, if specified by setDelegateContext(Object), or null otherwise.

public void trapData (byte[] data, int channel, TrapEndpoint endpoint, Object context)

Called when the Trap endpoint has received byte data from the other end. This method executes in a Trap thread, so it should only perform minimal operations before returning, in order to allow for maximum throughput.

Threading Considerations

In the default -- and recommended -- asynchronous mode (see setAsync(boolean) for a discussion about that), trapData may be called concurrently when multiple channels are used. This occurs when the client uses different channel IDs to send data. Within a single channel ID, however, trapData will only be called by one thread at a time.

For example, suppose the client sends messages on both channels 1 and 2. This means trapData can be called from two threads concurrently. The first thread will handle the data for channel 1, and the second will receive the data for channel 2. It is therefore important to synchronise any data structures shared between the two channels. In the best-case scenario, the two channels can work completely independent, and thus achieve full parallelism.

If the client only ever sends data on a single channel, this method will never be called by multiple threads, and does thus not need to be synchronised.

Parameters
data The data received. The ownership of this array is transferred to the receiver. It will not be overwritten by Trap, and Trap will not read any changes off of it.
channel The Channel ID on which this data was received.
endpoint The TrapEndpoint that received the data.
context The original context object supplied to the TrapEndpoint for this delegate. Will be null if no context was supplied.