[libbpmclient] Old received message on receive buffer
Closed this issue · 4 comments
Wednesday Sep 30, 2015 at 17:15 GMT
Originally opened as lnls-dig/bpm-sw#107
This problem arises from the fact that, sometimes, we give up too soon from waiting the received message. Most of the time, the message is just a bit delayed, causing the client prematurely abort the operation.
However, due to the asynchronous nature of libbpmclient, the message will arrive (eventually) and be put in the receive buffer.
On the following operation, even if the message arrives on time, there will be an earlier message in the buffer which will be mistakenly detected as the message for the current operation.
A possibility to handle this would be to use a single client instance per thread and add more information to the reply packet. For instance we could have the operation number which this reply belongs to and a sequence number to avoid detecting an earlier (and handled) message.
Wednesday Feb 24, 2016 at 01:32 GMT
This issue is related to lnls-dig/bpm-epics-ioc#3, lnls-dig/bpm-epics-ioc#4, lnls-dig/bpm-epics-ioc#5
This happens again in FMC250M, due to much time being taken into acquiring ADC temperature, I think. We could implement a simple yet efficient method of adding the "service address" + "message sequence number" so we won't mistake the message for another. This extra fields are easily added in malamute (our transmission protocol)
Most of the work will be in the client itself of checking if these "reply" fields match the ones it sent earlier
This is happening, once and for all, due to malamute client instance receiving messages that could be for either mailbox it sends messages to. So, if a malamute client instance sends messages to various mailboxes, each one of them can send their reply asynchronously and in any order.
So, we need to check if the "sender" of the received message is indeed what we are expecting and treat this accordingly.
However, we can only check for the sender once we have received the message, at which point we are too late to put it back on the receiving buffer for later consumption .
One simple workaround is to use one malamute instance for each service.
Not happening anymore.