Thanks, Jens. I have created an issue for this problem specific to Go (THRIFT-3735) and will be contributing a patch shortly.
Thanks, Tyler On Fri, Mar 11, 2016 at 2:05 PM Jens Geyer <[email protected]> wrote: > > Hi Tyler, > > I had the same issue with TJSONProtocol in Delphi (and it probably exists > in > C# too which I used as the model). Fortunately I was able to fix that > problem with the context stack, see THRIFT-1473. Since then, I had no > further problems of that kind with it. > > HTH, > JensG > > > > -----Ursprüngliche Nachricht----- > From: Tyler Treat > Sent: Thursday, March 10, 2016 6:26 PM > To: [email protected] > Subject: Reusing TProtocol after write error > > I have a case where I would like to reuse a TProtocol instance after a > write/flush error occurs on the protocol. > > For example, imagine I have a transport which has a size limit on message > frames, and it returns an error if you exceed that limit. The error is > bubbled up to the user, who is then responsible for making a smaller > request. The problem is that some TProtocols have state associated with > them (e.g. in Go, TJSONProtocol has a write buffer and a parse context), so > after an error they are in an invalid state and subsequent uses of them > produce corrupted data. TBinaryProtocol doesn't seem to have this issue. > > My question is: would it be reasonable to expose a method for "resetting" a > TProtocol back to its original state such that it can be safely reused > after a failed write or flush? > > Thanks, > >
