ctubbsii commented on code in PR #5012:
URL: https://github.com/apache/accumulo/pull/5012#discussion_r1815591112
##########
core/pom.xml:
##########
@@ -412,6 +416,37 @@
</plugins>
</build>
<profiles>
+ <profile>
+ <id>flatbuffers</id>
+ <build>
+ <plugins>
+ <plugin>
+ <groupId>com.sequsoft.maven.plugins</groupId>
+ <artifactId>flatbuffers-maven-plugin</artifactId>
Review Comment:
You're probably right about how thrift deserializes. It's a safe assumption
that if you've made an RPC call, you want to make use of the response, so
that's probably what thrift does.
We've also used JSON in many places, which has similar benefits. I wonder
what the difference in performance would be if we just used Gson or Jackson to
handle the serialization of the objects, rather than introduce another
dependency and workflow into the build. It'd be nice to be somewhat consistent
with how we do serialization, and it would be nice to avoid the complexity of
another IDL build workflow and dependency, especially if the plugin that makes
the workflow easier isn't well maintained.
The way the monitor currently avoids unnecessary work is by only pulling
stuff from the Manager when needed to serve content to a user request. It rate
limits the frequency of the pulling to prevent excessive calls to the Manager.
I don't know if it would eliminate the entire benefits of flatbuffers, but I'm
thinking we should probably do the same here, because there's no reason for the
monitor to constantly poll the whole cluster when nobody is querying any pages.
If that alone is enough to eliminate the unnecessary deserialization when
nobody's asking for it, then it might make things dramatically simpler.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
