Home >> All >> org >> jboss >> [ invocation Javadoc ]

•	org.jboss.invocation.http.* (17)	•	org.jboss.invocation.iiop.* (8)	•	org.jboss.invocation.jrmp.* (7)
•	org.jboss.invocation.local.* (1)	•	org.jboss.invocation.pooled.* (10)

• org.jboss.invocation: Javadoc index of package org.jboss.invocation.


Package Samples:

• org.jboss.invocation.http.interfaces
• org.jboss.invocation.http.server
• org.jboss.invocation.jrmp.interfaces
• org.jboss.invocation.jrmp.server
• org.jboss.invocation.iiop
• org.jboss.invocation.local
• org.jboss.invocation.pooled.interfaces
• org.jboss.invocation.pooled.server
• org.jboss.invocation.http.servlet

Classes:

• IIOPInvoker: IIOP invoker that routs IIOP requests to CORBA servants. It implements the interface ServantRegistries , which gives access to four ServantRegistry instances: a ServantRegistry with a single transient POA shared among all its servants; a ServantRegistry with a single persistent POA shared among all its servants; a ServantRegistry with a transient POA per servant; a ServantRegistry with persistent POA per servant. CORBA servants registered with any of these ServantRegistry instances will receive IIOP invocations. These CORBA servants will typically be thin wrappers that merely forward to the JBoss ...
• MarshalledInvocation: The MarshalledInvocation is an invocation that travels. As such it serializes its payload because of lack of ClassLoader visibility. As such it contains Marshalled data representing the byte[] of the Invocation object it extends Besides handling the specifics of "marshalling" the payload, which could be done at the Invocation level the Marshalled Invocation can hold optimization and needed code for distribution for example the TransactionPropagationContext which is a serialization of the TX for distribution purposes as well as the "hash" for the methods that we send, as opposed to sending Method ...
• PooledMarshalledInvocation: The MarshalledInvocation is an invocation that travels. As such it serializes its payload because of lack of ClassLoader visibility. As such it contains Marshalled data representing the byte[] of the Invocation object it extends Besides handling the specifics of "marshalling" the payload, which could be done at the Invocation level the Marshalled Invocation can hold optimization and needed code for distribution for example the TransactionPropagationContext which is a serialization of the TX for distribution purposes as well as the "hash" for the methods that we send, as opposed to sending Method ...
• PooledInvoker: This invoker pools Threads and client connections to one server socket. The purpose is to avoid a bunch of failings of RMI. 1. Avoid making a client socket connection with every invocation call. This is very expensive. Also on windows if too many clients try to connect at the same time, you get connection refused exceptions. This invoker/proxy combo alleviates this. 2. Avoid creating a thread per invocation. The client/server connection is preserved and attached to the same thread. So we have connection pooling on the server and client side, and thread pooling on the server side. Pool, is an LRU ...
• PooledInvokerHA: This invoker pools Threads and client connections to one server socket. The purpose is to avoid a bunch of failings of RMI. 1. Avoid making a client socket connection with every invocation call. This is very expensive. Also on windows if too many clients try to connect at the same time, you get connection refused exceptions. This invoker/proxy combo alleviates this. 2. Avoid creating a thread per invocation. The client/server connection is preserved and attached to the same thread. So we have connection pooling on the server and client side, and thread pooling on the server side. Pool, is an LRU ...
• InvocationContext: The Invocation Context Describes the context in which this Invocation is being executed in the interceptors The heart of it is the payload map that can contain anything we then put readers on them. The first "reader" is this "Invocation" object that can interpret the data in it. Essentially we can carry ANYTHING from the client to the server, we keep a series of redifined variables and method calls to get at the pointers. But really it is just a repository of objects.
• ServerThread: This Thread object hold a single Socket connection to a client and is kept alive until a timeout happens, or it is aged out of the PooledInvoker's LRU cache. There is also a separate thread pool that is used if the client disconnects. This thread/object is re-used in that scenario and that scenario only. This class will demarshal then delegate to PooledInvoker for invocation. *NOTES* ObjectStreams were found to be better performing than the Custom marshalling done by the TrunkInvoker.
• Invocation: The Invocation object is the generic object flowing through our interceptors. The heart of it is the payload map that can contain anything we then put readers on them. The first reader is this Invocation object that can interpret the data in it. Essentially we can carry ANYTHING from the client to the server, we keep a series of of predifined variables and method calls to get at the pointers. But really it is just a repository of objects.
• InvokerServlet: This servlet accepts a post containing a MarshalledInvocation, extracts the Invocation object, and then routes the invocation via JMX to either: 1. the MBean specified via the invokerName ini parameter 2. the MBean whose object name hash is specified by the invocation.getObjectName() value. This name's hash must have been entered into the Registry. The method signature of the invoker must be Object invoke(org.jboss.invocation.Invocation).
• ReferenceData: Helper class used to create a byte array ("reference data") to be embedded into a CORBA reference and to extract object/servant identification info from this byte array. If this info consists simply of an objectId , this id is serialized into the byte array. If this info consists of a pair (servantId, objectId), a ReferenceData instance containing the pair is is serialized into the byte array.
• HttpInvokerProxyHA: The client side Http invoker proxy that posts an invocation to the InvokerServlet using the HttpURLConnection created from a target url. This proxy handles failover using its associated LoadBalancePolicy and current list of URL strings. The candidate URLs are updated dynamically after an invocation if the cluster partitation view has changed.
• NamingFactoryServlet: Create a Naming interface proxy that uses HTTP to communicate with the JBoss JNDI naming service. Any request to this servlet receives a serialized object stream containing a MarshalledValue with the Naming proxy as its content. The proxy is obtained from the MBean named by the namingProxyMBean init-param.
• HttpProxyFactoryHA: An extension of HttpProxyFactory that supports clustering of invoker proxies. It does this by creating a HATarget that monitors the replication of the invoker url and creates a HAInvokerWrapper that handles wrapping the underlying invocation result with changes to the HATarget replication view.
• Invoker: This invoker carries Invocation in the JMX target node. The interface in the current JBoss can be implemented with Remote/local switches or with clustered invokers, this interface just masks the network details and the topology of the JMX nodes for the client proxies.
• HttpProxyFactory: Create an interface proxy that uses HTTP to communicate with the server side object that exposes the corresponding JMX invoke operation. Any request to this servlet receives a serialized object stream containing a MarshalledValue with the Naming proxy as its content.
• InvocationKey: Type safe enumeration used for keys in the Invocation object. This relies on an integer id as the identity for a key. When you add a new key enum value you must assign it an ordinal value of the current MAX_KEY_ID+1 and update the MAX_KEY_ID value.
• HttpProxyFactoryHAMBean: An mbean interface that extends the HttpProxyFactoryMBean to provide support for cluster aware proxies. This interface adds the ability to configure the load-balancing policy of the proxy as well as the cluster partition name the mbean belongs to.
• ServerAddress: This class encapsulates all the required information for a client to establish a connection with the server. It also attempts to provide a fast hash() function since this object is used as a key in a hashmap mainted by the ConnectionManager.
• MarshalledValueOutputStream: An ObjectOutputStream subclass used by the MarshalledValue class to ensure the classes and proxies are loaded using the thread context class loader. Currently this does not do anything as neither class or proxy annotations are used.
• JRMPProxyFactory: Create an interface proxy that uses RMI/JRMP to communicate with the server side object that exposes the corresponding JMX invoke operation. Requests make through the proxy are sent to the JRMPInvoker instance the proxy is bound to.
• OptimizedObjectOutputStream: An ObjectOutputStream subclass used by the MarshalledValue class to ensure the classes and proxies are loaded using the thread context class loader. Currently this does not do anything as neither class or proxy annotations are used.
• InvokerHA: An administrative interface used by server side proxy factories during the creation of HA capable invokers. Note that this does NOT extend the Invoker interface because these methods are not for use by an invoker client.
• MarshalledValue: A simple replacement for the RMI MarshalledObject that uses the thread context class loader for resolving classes and proxies. This currently does not support class annotations and dynamic class loading.
• PooledMarshalledValue: A simple replacement for the RMI MarshalledObject that uses the thread context class loader for resolving classes and proxies. This currently does not support class annotations and dynamic class loading.
• JRMPProxyFactoryMBean: An mbean interface for a proxy factory that can expose any interface with RMI compatible semantics for access to remote clients using JRMP as the transport protocol.

Home | Contact Us | Privacy Policy | Terms of Service