[
https://issues.apache.org/jira/browse/AVRO-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881322#action_12881322
]
Doug Cutting commented on AVRO-578:
-----------------------------------
Patrick> One way would be to add add two calls in each place, one which
interacts with plugin pre-encoding payload and the other after. That feels ugly
to me...
What's a better alternative? Should we have specific
mungeServerRequestMetadata(Map<String,ByteBuffer>) and a
recordStatsAboutServerResponsePayload(List<ByteBuffer>) methods instead?
That'd be cleaner, but might overly constrain what's possible.
Philip> It's a question of whether we are considering the Plugin API evolving
or stable, and I'm not sure.
I don't think the plugin API is yet used much, so I think it could change
without breaking much, if anything.
Some comments on the patch:
- What's a use case for preServerSendResponse? If a plugin wants to add
metadata to the response, it now needs to do it in the serverRecieveRequest()
method, which limits what it can do. I can imagine plugins that want to add
stuff to the metadata that depends on the response. That was possible before,
but no longer is. Perhaps metadata should always be put in a separate
ByteBuffer at the head of the response, then we might could (1) serialize the
response payload; (2) run the plugins; (3) serialize the metadata. Then you
could collect stats on payload size, but not metadata size. This would allow a
plugin that encrypted or checksummed payloads.
- Similarly, in Requestor, we might serialize the payload, then call plugins,
then serialize the metadata.
- In Requestor, can we combine the two loops calling postClientSendRequest()?
> Add RPC Payload to RPCContext class
> -----------------------------------
>
> Key: AVRO-578
> URL: https://issues.apache.org/jira/browse/AVRO-578
> Project: Avro
> Issue Type: Sub-task
> Components: java
> Reporter: Patrick Wendell
> Assignee: Patrick Wendell
> Attachments: AVRO-578.patch, AVRO-578.patch.v2, AVRO-578.patch.v3
>
>
> For stats/monitoring it is helpful to see how many bytes are encoded for a
> given RPC call. Right now Encoder's don't track how many payload bytes are
> actually written out when encoding is done.
> Ideally this bytesWritten() would be in Encoder interface, however not sure
> JSON plugin can track the number of characters actually written, so
> alternatively just could be added to BinaryEncoder, and stats plugin will
> only provide payload sizes when that encoder is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
