search

lnls-dig / halcs

Hardware Abstraction Layer for Control Systems
GNU General Public License v3.0
1 stars 4 forks source link

[libbpmclient] Old received message on receive buffer #107

Closed lerwys closed 4 years ago

lerwys commented 8 years ago

Issue by lerwys Wednesday Sep 30, 2015 at 17:15 GMT Originally opened as https://github.com/lnls-dig/bpm-sw/issues/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.

lerwys commented 8 years ago

Comment by lerwys 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

lerwys commented 7 years ago

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

lerwys commented 7 years ago

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.

lerwys commented 4 years ago

Not happening anymore.