Description of problem: If the journal files should fill (ie the ability to overwrite a file is blocked by a message that has not been dequeued), then a fatal journal condition exists. This is because dequeues (which could potentially free up the journal file space) can no longer be written either, and the full condition will persist indefinitely. Plans exist to extend the journal file count under such conditions or when the management module detects a near-full condition, but will not be implememnted for this release. One possible course of action is to deny the ability to enqueue records when the file being written is within one file of the last enqueued record which will block. This should allow dequeues to contune for one file, but does not guarantee that when the last file is full, the blocking enqueued record will be dequeued.
Added a journal fullness check that is performed for each enqueue. When the journal reaches 80% full or the point where only 1 file is free (whichever is greater) as a result of the operation, an exception is thrown which results in the closing of the producer connection. Consumers may continue to dequeue, however. At present, these limits are hard-coded. RHM svn r.1474 cc 64-bit: 347 cc 32-bit: 58