In that case I would recommend that it is a separate category that can be easily turned off. Also, if there are 1000 caches, then I am certain that they share most of the properties and only a few configuration properties differ. Moreover, it is very likely that most of them belong to the same cache group. So I recommend the following:
1. Instead of printing configuration per cache we should print caches per configuration. In other words, we print out the config properties and then all caches that use it. This should reduce the configuration print out. 2. If more than 1 group is used, then let's print out configuration per group, not per cache. 3. For new nodes joining, let's print out the configuration differences for the properties that are expected to be the same. In addition, I would like to have a configuration validator. For example, we could have a set of mandatory config properties stored in config-validator.xml. Whenever a new node joins, we check its config against the config-validator properties. If they don't match, then a new node is not allowed to join. This approach will allow users to control configuration properties across the cluster. Thoughts? D. On Sun, Jul 8, 2018 at 2:39 AM, Ilya Kasnacheev <ilya.kasnach...@gmail.com> wrote: > Hello! > > The configuration is usually already present in some other file (in XML or > Java form). People who report problems or userlist often fail to provide > such file, and they will also definitely forget to provide that other > separate file with printed configuation. Log file is our best shot since > it's what usually gets reported. > > Regards, > > -- > Ilya Kasnacheev > > 2018-07-07 0:23 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > Can we print out the configuration to a separate file? Moreover, I think > we > > should also print out the configuration differences between nodes, > whenever > > new nodes join topology. > > > > D. > > > > On Fri, Jul 6, 2018 at 6:51 AM, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > > > > wrote: > > > > > Hello! > > > > > > I was working on https://issues.apache.org/jira/browse/IGNITE-8935 to > > > avoid > > > default toString() implementations in classes reachable from > > > IgniteConfiguration, which we print on start-up. > > > > > > I have discovered that by default we avoid printing arrays and > > collections. > > > We only print those when marked with @GridToStringInclude. This to > avoid > > > serializing endless auto-generated lists I suppose. > > > > > > And I was thinking of going through IgniteConfiguration and friends, > > > marking some user-specified collections @GridToStringInclude so that > they > > > show up in toString(). The most notorious one will be > > > IgniteConfiguration.cacheConfigurations. > > > > > > What's your take on this one? On one hand, cache configurations are of > > > tremendous significance to anybody debugging Ignite, or troubleshooting > > > user cases on e.g. userlist. > > > On other hand, some people have configurations with thousands of caches > > and > > > might be not completely happy with several megabytes of log within a > > single > > > line. > > > > > > Should I mark caches configurations (and also service configurations, > and > > > others) with @GridToStringInclude or not? I think that the only place > > where > > > it gets printed is once on the start when IGNITE_QUIET is false. > > > > > > I will defer doing that until aforementioned ticket is merged, so > please > > > take a look at it if you're interested. > > > > > > Regards, > > > > > > -- > > > Ilya Kasnacheev > > > > > >
