thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murat Knecht <murat.kne...@googlemail.com>
Subject Not enough frame size 0 to read 4 bytes
Date Mon, 11 Apr 2016 10:38:28 GMT
Hello,

we've a few Golang services connected with Thrift and are running into a
peculiar problem every week or so: Calls to one particular service would
fail with:

    Notenoughframesize0toread4bytes

or

    outofsequenceresponse
    Incorrectframesize(251658252)

The weird thing is that most API endpoints of that service are working
fine, can be called and will respond properly. Only two methods are,
when they degrade, down for good. Until we restart the process.

The one thing that makes these two API endpoints special (apart from the
errors): The service calls another Thrift-powered service to retrieve
data — which is running in the same process. So, we have two services
exposing Thrift endpoints on different ports, but running in the same
process (for good, old historic reasons), with one of those services
calling the other.

Does that ring a bell with anyone familiar with the Thrift-Go
implementation? Is this obviously a bad idea? Is there some shared state
that would explain why sometimes the framebuffers leak memory / degrade?
This happens sporadically (usually Friday night, for the fun of it) so I
won't be able to provide a minimal code sample to reproduce this.

Any thoughts / ideas?

Thanks,
Murat



Mime
View raw message