Overview

GigaSpaces provides a pluggable communication adaptor, LRMI (Light Remote Method Invocation). The adaptor consists of a Stub Handler that manages the client communication with the space server.

The default adaptor supports two communication protocols, RMI and NIO (default protocol):

• RMI is the standard Sun communication protocol.
• NIO provides much more scalability and efficiency when there are many concurrent connections and heavy load.

Schema

The space schema communication settings include the following elements:

<space-config>
   <lrmi-stub-handler>
      <!--name of LRMI protocol, for example: NIO, RMI-->
      <protocol-name>${com.gs.protocol}</protocol-name>
      <!--export the space to specified port number, 0 system will choose free port-->
      <server-port>0</server-port>
      <client-port>0</client-port>
      <!--maximum pool of connections to the Server-->
      <max-pool-connections>1024</max-pool-connections>
      <!--minimum/maximum worker threads in Server Connection Manager-->
      <min-worker-threads>16</min-worker-threads>
      <max-worker-threads>500</max-worker-threads>
      <is-multiplex-connection>false</is-multiplex-connection>
   </lrmi-stub-handler>
   <!--number of retries to server-->
   <retries>10</retries>
   <!--number of notify retries-->
   <notifier-retries>3</notifier-retries>
</space-config>

Options

Here are the space communication settings options:

Element	XPath Property	Description	Default value
<protocol-name>	space-config. lrmi-stub-handler. protocol-name	Name of LRMI protocol, for example: NIO, RMI.	NIO Override property: com.gs.protocol
<server-port>	space-config. lrmi-stub-handler. server-port	Server port used for incoming client requests.The server port is set by default to 0, which means next free port. This means that whenever the space server is launched it allocates one of the available ports.Define a specific port value to enforce a specific port on the space server.	0
<client-port>	space-config. lrmi-stub-handler. client-port	Client port used for incoming server requests. For example, notify-callback operations. The client port is set by default to 0, which means next free port. This means that whenever the client is launched it allocates one of the available ports.Define a specific port value to enforce a specific port on the client to be used when server approach the client.	0
<max-pool-connections>	space-config. lrmi-stub-handler. max-pool-connections	Relevant only for NIO protocol.Client connection pool maximum size to server. Starts with 1 connection.	1024
<min-worker-threads>	space-config. lrmi-stub-handler. min-worker-threads	Relevant only for NIO protocol. GigaSpaces maintains thread pool in Client and Server that manage incoming remote requests. The thread pool size is increased each time with one additional thread and shrinks when existing threads are not used for 5 minutes. This parameter specifies the minimum size of this thread pool.	16
<max-worker-threads>	space-config. lrmi-stub-handler. max-worker-threads	Relevant only for NIO protocol. This parameter specifies the maximum size of this thread pool.You should make sure the pool max size will accommodate the maximum number of concurrent requests to the space. The client using this pool for server requests into the client side - i.e. notify callbacks. When the pool is exhausted and all threads are consumed to process incoming requests, additional requests will be blocked until existing requested processing will be completed.	500
<is-multiplex-connection>	space-config. lrmi-stub-handler. is-multiplex-connection	Boolean value. This property should be set to true if there are many remote concurrent connections to the space. When this parameter set to false the space opens a dedicated network channel and a thread for each remote client. These network channel consumes resources. In general when running in is-multiplex-connection=false the space generates and maintains a thread per connection. This is very expensive both in terms of CPU and memory when having many users. The is-multiplex-connection=false is relevant only for very few concurrent connections (1-3). To optimize the space handling with concurrent access configure the <is-multiplex-connection> to have its value as true. This allows the space to share the same network channel and thread for multiple concurrent clients. Make sure you run in is-multiplex-connection=true when having more than 3 concurrent connections to the space. If is-multiplex-connection=false, the space disregards the parameters you configure, and also does not limit the thread number.	Starting with GigaSpaces 5.2 default is true
<retries>	space-config. retires	This parameter should be modified when connecting to a remote space and there is a heavy load and/or unreliable network which may cause a communication failure. In such scenario the space proxy detects this and tries to re-invoke the failed operation. The following specifies the number of retries. The default is 10. It applies both to the client proxy and to the space server (on callbacks).	10
<notifier-retries>	space-config. notifier-retires	The space may lose its connection to the client's Notify proxy for various reasons. In the event of such a failure, the server tries to reconnect and send the notification to the client. This value specifies the maximum number of times the space tries to reconnect to the client. There is a two-second delay between each retry attempt. If the space succeeds in connecting to the proxy before reaching the maximum number of retries (for example, if it connects on the second try, and Notify Retries is set to 3), it transmits the notification. If it reaches the maximum number of retries and still has not established the connection, it erases the notify template without notifying the client. You may use values as high as 10, but note that repeated connection attempts by the server demand resources and may slow down other operations.	3

Overriding Client LRMI Settings

Since the space client uses global LRMI settings configured as part of the space schema, you might want to override these to have a smaller connection thread pool.

The client LRMI settings are defined per proxy. You can override the global LRMI settings using the properties file handed to the client URL.

The properties file in our lrmi_settings can have the following:

space-config.lrmi-stub-handler.max-pool-connections=1024
space-config.lrmi-stub-handler.min-worker-threads=10
space-config.lrmi-stub-handler.max-worker-threads=20

The properties file needs to be placed under the <GigaSpaces Root>\config directory. For more details, refer to the Overwriting Schema Settings in Runtime section.

The client URL:

Jini://*/*/mySpace?properties=lrmi_settings

Configuration with Multi-Homed Machines When working with a multi-homed machine (a computer with multiple network cards), use the following system property to bind the GigaSpaces Server on a specified network interface: -Djava.rmi.server.hostname=<hostname or IP address>. The value of this property represents the host name string that must be associated with the network interface. The default value of this property is the IP address of the local host, in "dotted-quad" format.

Troubleshooting

You can troubleshoot the space activity using LRMI logging. You can turn on LRMI logging in the following modes:

Offline mode – via gs_logging.properties

1. Open <GigaSpaces Root>/config/gs_logging.properties
2. Locate the following line:

   com.gigaspaces.lrmi.level = INFO

3. Set debug logger granularity level:
   • ALL – all debug messages available for LRMI.
   • FINE – configuration, watchdog, client connections (connect/disconnect).
   • FINER – content and execution state of remote method invocation on remote object.
   • SEVER – caught exceptions by LRMI on server and client side.
4. Save and close the gs_logging.properties file.
5. Start a space: <GigaSpaces Root>/bin/gsInstance.

LRMI communication transport protocol debug messages are displayed.

During Runtime – using JMX

1. Start gsInstance using the following Java system properties:

   -Dcom.sun.management.jmxremote.port=5001
   -Dcom.sun.management.jmxremote.ssl=false
   -Dcom.sun.management.jmxremote.authenticate=false

2. Start jconsole – copy the JMX URL to the JConsole.
3. Click Connect.

   

4. Set com.gigaspaces.lrmi with a desired log level.
5. Click setLoggerLevel.
6. A new log level is defined.

When LRMI logging is turned on, the space displays the following when started:

To test LRMI logging, you can run the space ping utility using the following command:

<GigaSpaces Root>/bin/ping myCache_container myCache -r -i 1

The space displays the following:

The client displays the following:

Troubleshooting Tip If your client application loses its connection to the server, you can follow a simple procedure to check if the server erased any of your notify templates in the interim. For each notify template, write an Entry to the space that matches the template and see if you receive a notification. If you do not receive a notification, this means that while you were disconnected, new Entries matching the notify template entered the space (you can try to find them – depending on their lease time, they may still exist). As a result, your notify template was erased.