Hi,
Randy explained the purpose of the seqID here:
http://stackoverflow.com/questions/28858960/for-which-purposes-used-seqid-in-apache-thrift
Re testing the order of seqIDs (and throwing), I tend to think that this is
just plain wrong re normal Thrift usage. Of course one can have multiple
outstanding requests, and of course any subsequent request may return before
requests made earlier. There's nothing wrong with that in my opinion.
Whether or not these requests belong together in some logical fashion and
this have to be in a specific order should not be a Thrift problem, that's
an application problem.
So IMHO using the field is fine, but throwing if the responses are out of
order is probably not.
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: Oleg Sivokon
Sent: Sunday, May 15, 2016 11:35 AM
To: [email protected]
Subject: Possible bug in Go generated code related to multiple outstanding
requests
Hello, list.
I've encountered a problem with generated Go code, namely, when I try
to use the same client to send multiple requests in quick succession I
run into "ping failed: out of sequence response" error. This happens
because responses don't necessarily arrive before next request is
sent. However, the generated code seems to assume this shouldn't
happen.
Below is the simplified code for generic generated send/receive:
func send() {
id++
receive()
}
func receive() error {
message := actuallyReceive()
if message.id != id {
return fmt.Errorf("Ids don't match")
}
return nil
}
Where this becomes problematic is when you have two or more
outstanding requests. Obviously, the id counter will miss some
responses, because it will be incremented before receive() was able to
process the previously sent message.
So, my questions are: is this behavior expected? And if so, what's
the suggested way to have multiple outstanding requests?
Best.
Oleg
