You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 22, 2018. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
This is related to github issue #3 and 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.
The text was updated successfully, but these errors were encountered: