Possible command issue with multiple commands at (almost) same time #8
Labels
No labels
bug
confirmed
critical
discussion
documentation
Doing
enhancement
suggestion
support
To Do
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: hazaar/hazaar-warlock#8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have a situation where I am firing off two triggers within a single loop. In this case it is trigger an email to be sent and the loop is through a list of email addresses to send the email to.
The problem is, only first email is being sent because only the first trigger is recognised. I'm not sure if this is a transmission problem on the client, or a receive problem on the server, however the server seems to receive multiple packets at the same time in other situations without a problem.
This is critical, but my current test case was able to work around this issue by putting in a small
sleep(1)
after sending each trigger.added ~163 label
I have tried to replicate this. At first I failed to replicate it, because it does not appear to be a send issue. It is actually a receive issue. I was able to replicate this issue by putting a standard
sleep(1)
call inside the event handler. This simulated the sending of email, which does quite a bit of stuff (parses a template, looks up database stuff, talks to sendmail, etc) so the receiver can be hung up for a little while, while it does it's job.So, I did this to replicate the issue:
And on the sending side I did this in the index controller:
When I did this, I got the first 2 events and then nothing. Log:
As soon as on the sender I put that sleep back in, I get this:
Which is still wrong because i lost the last event. I'm really not sure what is going on here as data should stay in the receive buffer until it is picked up.
Moar testing!
created branch
8-possible-command-issue-with-multiple-commands-at-almost-same-time
Note. Packets are NOT getting lost. It looks like the service client only checks for new packets WHILE there are new packets coming in. It then loads them into it's local buffer but if they are not processed they will just sit there until more data arrives.
Found the issue! Finally! And it was stupid! haha
Basically, when data is received it is converted into a packet. If there is data leftover from the conversion, it is stored in a local frame buffer. However, this frame buffer is only checked when the processFrame() method is called, which is only called when data is received. That's right. THERE IS NO ADDITIONAL FRAME BUFFER CHECK.
I have now added this above the check for new packets from the socket buffer.
mentioned in commit
0291dd3bde
mentioned in merge request !3
closed via commit
46832da293
closed via merge request !3