ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Fedotov <alexander.fedot...@gmail.com>
Subject Re: IgniteConfiguration.gridName is very confusing
Date Sat, 31 Dec 2016 08:23:18 GMT
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?
> >> >>>
> >> >>>
> >> >
> >>
> >
>

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