> On May 2, 2016, at 9:32 AM, Chris Pike <[email protected]> wrote: > > Currently, calling Config will give you both local and remote config, so the > only code calling LocalConfig is code loading properties needed for setting > up the connection. I'm not sure if there is a great way to abstract it any > further. Potentially, we could create a RemoteConfig class and let Config be > the common interface to both. But it would have to keep state on whether > remote config was loaded, and then try to load it every time any of the > getProperty methods was called until successful. > > As for the GlobalIds, it might make sense to make all the non static calls > just method in the Config class and not make GlobalIds a singleton. > > I built a VM with this branch, and it passed all the unit tests, I ran a > bunch of the JMeter tests as well, but not sure what is considered acceptable > performance.
Chris agree with the making all calls to globalids use the nonstatic call. But I’m going to have to push back on the other. It will make the code brittle because we’re not going to be able to remember which one’s are needed for connection setup and which ones aren’t. And for that matter it will likely change over time. We need to figure something out here. I’d rather have more complexity in the config class than expose that to the callers. As for performance testing, do a comparison - one with the changes and one w/out. Response time should be about the same. Good work btw, I’m sure we’ll figure something out on the local / remote config. Can we add a type to the config (i.e. local or remote)? Let me know if you want to discuss it further. Shawn
