Restructuring of Framework Remote Component Update 1

Restructuring of Framework Remote Component Update 1

Lack of Topic Data Buffer Release

Immediately after publishing the last post – Restructuring of Framework Remote Component – I found that Remote Register Complete topic still wasn't treated correctly in all circumstances.

Looking into this I finally found that it didn't really have anything to do with this topic per se.  Instead, it was due to a topic that the framework, upon its being published, determines that it is to be transmitted.  When this is the case the framework copies the data to a record that is added to the Transmit Queue and invokes a procedure to release the data buffer.

The problem is that the Release procedures, except for one, only release the data buffer if it has been marked as being read; i.e., that a Reader has been instantiated for the topic instance.  When the framework just copies it into the Transmit Queue this doesn't happen.  Therefore, the data buffer wasn't being released.  Since the topic was specified as one to use multiple buffers the next time a writer for the topic was instantiated for the same producer another data buffer was assigned. 

Since the Remote component is both the publisher and the consumer of this topic, a new buffer could be assigned upon the publish of a received message from another application.  Then, when Remote, as the consumer component, read the topic it got the oldest of the multiple data buffers.  Depending upon the timing, this could be the instance that the application transmitted to another app rather than the one received.

In trying to determine why this was taking place I happened to see the one Release procedure that also checked whether the Reference Numbers matched when the Being Read boolean was not set.  I reasoned that this was because at some time in the past I had found the same problem for a different method of topic delivery and had corrected the problem in this manner.  That is, looking for a matching Reference Number when the topic didn't have Being Read set indicating that it had been transmitted rather that delivered to a local component that had instantiated a Reader.

I updated each of the various Release procedures to also make a similar check if the procedure was being called following transmit.  This fixed the problem.

Use of Remote Register Complete message

While locating the source of the seeming mis-delivery of the Remote Register Complete topic, the reason for needing this topic was well illustrated.  That is, the Aperiodic component of App2 sent a N-to-One request to App1 each time that it ran if there was a connection to App1.  However, until the Remote Register messages were received and treated sometime after the connection, the remote app – in this instance App1 – didn't know what to do with the Response.

Therefore, the response wasn't transmitted back to App2 and its data buffer didn't get released.  In this situation the topic wasn't one that specified multiple data buffers.  Therefore, the next time such a topic was received from App2, the response couldn't be created because the data buffer was still in use.

Also, a table exists to match responses to received requests to look up where to transmit the response.  With no response to match a request, received requests kept being added to the table until its limit was reached.

This was fixed – as point 4) in the previous post mentioned that it would be – by changing when the Writer could obtain a data buffer for a topic to be transmitted.  Instead of only requiring that there be a connection to the remote app that is to consume the topic, another consideration was added.  When the topic is a non-registration topic, Remote Register Complete also has to have been received from the remote app to which the topic message is to be transmitted.

This prevented topic data buffers being created, and hence written and published, until the remote application is ready to fully treat them.