The basic idea is that when we originally connect, we give a list of as many servers as we can in the form of hostname, port. These servers are connected to and they are queried to find out about any other servers that might be in the cloud. Servers might have multiple routes, but we resolve this because each server returns a unique identifier.

When it comes time to log, we look in a topic=> server cache. If we find a preferred server there, we use it. Otherwise, we pick some server at random.

When we send a log message, the response may include a redirect to a different server. If so, we make sure that we have connected to all forms of that server's address and cache that for later. Then we retry the send to the new server. We may also cache that message for later retry.

If a log request results in an error, we try to get rid of the connection that caused us this grief. This might ultimately cause us to forget a host or even a cache entry, but we will attempt to re-open these connections later, usually due to a referral back to that host. During server cloud reorganizations, we may not re-open the same server.

{@link ClientFilter} instances may be added to the client for filteringrequests and responses, including those of {@link WebResource} instancescreated from the client.

A client may be configured by passing a {@link ClientConfig} instance tothe appropriate constructor.

Methods to create instances of {@link WebResource} are thread-safe. Methodsthat modify configuration and or filters are not guaranteed to be thread-safe.

The creation of a Client instance is an expensive operation and the instance may make use of and retain many resources. It is therefore recommended that a Client instance is reused for the creation of {@link WebResource} instances that require the same configuration settings.

A client may integrate with an IoC framework by passing a {@link IoCComponentProviderFactory} instance to the appropriate constructor. @author Paul.Sandoz@Sun.Com

A BitTorrent client in its bare essence shares a given torrent. If the torrent is not complete locally, it will continue to download it. If or after the torrent is complete, the client may eventually continue to seed it for other clients.

This BitTorrent client implementation is made to be simple to embed and simple to use. First, initialize a ShareTorrent object from a torrent meta-info source (either a file or a byte array, see com.turn.ttorrent.SharedTorrent for how to create a SharedTorrent object). Then, instantiate your Client object with this SharedTorrent and call one of {@link #download} to simply download the torrent, or {@link #share} todownload and continue seeding for the given amount of time after the download completes.

Clients are heavy-weight objects that manage the client-side communication infrastructure. Initialization as well as disposal of a {@code Client} instancemay be a rather expensive operation. It is therefore advised to construct only a small number of {@code Client} instances in the application. Client instancesmust be {@link #close() properly closed} before being disposed to avoid leakingresources. @author Marek Potociar @see javax.ws.rs.core.Configurable @since 2.0

The ClientEntry interface represents one client inside of the client registry. It is accessed by the portlet container to get information about the clients.

 Client client = ClientFactory.getDefault().newClient(); RequestBuilder request = client.newRequestBuilder() .method(Request.METHOD.GET) .uri(targetUrl + "/suspend") .decoder(new Decoder<String, POJO>() { @Override public POJO decode(String s) { return new POJO(s); } }) .transport(Request.TRANSPORT.WEBSOCKET); 

The first is dynamic mode. In this mode the WSDL is retrieved for a service, a {@link org.codehaus.xfire.service.Service} model is created from it, and it is used as metadata for the service. @author Dan

All operations performed are asynchronous by nature. Each action/operation has two flavors, the first simply returns an {@link org.elasticsearch.action.ActionFuture}, while the second accepts an {@link org.elasticsearch.action.ActionListener}.

A client can either be retrieved from a {@link org.elasticsearch.node.Node} started, or connected remotelyto one or more nodes using {@link org.elasticsearch.client.transport.TransportClient}. @author kimchy (shay.banon) @see org.elasticsearch.node.Node#client() @see org.elasticsearch.client.transport.TransportClient

 Client client = new Client(new OrkutProvider(), new OAuth2LeggedScheme(ORKUT_KEY, ORKUT_SECRET, ORKUT_ID)); Response response = client.send(PeopleService.getViewer()); 

 An application making protected resource requests on behalf of the resource owner and with its authorization.  The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices). 

A Client that connects to one or more nodes in a volt cluster and provides methods for invoking stored procedures and receiving responses. Client applications that are resource constrained (memory, CPU) or high performance (process hundreds of thousands of transactions per second) will want to pay attention to the hints that can be provided via {@link ClientFactory#createClient(int,int[],boolean,StatsUploaderSettings)} and{@link #callProcedure(ProcedureCallback,int,String,Object)}. Most Client applications will not need to generate enough load for these optimizations to matter.

A stored procedure invocation contains approximately 24 bytes of data per invocation plus the serialized sized of the procedure name and any parameters. The size of any specific procedure and parameter set can be calculated using {@link #calculateInvocationSerializedSize(String,Object) calculateInvocationSerializedSize}. This method serializes the invocation and returns the serialized size and is computationally intensive and not suitable for use on a per invocation basis.

The expected serialized message size parameter provided to {@link ClientFactory#createClient(int,int[],boolean,StatsUploaderSettings) createClient}determines the default size of the initial memory allocation used when serializing stored procedure invocations. If the initial allocation is insufficient then the allocation is doubled necessitating an extra allocation and copy If the allocation is excessively small it may be doubled and copied several times when serializing large parameter sets.

{@link #callProcedure(ProcedureCallback,int,String,Object)} allows the initial allocation to be hinted on aper procedure invocation basis. This is useful when an application invokes procedures where the size can vary significantly between invocations or procedures.

The Client performs aggressive memory pooling of {@link java.nio.DirectByteBuffer DirectByteBuffers}. The pool contains arenas with buffers that are sized to powers of 2 from 2^4 to 2^18. Java does not reliably garbage collect {@link java.nio.DirectByteBuffer DirectByteBuffers} so the pool never returns a buffer to theheap. The maxArenaSizes array passed to {@link ClientFactory#createClient(int,int[],boolean,StatsUploaderSettings)} can be usedto specify the maximum size each arena will be allowed to grow to. The client will continue to function even if the an arena is no longer able to grow. It will fall back to using slower {@link java.nio.HeapByteBuffer HeapByteBuffers} for serializing invocations.

Customizing this class is done by subclassing it, and implementing the abstract methods.

For sample implementations, you can check the socket and mux sub packages. @see ClientFactory @see org.w3c.jigsaw.http.socket.SocketClient @see org.w3c.jigsaw.http.mux.MuxClient