RedDwarf Server 0.10.1 API

Complete implementation of the RedDwarf Server.

See:
Description

External API

com.sun.sgs.app	Provides the interface to the RedDwarf Server used by application developers.
com.sun.sgs.app.util	Provides utilities for use by RedDwarf Server application developers.
com.sun.sgs.internal	Provides implementation hooks for a RedDwarf Server to configure the underlying behavior of the system.
com.sun.sgs.protocol.simple	Protocol specification classes.

Internal API

com.sun.sgs.auth	Provides interfaces for identities and how to authenticate them.
com.sun.sgs.kernel	Provides the core system interfaces used by the RedDwarf Server.
com.sun.sgs.kernel.schedule	Provides queue ordering and retry behavior abstractions that may be used by scheduler implementations.
com.sun.sgs.management	Provides the RedDwarf management interfaces exposed via JMX.
com.sun.sgs.nio.channels	Defines asynchronous channels that are connected to a stream-oriented connecting or listening socket, or a datagram-oriented socket.
com.sun.sgs.nio.channels.spi	Service-provider classes for the com.sun.sgs.nio.channels package.
com.sun.sgs.profile	Interfaces used to create profiling information.
com.sun.sgs.protocol	Provides interfaces for the protocol layer.
com.sun.sgs.service	Provides interfaces and classes for services provided by the RedDwarf Server.
com.sun.sgs.service.store	Provides interfaces and classes for pluggable data stores of DataService implementations.
com.sun.sgs.service.store.db	Provides a database abstraction layer for use by the default implementation of the DataStore class.
com.sun.sgs.service.task	Provides interfaces and classes for pluggable TaskService implementations.
com.sun.sgs.transport	Provides interfaces for the transport layer.

Implementation

com.sun.sgs.impl.app.profile	Provides manager implementations that support profiling.
com.sun.sgs.impl.auth	Provides simple implementations for identities and how to authenticate them.
com.sun.sgs.impl.kernel	Provides an implementation of the RedDwarf Server kernel.
com.sun.sgs.impl.kernel.logging	Provides transactional logging facilities.
com.sun.sgs.impl.kernel.schedule	Provides scheduling facilities for the kernel.
com.sun.sgs.impl.nio	Implements asynchronous IO as specified by the package com.sun.sgs.nio.channels.
com.sun.sgs.impl.profile	Provides an implementation for some interfaces in com.sun.sgs.profile.
com.sun.sgs.impl.profile.listener	Provides implementations for ProfileListener.
com.sun.sgs.impl.profile.util	Provides utilities useful for profiling implementations.
com.sun.sgs.impl.protocol.simple	Provides an implementation of the protocol layer APIs using the SimpleSgsProtocol.
com.sun.sgs.impl.service.channel	Provides an implementation of ChannelManager.
com.sun.sgs.impl.service.data	Provides an implementation of DataService.
com.sun.sgs.impl.service.data.store	Provides facilities for storing objects used by DataServiceImpl.
com.sun.sgs.impl.service.data.store.db.bdb	Provides an implementation of the interfaces in the com.sun.sgs.service.store.db package based on Berkeley DB.
com.sun.sgs.impl.service.data.store.db.je	Provides an implementation of the interfaces in the com.sun.sgs.service.store.db package based on Berkeley DB Java Edition.
com.sun.sgs.impl.service.data.store.net	Provides an implementation of DataStore that supports clients communicating to a shared data store server over the network.
com.sun.sgs.impl.service.nodemap	Provides an implementation of NodeMappingService.
com.sun.sgs.impl.service.nodemap.affinity	Provides classes, interfaces, and utilities used to find affinity groups with the label propagation algorithm (LPA).
com.sun.sgs.impl.service.nodemap.affinity.dgb	Provides classes for a multi-node distributed graph builder implementation of the label propagation algorithm described in "Near linear time algorithm to detect community structures in large-scale networks" by Raghavan, Albert and Kumara (2007).
com.sun.sgs.impl.service.nodemap.affinity.dlpa	Provides classes for a multi-node, distributed algorithm implementation of the label propagation algorithm described in "Near linear time algorithm to detect community structures in large-scale networks" by Raghavan, Albert and Kumara (2007).
com.sun.sgs.impl.service.nodemap.affinity.dlpa.graph	Provides classes used to create the graphs for the fully distributed label propagation algorithm implementation.
com.sun.sgs.impl.service.nodemap.affinity.graph	Provides classes used to build graphs used by the label propagation algorithm (LPA).
com.sun.sgs.impl.service.nodemap.affinity.single	Provides classes for a single node implementation of the label propagation algorithm described in "Near linear time algorithm to detect community structures in large-scale networks" by Raghavan, Albert and Kumara (2007).
com.sun.sgs.impl.service.nodemap.policy	Provides implementations of NodeAssignPolicy.
com.sun.sgs.impl.service.session	Provides an implementation of ClientSessionService.
com.sun.sgs.impl.service.task	Provides an implementation of TaskService.
com.sun.sgs.impl.service.transaction	Provides an implementation of transactions.
com.sun.sgs.impl.service.watchdog	Provides an implementation of WatchdogService.
com.sun.sgs.impl.sharedutil	Provides common utility classes.
com.sun.sgs.impl.sharedutil.logging	Provides utility classes for customizing logging.
com.sun.sgs.impl.transport.tcp	Provides an implementation of the transport layer APIs using TCP.
com.sun.sgs.impl.util	Provides miscellaneous utility classes and methods.
com.sun.sgs.impl.util.lock	Provides utility classes for managing locks.

