Permissions to apache-geode jira dashboard
Can I please have permissions to edit the Apache-Geode JIRA dashboard. My username is mboxwala. I would like to be able to add new tickets, edit ticket, assign tickets to myself… Thanks, Murtuza
Re: [DISCUSS] changing geode 32-bit counter stats to 64-bit
+1 to @Udo Kohlmeyer comment. If the memory has been used, might as well allow us to query the values On Fri, Jun 7, 2019 at 2:18 PM Udo Kohlmeyer wrote: > +1, if the LongAdders have already added and the additional memory usage > has already been dealt with, then adding the accessors does not really > make a difference anymore. > > On 6/7/19 13:47, Jacob Barrett wrote: > > I like this! > > > > I’d go ahead and change all the usage of the int methods to the long > methods. I’d deprecate the int methods to make it very clear. > > > > If some consumer is using the int methods they will still work with the > same rollover issues but perhaps with the deprecated warning they will > update their code. Without the warning they may never know. > > > > -jake > > > > > >> On Jun 7, 2019, at 1:32 PM, Darrel Schneider > wrote: > >> > >> We have had a couple of tickets that have problems with 32-bit counters > >> changing too fast and causing them to be hard to understand when they > wrap > >> around (see GEODE-6425 and GEODE-6834). We have also had problems with > some > >> stats being broken because they were changing the 32-bit one when they > >> should have been changing the 64-bit one (see GEODE-6776). > >> The current implementation has one array of values for the 32-bit stats > and > >> another array of values for the 64-bit stats. We use indexes into these > >> arrays when changing a stat. Given an int "id" used to index these > arrays, > >> we can not tell if we should be indexing the 32-bit array or 64-bit > array. > >> The first 32-bit stat for a type will have an id of 0 and the first > 64-bit > >> stat on that type will also have an id of 0. But our current > implementation > >> has the same type of value in both arrays (LongAdder > >> see: StripedStatisticsImpl fields intAdders and longAdders). So if we > >> simply change our implementation to have a single array, then the ids > will > >> no longer be overloaded. > >> > >> Changing this internal implementation also improves backward > compatibility. > >> Currently when we change one of our counters from 32-bit to 64-bit it is > >> possible we would break existing applications that are using the > Statistics > >> interface. It has methods on it that allow stats to be read given an it: > >> getInt(int id) and getLong(int id). If they are currently reading a > 32-bit > >> stat using getInt(id) and we change that stat to be 64-bit (like we did > in > >> GEODE-6425) then they will now be reading the wrong stat when they call > >> getInt(id). If they used getInt(String) or getInt(StatisticDescriptor) > they > >> will be okay. But if we make this simple change to have 32-bit and > 64-bit > >> stats stored in the same array then getInt(id) will do the right thing > when > >> we change a stat from 32-bit to 64-bit. > >> > >> Does anyone see a problem with making this change? > >> > >> After we do it I think we should change all of our counters to 64-bit > since > >> they are always stored in a LongAdder anyway and we should deprecate the > >> methods that support 32-bit stats. >
Re: Permissions to apache-geode jira dashboard
You should have access now. Thanks, -Dan On Mon, Jun 10, 2019 at 10:31 AM Murtuza Boxwala wrote: > Can I please have permissions to edit the Apache-Geode JIRA dashboard. My > username is mboxwala. I would like to be able to add new tickets, edit > ticket, assign tickets to myself… > > Thanks, > Murtuza
Re: [DISCUSS] changing geode 32-bit counter stats to 64-bit
+1 for Jake’s approach. Jake’s approach seems to address the only concern that I know of which is backward compatibility. Thanks, Mark > On Jun 10, 2019, at 11:20 AM, Robert Houghton wrote: > > +1 to @Udo Kohlmeyer comment. If the memory has > been used, might as well allow us to query the values > > On Fri, Jun 7, 2019 at 2:18 PM Udo Kohlmeyer wrote: > >> +1, if the LongAdders have already added and the additional memory usage >> has already been dealt with, then adding the accessors does not really >> make a difference anymore. >> >> On 6/7/19 13:47, Jacob Barrett wrote: >>> I like this! >>> >>> I’d go ahead and change all the usage of the int methods to the long >> methods. I’d deprecate the int methods to make it very clear. >>> >>> If some consumer is using the int methods they will still work with the >> same rollover issues but perhaps with the deprecated warning they will >> update their code. Without the warning they may never know. >>> >>> -jake >>> >>> On Jun 7, 2019, at 1:32 PM, Darrel Schneider >> wrote: We have had a couple of tickets that have problems with 32-bit counters changing too fast and causing them to be hard to understand when they >> wrap around (see GEODE-6425 and GEODE-6834). We have also had problems with >> some stats being broken because they were changing the 32-bit one when they should have been changing the 64-bit one (see GEODE-6776). The current implementation has one array of values for the 32-bit stats >> and another array of values for the 64-bit stats. We use indexes into these arrays when changing a stat. Given an int "id" used to index these >> arrays, we can not tell if we should be indexing the 32-bit array or 64-bit >> array. The first 32-bit stat for a type will have an id of 0 and the first >> 64-bit stat on that type will also have an id of 0. But our current >> implementation has the same type of value in both arrays (LongAdder see: StripedStatisticsImpl fields intAdders and longAdders). So if we simply change our implementation to have a single array, then the ids >> will no longer be overloaded. Changing this internal implementation also improves backward >> compatibility. Currently when we change one of our counters from 32-bit to 64-bit it is possible we would break existing applications that are using the >> Statistics interface. It has methods on it that allow stats to be read given an it: getInt(int id) and getLong(int id). If they are currently reading a >> 32-bit stat using getInt(id) and we change that stat to be 64-bit (like we did >> in GEODE-6425) then they will now be reading the wrong stat when they call getInt(id). If they used getInt(String) or getInt(StatisticDescriptor) >> they will be okay. But if we make this simple change to have 32-bit and >> 64-bit stats stored in the same array then getInt(id) will do the right thing >> when we change a stat from 32-bit to 64-bit. Does anyone see a problem with making this change? After we do it I think we should change all of our counters to 64-bit >> since they are always stored in a LongAdder anyway and we should deprecate the methods that support 32-bit stats. >>
Re: [PROPOSAL] Instrumenting Geode Code
+1 I like this approach compared to the previous proposals because it's simpler (doesn't require a custom registry) and makes it more straightforward to replace stats with Micrometer meters in the future. - Aaron On Fri, Jun 7, 2019 at 4:58 PM Dale Emery wrote: > Proposal for instrumenting Geode > > > *Goals* > > - Allow routing measurements to statistics, Micrometer meters, or both as > appropriate, to allow publishing each measurement to the appropriate places. > > - Minimize the intrusiveness of new and existing metrics instrumentation. > > - Minimize the amount of code that must know how to route measurements to > stats and meters. > > - Maintain Geode performance. > > - Not preclude any options for deprecating and removing Geode’s statistics > mechanism in the future. And take steps to make deprecating and removing > the existing statistics mechanism easier. > > > *Proposal* > > - Continue to use Geode’s existing style of instrumentation class (e.g. > CachePerfStats) to instrument code. > > - Enhance the instrumentation classes to create and register meters when > appropriate, and to route each measurement to the appropriate stats and > meters. > > - When we want to route a given measurement to both a statistic and a > meter, use the "legacy meter" wrapper mechanism (described below). > > - Incrementally improve the instrumentation classes to focus more on > reporting domain events (e.g. regionAdded()) and less on reporting > measurements (e.g. incRegions()). > > > *Legacy Meter Wrappers* > > To route a given measurement to both a Micrometer meter and a Geode > statistic, do the following in the instrumentation class's constructor: > > - Create and register a normal Micrometer meter in the cache's meter > registry. > > - Wrap the registered meter in a custom "legacy meter" that reads and > writes the stat, and also writes to the registered meter. > > In the instrumentation methods (e.g. endPut()): > > - Use the legacy meter to report measurements. > > I've attached two diagrams below to show how the wrapper mechanism works > for "counter" style stats and meters. The first is a class diagram, showing > how the parts relate in general. The second is a sequence diagram that > shows in some detail how the parts interact to route a given measurement to > both a meter and a stat. > > If you want even more details, Jake Barrett has created a nice "proof of > concept" implementation: > https://github.com/apache/geode/compare/develop...pivotal-jbarrett:wip/LegacyMeterBuilder > > > > Please let us know if you have questions, comments, or concerns. > > > Cheers, > Dale > > — > Dale Emery > dem...@pivotal.io > > > > > > > > >
