Skip to main content

Problem:

  • Product Name: Visibroker for Java
  • Product Version: 6.0, 6.5 and 7.0
  • Product Component: Gatekeeper
  • Platform/OS version: All
  • JDK: Not Applicable

A detailed information about Gatekeeper cache.

Resolution:

Purpose for the Cache

The cache function introduces an additional overhead to the Gatekeeper. The cache aims to improve the performance of the Gatekeeper by reducing the need to generate the GIOP proxy object reference for frequently used references.

Controlling Gatekeeper Cache

The vbroker.gatekeeper.cache.size allows 3 values. The value -1 means to disable the cache. The value 0 means unlimited caching. The value 64 will caches 64 GIOP proxy objects and is the default setting.

As the size of the cache can be limited, the Gatekeeper is designed to trash out those proxy objects that are idled after the vbroker.gatekeeper.cache.timeout has expired. The default setting for this property is 900 seconds. The empty slots will be inserted with the new proxy object.

Gatekeeper and GIOP Proxy

Unless the client orb is using GIOP 1.2 Absolute Address mode, the client orb has to invoke a new_target on the GIOP proxy before it communicates with the server via the GIOP proxy. The new_target call will return a new proxy object reference to the client orb. The GateKeeper remembers the mapping between the proxy object reference and the actual server reference so it can forward the messages to the servers.

When the new_target call is invoked to the Gatekeeper, the Gatekeeper performs the following tasks:

  • Bind to the target object passed by client. The target is the server which the client wants to talk to.
  • Generate a new object key based on the target's object key.
  • Ask the exterior POA to generate a new object reference - proxy object reference
  • Register the proxy object reference and the target object reference in the forward registration map.
  • Return the proxy object reference to the client

If the firewall supports GIOP 1.2 and requires a NORMAL connection, it is not necessary to invoke the new_target operation. Instead the sender (assuming it knows GIOP 1.2) can place the target IOR in the targetAddress field of the GIOPRequestHeader1_2. However, if a PASSTHRU connection using GIOP 1.2 is required, new_target must be invoked, and the resulting object should be used as the destination of the GIOP 1.2 messages.


   CbkObjectImpl cbkServant = new CbkObjectImpl(); // Create the servant
   rootPOA.activate_object(cbkServant); // Activate the Servant
   rootPOA.the_POAManager.activate(); // Activate the POA Manager
   Bank.CbkObject cbk = Bank.CbkObjectHelper.narrow(rootPOA.servant_to_reference(cbkServant));
   Bank.Account account = manager.open(accountName, cbk);

Each instance of the Bank.CbkObject will creates a new_callback call to the Gatekeeper. The new_callback will establish a GIOP proxy object in the Gatekeeper. Each instance of the Bank.AccountManager and Bank.Account will also create a GIOP proxy object in the Gatekeeper.

Performance Consideration

The cache introduces additional overheads to generate the hash key to store the GIOP proxy object and track the usage frequency of each GIOP proxy objects in the cache. If the percentage of cache hit rate is low, the performance of the Gatekeeper will be worse than without the use of cache. If the cache size is big and the GIOP proxy objects in the cache are rarely used, each cache timeout will free a large amount of GIOP proxy objects for garbage collection.


#cache
#gatekeeper
#Security
#VisiBroker