Imaging Queue

Prior to version 8.2.3 when you restart Kognitio a global session is held while table and view images are built in Kognitio RAM. Users could not connect to Kognitio until all these image builds were completed. This also occurs during a RECLAIM.

From version 8.2.3 onwards we have added an imaging queue feature which will load the objects into Kognitio RAM in the background following a restart. The imaging queue contains an ordered list of the table and views that had an image in RAM prior to the restart and therefore need rebuilding.

Any queries submitted that depend on objects that are in the imaging queue are blocked until the imaging is completed.

To retain similar behaviour to previous versions (<8.2.3) the imaging queue can be disabled by setting the parameter imgqueue_threads to 0. If this is set as a session parameter it will affect any CREATE IMAGE issued by that session only, the image queue builds images synchronously.

When a CREATE IMAGE <admin-createimage> command is run and the imaging queue is active any jobs that are currently running on the image queue are aborted then the queue is restarted and automatically re-populated.

The imaging queue does not include Kognitio System Tables these are handled by a different process. If Kognitio is restarted with a CREATE SYSTEM IMAGE then the imaging queue will be empty.

System information for the imaging queue

The virtual system table IPE_IMAGING_QUEUE has been added to show progress in the imaging queue and also allows jobs to be aborted.

Columns include:

  • elapsed_time - time taken for the image creation (so far when the job is running)

  • status - zero if there was no error on imaging the Kognitio return code otherwise

  • imaging_status - status of the image:


    Imaging Status


    Waiting in queue


    Failed - see text column for details


    Running - image being created


    Imaged sucessfully - completed successfully


    Comment has been written the text column

  • abort - used to abort selected running or queued jobs by setting it to 1 for the specific rows. This will have no effect on already completed jobs

  • text - The SQL command to run the imaging plus additional comments if:

    1. The imaging queue has never been populated (which is the case if Kognitio came up with image re-use)

    2. The imaging queue has completed all of its jobs

    3. The imaging queue is waiting for the global session lock (if a session has done CREATE IMAGE and is still connected).

IPE_IMAGING_QUEUE retains the jobs after completion until the next CREATE IMAGE is executed.

Note that the imaging queue sessions or transactions can not be aborted using the virtual tables IPE_ALLCURTRANS or IPE_ALLCURSESSIONS, or the parameters abort_session or abort_session_tx. They can only be aborted by updating the abort column in IPE_IMAGING_QUEUE.

Errors associated with failed imaging

When running SQL queries users will see:

CI30F2: Operation not valid on <object> because it has an invalid image

If a table or view they are using doesn’t have a valid image because its imaging failed in the Imaging Queue. This could be because imaging failed with an out of memory error or it was cancelled in the Imaging Queue. .

This error can be solved by trying to manually CREATE VIEW IMAGE or CREATE TABLE IMAGE and addressing any issues that arise or by simply dropping the image.