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
This adds an Automatic-Module-Name entry to the Thrift jar manifest
in order to provide Thrift with a stable module name when used in a
JPMS modular context. The name chosen here is "org.apache.thrift",
which matches the symbolic name used for OSGi.
See: http://branchandbound.net/blog/java/2017/12/automatic-module-name/
This also comes from the discussion of
https://github.com/apache/thrift/pull/1992#issuecomment-705903922.
I think TDebugProtocol is a better fit for this feature than creating a
new TProtocol implementation.
The DuplicateTo field is not added to TDebugProtocolFactory because I
don't think it makes sense from the factory setup. In vast majority
cases users would need direct access to the underlying TMemoryBuffer to
make it useful, which is easier this way than an additional
TTransportFactory plus TProtocolFactory to make TDebugProtocolFactory
way too complicated.
Client: go
In go library's TSimpleJSONProtocol and TJSONProtocol implementations,
we use slices as stacks for context info, but didn't do proper boundary
check when peeking/popping, result in it might panic with using -1 as
slice index in certain cases of calling Write*End without matching
Write*Begin before.
Refactor the code to properly implement the stack, and return a
TProtocolException instead on those cases.
Also add unit tests for all protocols. The unit tests shown that
TCompactProtocol.[Read|Write]StructEnd would also panic with unmatched
Begin calls, so fix them as well.
Client: go
This is a follow up to 4db7a0af13.
Because of the Go runtime bug [1], the previous default value of 1ms is
not a great default as it could cause excessive cpu usage. Use 5ms
instead as a balance between being useful and not causing too much cpu
overhead.
It's still configurable.
[1]: https://github.com/golang/go/issues/27707
Client: go
Cleanup the default NewTSerializer and NewTDeserializer implementations
to save an unnecessary allocation, and provide
NewTSerializerPoolSizeFactory and NewTDeserializerPoolSizeFactory for
easier non-default pool usages.
For the abstract unix socket address type, the string in the
'sun_path' field of the 'sockaddr_un' struct, is a not null-terminated
string (see unix(7)).
Fix the lentgh calculation of the 'sun_path' field to not add
the termination null byte.
