ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: IgniteConfiguration.gridName is very confusing
Date Tue, 10 Jan 2017 09:58:47 GMT
I think we should fix log output as well and replace all "grid" occurences
with "instance".

On Tue, Jan 10, 2017 at 12:55 PM, Alexander Fedotov <
alexander.fedotoff@gmail.com> wrote:

> Hi,
>
> I think we should leave null as a default value for unnamed Ignite
> instances. At least that change should be considered out of the current
> scope.
>
> What about naming, I'm also renaming log occurrences of "grid" and "grid
> name" where it stands reasonable.
> Are there places in the logging logic where we should prefer name "grid" or
> "grid name" instead of "Ignite instance name" or "Ignite instance name" can
> be used without any semantic impact?
>
> On Sat, Dec 31, 2016 at 11:23 AM, Alexander Fedotov <
> alexander.fedotoff@gmail.com> wrote:
>
> > Okay. From the all said above I suppose "instanceName" should work for
> > IgniteConfiguration and "igniteInstanceName" in all other places.
> >
> > Regards,
> > Alexander
> >
> > 31 дек. 2016 г. 3:43 AM пользователь "Dmitriy Setrakyan" <
> > dsetrakyan@apache.org> написал:
> >
> > It sounds like it must be unique then. I would propose the following:
> >
> >    1. If user defines the instanceName, then we assign it to the node.
> >    2. If user does not define the instance name, then we have to give it
> >    some unique value, like node ID or PID.
> >
> > Will this change be backward compatible, or should we leave it as null if
> > user does not define it?
> >
> > D.
> >
> > On Fri, Dec 30, 2016 at 4:19 PM, Denis Magda <dmagda@gridgain.com>
> wrote:
> >
> > > Sounds reasonable. Agree that 'instanceName' suits better considering
> > your
> > > explanation.
> > >
> > > --
> > > Denis
> > >
> > > On Friday, December 30, 2016, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com> wrote:
> > > > This name identifies instance of Ignite, in case there are more than
> > one
> > > > within an application. Here are our API methods around this:
> > > >
> > > > // We provide a name and get newly started *Ignite* instance.
> > > > Ignite ignite = Ignition.start(new
> > > IgniteConfiguration().setGridName(name));
> > > >
> > > > // We provide a name and get existing *Ignite* instance.
> > > > Ignite ignite = Ignition.ignite(name);
> > > >
> > > > This has nothing to do with nodes. For node representation we have
> > > > ClusterNode API, which already has nodeId() method for
> identification.
> > > >
> > > > In other words, if we choose nodeName, we will have both nodeName and
> > > > nodeId in the product, but with absolutely different meaning and used
> > in
> > > > different parts of API. How user is going to understand the
> difference
> > > > between them? In my view, this is even more confusing than current
> > > gridName.
> > > >
> > > > -Val
> > > >
> > > > On Fri, Dec 30, 2016 at 2:42 PM, Denis Magda <dmagda@gridgain.com>
> > > wrote:
> > > >
> > > >> Alexander, frankly speaking I'm still for your original proposal -
> > > >> nodeName. The uniqueness specificities can be set in the doc.
> > > >>
> > > >> --
> > > >> Denis
> > > >>
> > > >> On Friday, December 30, 2016, Alexander Fedotov <
> > > >> alexander.fedotoff@gmail.com> wrote:
> > > >> > Well, then may be we should go with one of the below names:
> > > >> >
> > > >> > processNodeName
> > > >> > jvmNodeName
> > > >> > runtimeNodeName
> > > >> > processScopedNodeName
> > > >> > jvmScopedNodeName
> > > >> > runtimeScopedNodeName
> > > >> > processWideNodeName
> > > >> > jvmWideNodeName
> > > >> > runtimeWideNodeName
> > > >> >
> > > >> > Regards,
> > > >> > Alexander
> > > >> >
> > > >> > 31 дек. 2016 г. 12:37 AM пользователь "Denis
Magda" <
> > > dmagda@apache.org>
> > > >> > написал:
> > > >> >
> > > >> > The parameter specifies a node name which has to be unique per
JVM
> > > >> process
> > > >> > (if you start multiple nodes in a single process). In my
> > understanding
> > > it
> > > >> > was mainly introduced to handle these multiple-nodes-per-JVM
> > > scenarios.
> > > >> >
> > > >> > However, several nodes can have the same name cluster wide.
> > > >> >
> > > >> > —
> > > >> > Denis
> > > >> >
> > > >> >
> > > >> >> On Dec 30, 2016, at 1:30 PM, Dmitriy Setrakyan <
> > > dsetrakyan@apache.org>
> > > >> > wrote:
> > > >> >>
> > > >> >> Now I am confused. What is the purpose of this configuration
> > > parameter?
> > > >> >>
> > > >> >> On Fri, Dec 30, 2016 at 1:15 PM, Denis Magda <dmagda@apache.org>
> > > wrote:
> > > >> >>
> > > >> >>> See Val’s concern in the discussion. I’m absolutely
fine with
> > > >> ‘nodeName’.
> > > >> >>>
> > > >> >>> —
> > > >> >>> Denis
> > > >> >>>
> > > >> >>>> On Dec 30, 2016, at 1:13 PM, Dmitriy Setrakyan <
> > > dsetrakyan@apache.org
> > > >> >
> > > >> >>> wrote:
> > > >> >>>>
> > > >> >>>> On Fri, Dec 30, 2016 at 1:12 PM, Denis Magda <
> dmagda@apache.org>
> > > >> wrote:
> > > >> >>>>
> > > >> >>>>> What’s about ‘localNodeName’?
> > > >> >>>>>
> > > >> >>>>
> > > >> >>>> Why is it better than "nodeName"? Isn't it obvious
that the
> name
> > is
> > > >> for
> > > >> >>> the
> > > >> >>>> local node?
> > > >> >>>
> > > >> >>>
> > > >> >
> > > >>
> > > >
> > >
> >
> >
> >
>
>
> --
> Kind regards,
> Alexander.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message