bojand/ghz v0.80.0

on GitHub

Changelog

v0.80.0 - 2021-01-02

Changes

Attempt address at least in part #162, #169, #226 and #184.

CLI

Essentially adds several options for controlling behaviour of streaming calls:

--stream-call-duration

Maximum stream call duration. For client streaming and bidi calls, we'll send messages until this duration expires.

For server streaming calls we will receive message until the duration has expired. Note that in server streaming calls the cancellation will result in call cancelled error.

Example: 500ms.

--stream-call-count

The maximum number of message sends or receives the client will perform in a streaming call before closing the stream and ending the call. For client and bidi streaming calls this dictates the number of messages we will send.

If the data array contains more elements than the count, only data up to the number specified will be used.

If the data array contains fewer elements than the count specified, all the data will be iterated over repeatedly until count limit is reached.

For server streaming calls we will receive message until the specified count is reached. Note that in server streaming calls the cancellation will result in call cancelled error.

Examples:

--stream-call-count=2 -d '[{"name":"Joe"},{"name":"Kate"},{"name":"Sara"}]'

Will cause only [{"name":"Joe"},{"name":"Kate"}] to be sent. Similarly:

--stream-call-count=5 -d '[{"name":"Joe"},{"name":"Kate"},{"name":"Sara"}]'

Will cause [{"name":"Joe"},{"name":"Kate"},{"name":"Sara"},{"name":"Joe"},{"name":"Kate"}] to be sent.

--stream-dynamic-messages

In streaming calls, regenerate and apply call template data on every message send operation.
This is helpful in combination with template functionality to generate data for every message sent in a streaming call.
For example:

--stream-dynamic-messages=true --stream-call-count=5 -d '{"name":"{{randomString 8 }}"}'

Will result in streaming call with the following data sent:

[{"name":"sKNdMCIb"},{"name":"KLVXDvn1"},{"name":"RJ3knnBh"},{"name":"FTBqQ7nl"},{"name":"FzeMQIWo"}]

Contrast that with the default dynamic messages setting turned off; which means the template data will be applied only once for each stream call request, but not for each message sent in the streaming call.

--stream-call-count=5 -d '{"name":"{{randomString 8 }}"}'

Results in the following data sent:

[{"name":"5hL64dd0"},{"name":"5hL64dd0"},{"name":"5hL64dd0"},{"name":"5hL64dd0"},{"name":"5hL64dd0"}]

--count-errors

By default stats for fastest, slowest, average, histogram, and latency distributions only take into account the responses with OK status. This option enabled counting of erroneous (non-OK) responses in stats calculations as well.

API

In addition to API to support the above options, there are a few Go package API functions introduced in this pull request that are not exposed via CLI options.

WithDataProvider can be used to specify a custom data provider function that's invoked with every call.

WithDataProvider(func(*CallData) ([]*dynamic.Message, error) {
	protoMessage := &helloworld.HelloRequest{Name: "Bob"}
	dynamicMessage, err := dynamic.AsDynamicMessage(protoMessage)
	if err != nil {
		return nil, err
	}
	return []*dynamic.Message{dynamicMessage}, nil
}),

The signature is the same for unary or streaming calls. For unary calls the function must return an array with at least 1 value. The first value is always used for unary calls.

Similarly there is a metadata provider function.

WithMetadataProvider(func(*CallData) (*metadata.MD, error) {
	return &metadata.MD{"token": []string{mdv}}, nil
}),

WithStreamRecvMsgIntercept can be used to add an interceptor function to streaming call that is invoked every time we receive a streaming message. Example usage:

WithStreamRecvMsgIntercept(func(msg *dynamic.Message, err error) error {
	if err == nil && msg != nil {
		reply := &helloworld.HelloReply{}
		convertErr := msg.ConvertTo(reply)
		if convertErr == nil {
			if reply.GetMessage() == "Hello bar" {
				return ErrEndStream
			}
		}
	}
	return nil
})

In future release we hope to remove reliance on the github.com/jhump/protoreflect/dynamic package for these APIs.