You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Ilya Kasnacheev <il...@gmail.com> on 2018/07/06 13:51:07 UTC
IgniteConfiguration, toString(), @GridToStringInclude
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
Re: IgniteConfiguration, toString(), @GridToStringInclude
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <il...@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 <ds...@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.kasnacheev@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
> > >
> >
>
Re: IgniteConfiguration, toString(), @GridToStringInclude
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <ds...@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.kasnacheev@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
> >
>
Re: IgniteConfiguration, toString(), @GridToStringInclude
Posted by Dmitriy Setrakyan <ds...@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 <il...@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
>