Open robert3005 opened 5 years ago
Maybe related to #416?
In this instance, is the lone thing you need from the exchange the status code?
I need to be able to register an ExchangeCompletionListener
Sorry, the complicated bit of this logic is being able to get access to request body. Since if I were to do it before the default handler then it would fail deserializing the input.
Specifically to get the size of the incoming request or something else?
DatasetSizeThresholds makes an external call to fetch size of the data that the request is about.
I'm not sure I understand why this cannot be implemented using the async ListenableFuture instead. We can count bytes written to a BinaryResponseBody
and report success or failure using a future callback without reaching into the framework implementation. There may be something I'm missing though.
I am not interested in the byte size of the body but getting the body and using it to make a call to external service and then adding that to an exchange completion listener. I think I could wrap the async listenablefuture but I wanted to mimic the metric we used internally which uses the exchange completion time
What happened?
I had forked generated undertow handlers to add metrics dependent on request body.
Currently you can modify your service by wrapping your service definition or wrapping the endpoint. However, there's no way to create a plugin that can use both of them without forking generated undertow handlers.
The concrete case was creating a server response time metric that has tag values that are request body specific. This is a simpler version of the code modifications I had to make to generated service endpoints. Naturally this gets pretty cumbersome with many endpoints.
What did you want to happen?
It should be possible to write a an extension to generated handlers that can access both request objects and the undertow exchange.