Memory Queue Connector

You can use the Memory Queue (MemQueue) Connector to read and write to the memory queue feature (aka. MemBufferQ).

This is an alternative to writing script to access a memory queue and is an extension of the Memory Queue Function Component (function component).

The objects used to communicate between components are not persistent and are not capable of handling large return sets. For example, large data returned by an ldapsearch operation. In order to solve this problem, an internal threadsafe memory queue can be used as a communications data structure between AL components. It can contain embedded logic that would trigger whenever buffer is x% full/empty/data available.

There can be multiple readers and writers for the same queue. Every writer has to obtain a lock before adding data. The writer has to release lock before a reader can access it. Connectors in Iterator mode have a parameter that determines when the read lock is released – After single read, on AL cycle end or Connector close.

This Connector supports AddOnly and Iterator modes only.

Note:

Because of the non-persistent nature of this Connector, we recommend that you use the System Queue Connector instead, because that Connector relies on the underlying Java Messaging Service (JMS) functionality with persistent object storage.
When the Memory Queue Connector is in Iterator mode it reads from the configured queue. If that queue does not exist it is created. If you don't want this behavior, you need to set the system property tdi.memq.create.queue.default=false, in this case IBM Security Directory Integrator will behave like previous versions; this implies that when the queue does not exists, an exception is thrown in Iterator Mode.

This Connector can also be used in connection with MemQueue pipes set up from JavaScript, although it is important to note that a MemQueue pipe created by the MemQueue Connector will be terminated when the Connector closes.

The Memory queue buffer is a FIFO type of data structure, where adding and reading can occur simultaneously. It works as a pipe where additions happen at one end and reading happens at the other end and reading removes the data from queue.

The Memory queue buffer provides overflow storage using the System Store when a threshold value is reached, which is a function of the runtime memory available.