Menu
▾
▴
#2809 imm: A client may not be informed about an invalidated OI if it becomes invalid without an immnd restart
An OI used by an IMM client becomes invalid if a synchronous request is made by the client while immnd is unavailable for some reason, the request is timedout. The client now having an invalid OI is not made aware about that this has happened so no restore will be done by the client.
The consequence is that operations on objects that shall be handled by the OI will not trig any OI events and the operations will fail
Several solutions has been discussed. One solution that is dicussed is to use the AMF feature described in the AMF PR document section; "2.2.8 Periodic Component Monitoring with Commands" and create a program that periodically reads a file and expects a timestamp to have been updated. If the timestamp is not updated within a defined time immnd is aborted (SIGABORT). The immnd is responsible to update the timestamp. The timeout should be short e.g. 1 sec
I suggest that also the following is considered:
1. Immnd: Handle old already timed out requests from a client.
An example: A client has requsted to create a runtime object. The immnd is for some reason so slow in answering the request so the reply has already been timed out by the imm agent (mds reply timeout). Because of the timeout the client does not know wether the object was created or not and has cancelled the operation that needed the object. If this object is created anyway by immnd we have a "rouge" object.
Proposal: Let the agent give each request a "best before" timestamp that is related to when the request is timed out. In immnd the message is just "thrown away" if it is read after the "best before" time.
Note: A similar solution already exist in the log service.
If lots of messages (requests) are sent to the immnd there is a risk of getting tipc overload meaning that messages will be lost. If very big (tipc) buffers are used there is a risk that (1.) will happen. To minimize the risk that this will happen some sort of "overload protection" should be implemented.
Proposal: Use an internal buffer in immnd and and two thresholds hi and low. The built in mailbox buffer in the mailbox used between the mds thread and the event handling thread could be used. If the number of buffered (not yet handled) messages reaches the hi threashold immnd starts to throw all incoming messages and replies with TRY AGAIN for all requests. The sender must now slow down message sending using a delay before trying to send a new request (trying again). In the mean time immnd continues to service buffered events. When the buffer reaches the low threashold immnd start adding messages to the buffer again.
Note: A similar solution already exist in the log service.