Thomas, I don't have data points with me to show the noticeable problem with existing way. I was going through the code for some other purpose which is when I understood that java reflection is used. Its more of an opinion that use of reflections are costly and using something like Janino would ease the processing overhead on Stram and containers.
Would it make sense to try this out as a POC and see if we see improvements in performance/stability? Thanks, Chinmay. On Wed, Mar 15, 2017 at 9:46 PM, Thomas Weise <t...@apache.org> wrote: > Can you quantify what overhead you observed and if it has caused noticeable > problems in a real application? It would be good to understand the > motivation for the changes you suggest. > > Regarding 1. and 2. I don't want to see operator properties that the user > configures confused with metrics that the operator exposes for monitoring. > I think that the current approach of using fields that the operator > developer can choose to keep private is good. > > > > On Tue, Mar 14, 2017 at 11:17 PM, Chinmay Kolhatkar <chin...@apache.org> > wrote: > > > Dear Community, > > > > While going through the code, I found that the AutoMetrics are retrieved > > from operators using java reflection. This adds a lot of processing > > overhead. > > > > Hence to improve the performance of containers and stram, I want to > suggest > > following appraoch: > > 1. In Node, try to collect the metric using getter method using Janino if > > available, if not fallback to reflection. > > 2. In operator documentation, suggest to have a getter method/public for > > autometrics. > > 3. In AppDataPushAgent, use Janino to get the AutoMetrics present in > > LogicalOperatorInfo > > > > Please share your opinion. > > > > Thanks, > > Chinmay. > > >
