Message broker: missing messages on restart?
Folks,
Just wonder if other sites have run into the issue where when a message broker is shut down there are existing messages in the queue and they can't be accounted for when the system comes back up?
We had a serious back log of messages due to peak registration. I submitted a icgorodm job to create a new class late that night. When the system came back up the class wasn't created so I ran it again .. it got created shortly thereafter (with a time stamp of the event that I just fired off). Doing a grep for that CRN in the /var/imq/instances/imqbroker/fs350/message/Tcom_sct_ldi_sis_Sync/vrfile that message was there.
Shouldn't the message in the "vrfile" be processed first?
[am getting no where with SCT on this]
-Ken
problems with message queue jammed
At one time, our message queue became jammed (as number of messages arriving were more than the number of messages leaving - probably because the jvm start up overhead slows any processing down...)
We (naively) decided to increase the number of messages that the queue could handle.
Something like increase 100,000 messages to 200,000 messages.
This meant that all of Luminis processing power went on to filling up the queue which jammed quickly, and our portal could not server any of the web traffic!
A restart of the portal did not fix this, as it was trying to process the "vrfile" - cannot remember if we had any message to that effect though. We had to find a way to throw away the vrfile, and to regenerate the events (using cptool import ims). Then we had to make sure that we drip fed the queue so that it never jammed - but it did take the best part of 24hrs to process all of the events and be in a stable state.
Derek
University of Leeds, UK