Complete implementation of the RedDwarf Server.

Implementation-specific information

Configuration properties

See this document for a list of configuration properties supported by the current implementation of the RedDwarf Server.

Additional Protocol Semantics

In addition to the semantics for protocol messages given in SimpleSgsProtocol, the current implementation of the RedDwarf Server provides the following semantics for messages:

• If a RedDwarf server receives a message with an Opcode other than those specified in the protocol specification, or with an Opcode that defines a message that should only be sent to a client, or the message is malformed in other ways, the server will disconnect the client session that was the origin of the message;
• If the server receives a message from a client that is not currently logged in, and the message is not a LOGIN_REQUEST, the message will be ignored;
• If the server receives a LOGIN_REQUEST that specifies the same identity as an existing user, the behavior of the server is determined by the value of the com.sun.sgs.impl.service.session.allow.new.login property. If the value of that property is false (the default value) the new login is not permitted and the server responds with a LOGIN_FAILURE. If the value of the property is true, the user's existing session is disconnected, and a new login is allowed to proceed.

At this time, the RedDwarf Server does not implement a response to the RECONNECT_REQUEST Opcode. The current implementation treats such a request as an unknown Opcode and will disconnect any client sending such a request. Similarly, the current implementation of the RedDwarf server will not send messages beginning with the RECONNECT_SUCCESS or RECONNECT_FALURE Opcodes.

Modifications and updates to managed objects

You can using logging to obtain information about instances of ManagedObject that were modified without being marked for update. Developers can use this information to help determine if they can safely disable the automatic detection of object modifications — see the documentation for the com.sun.sgs.impl.service.data.DataServiceImpl.detect.modifications property.

Information about managed objects that were modified and not marked for update is logged to the Logger named com.sun.sgs.impl.service.data.DataServiceImpl.detect.modifications at level FINEST. This logging is only performed if detection of modifications is enabled.

API conventions

Interfaces in this API do not extend Serializable even if classes that implement those interfaces are required to implement it.

The API uses this approach to avoid an issue involving the serialVersionUID field. To guard against serialVersionUID mismatches, as well as to improve performance, any class or interface that extends Serializable should declare a serialVersionUID field. Since public interfaces can only declare public members, a public interface that extends Serializable would need to have a public serialVersionUID field, meaning that any classes implementing the interface would inherit its serialVersionUID, and so would be prevented from controlling their versioning separately. This issue does not crop up for interfaces that do not extend Serializable, since they by definition have a serialVersionUID of 0.

Documentation conventions

Unless explicitly specified otherwise, all documentation for these APIs uses the following conventions:

• If null is not explicitly specified as an acceptable value for a method parameter, then the method does not permit null to be passed as a value for that parameter, and will throw a NullPointerException if null is passed (though it is left unspecified whether or not NullPointerException takes precedence over other types of exceptions that could also be thrown).
• If null is not explicitly specified as an acceptable value for a method to return, then the method is not permitted to return null.
• If null is not explicitly specified as an acceptable value for a given collection (e.g. Collection, List, or Set) to contain, then the collection is not permitted to contain null elements.

Methods that can accept or return null values generally specify this at least in their parameter-level (i.e. @param tag) or return value-level (i.e. @return tag) documentation.