Client: Java
Patch: Christopher Tubbs
This closes#2325
* Enforce Java 8 compatibility using the new `--release` flag introduced
in JDK9, so that all generated bytecode follows Java 8 strict
compatibility, even when building with newer JDK versions (9 or later)
(this fixes NoSuchMethodError with ByteBuffer, and other potential
incompatibilities in bytecode generation that would make the code
unable to run on a Java 8 JRE)
* Also strictly enforce the JDK version used to build the project by
ensuring it is at least version 1.8, and will fail fast when building
the Java libraries if this condition is not met.
Client: go
There is a duplicate elements check for set in writeFields* function,
and it compares elements using reflect.DeepEqual which is expensive.
It's much faster that generates a *Equals* function for set elements and
call it in duplicate elements check, especially for nested struct
element.
Closes#2307.
Client: go
Make a breaking change so that TClient.Call returns the response
meta, currently only contains headers but could be expanded in the
future, and make a compiler change to compiler generated clients to take
advantage of that and provide access to response metadata to users.
Client: go
This fixes a bug introduced in
https://github.com/apache/thrift/pull/2296, that we mixed the preferred
proto id and the detected proto id, which was a bad idea.
This change separates them, so when we propagate TConfiguration, we only
change the preferred one, which will only be used for new connections,
and leave the detected one from existing connections untouched.
Also add a test for it.
Client: go
Having it under a subdirectory has some unexpected consequences, so
remove it for now. Another PR will be open up later to add it back to
the root directory.
Client: go
Add TExceptionType enum type, and add
TExceptionType() TExceptionType
function to TException definition.
Also make TProtocolException unwrap-able.
Client: go
Define TConfiguration following the spec, and also move the following
configurations scattered around different TTransport/TProtocol into it:
- connect and socket timeouts for TSocket and TSSLSocket
- tls config for TSSLSocket
- max frame size for TFramedTransport
- strict read and strict write for TBinaryProtocol
- proto id for THeaderTransport
Also add TConfiguration support for the following and their factories:
- THeaderTransport and THeaderProtocol
- TBinaryProtocol
- TCompactProtocol
- TFramedTransport
- TSocket
- TSSLSocket
Also define TConfigurationSetter interface for easier TConfiguration
propagation between wrapped TTransports/TProtocols , and add
implementations to the following for propagation
(they don't use anything from TConfiguration themselves):
- StreamTransport
- TBufferedTransport
- TDebugProtocol
- TJSONProtocol
- TSimpleJSONProtocol
- TZlibTransport
TConfigurationSetter are not implemented by the factories of the
"propagation only" TTransports/TProtocols, if they have a factory. For
those use cases, TTransportFactoryConf and TProtocolFactoryConf are
provided to wrap a factory with the ability to propagate TConfiguration.
Also add simple sanity check for TBinaryProtocol and TCompactProtocol's
ReadString and ReadBinary functions. Currently it only report error if
the header length is larger than MaxMessageSize configured in
TConfiguration, for simplicity.
Client: py
This allows clients to choose which subprotocol (TBinary/TCompact) to frame with headers. The server will already accept either protocol and reply correctly.
Client: go
In TBinaryProtocol.ReadString, TBinaryProtocol.ReadBinary,
TCompactProtocol.ReadString, and TCompactProtocol.ReadBinary, use
safeReadBytes to prevent from large allocation on malformed sizes.
$ go test -bench=SafeReadBytes -benchmem
BenchmarkSafeReadBytes/normal-12 625057 1789 ns/op 2176 B/op 5 allocs/op
BenchmarkSafeReadBytes/max-askedSize-12 545271 2236 ns/op 14464 B/op 7 allocs/op
PASS
Client: go
The fix in https://github.com/apache/thrift/pull/2293 doesn't work for
go1.10.8 due to the possibility of data races. This exposes a bigger,
underlying issue regarding the ownership of the request buffer in
THttpClient between THttpClient itself and the http request it creates.
Instead of reset and reuse the same buffer, always give up the ownership
of it and create a new buffer after each Flush call.
THttpClient did not reset its internal buffer when HTTP client returned
an error, leaving the whole or partially read message in the buffer.
Now we reset the buffer in defer.
Client: go
