You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by afedotov <al...@gmail.com> on 2016/12/30 10:53:24 UTC
Re: IgniteConfiguration.gridName is very confusing
Hello!
Looks like there has not been any activity on the issue since July, so I've
taken the issue.
I still have a concern regarding the naming: "instanceName" is quite vague
in some contexts like IgniteThread, SpringCacheManage etc. I would suggest
naming it like "gridInstanceName" or "nodeName". Also to make clear that the
name is effective locally "localNodeName" or "localGridInstanceName" could
be used.
Any considerations in this regard?
dsetrakyan wrote
> Biao, are you still working on this ticket or should someone else in the
> community pick it up?
>
> On Fri, Aug 5, 2016 at 1:53 AM, Pavel Tupitsyn <
> ptupitsyn@
> > wrote:
>
>> We keep getting a steady stream of users confused by gridName :)
>>
>> https://issues.apache.org/jira/browse/IGNITE-3207 seems to be abandoned,
>> should we unassign it?
>>
>> Pavel.
>>
>> On Fri, May 27, 2016 at 8:10 PM, Dmitriy Setrakyan <
> dsetrakyan@
> >
>> wrote:
>>
>> > Great! I think I like “instanceName” better, just in case if this name
>> will
>> > be provided for information purposes on other nodes.
>> >
>> > D.
>> >
>> > On Fri, May 27, 2016 at 2:29 AM, Pavel Tupitsyn <
> ptupitsyn@
> >
>> > wrote:
>> >
>> > > Done: https://issues.apache.org/jira/browse/IGNITE-3207
>> > >
>> > > I have stated "localInstanceName" there, because "instanceName" may
>> not
>> > be
>> > > clear enough.
>> > >
>> > > Pavel.
>> > >
>> > > On Fri, May 27, 2016 at 12:19 PM, Dmitriy Setrakyan <
>> >
> dsetrakyan@
>> > > >
>> > > wrote:
>> > >
>> > > > I like the change, as long as we do not remove, but *deprecate* the
>> > > > gridName property and update all the documentation and examples.
>> > > >
>> > > > Pavel, can you please file a ticket?
>> > > >
>> > > > D.
>> > > >
>> > > > On Tue, May 24, 2016 at 1:56 AM, Pavel Tupitsyn <
>> >
> ptupitsyn@
>>
>> > > > wrote:
>> > > >
>> > > > > Igniters,
>> > > > >
>> > > > > We have got a TON of questions on gridName property. Everyone
>> thinks
>> > > that
>> > > > > clusters are formed based on the gridName, that is, nodes with
>> the
>> > same
>> > > > > grid name will join one cluster, and nodes with a different name
>> will
>> > > be
>> > > > in
>> > > > > a separate cluster.
>> > > > >
>> > > > > I suggest to deprecate this property and add instanceName
>> instead.
>> > > > >
>> > > > > Thoughts?
>> > > > >
>> > > > > Pavel.
>> > > > >
>> > > >
>> > >
>> >
>>
-----
Kind regards,
Alexander
--
View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/IgniteConfiguration-gridName-is-very-confusing-tp9077p13451.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
Re: IgniteConfiguration.gridName is very confusing
Posted by Denis Magda <dm...@apache.org>.
Alexander,
May I ask you to update Apache Ignite 2.0 migration guide?
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide <https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
There you need to say that IgniteConfiguration.gridNama parameter has been changed to the other one that behaves this or that way.
—
Denis
> On Mar 13, 2017, at 4:37 AM, Semyon Boikov <sb...@gridgain.com> wrote:
>
> Thank you Alexander, I merged these changes.
>
> I recommend everybody get latest chages from ignite-2.0.
>
> Thanks!
>
> On Mon, Mar 13, 2017 at 1:23 PM, Alexander Fedotov <
> alexander.fedotoff@gmail.com> wrote:
>
>> PR updated
>>
>> On Mon, Mar 13, 2017 at 1:05 PM, Alexander Fedotov <
>> alexander.fedotoff@gmail.com> wrote:
>>
>>> Okay. Will do it shortly.
>>>
>>> On Mon, Mar 13, 2017 at 1:03 PM, Semyon Boikov <sb...@gridgain.com>
>>> wrote:
>>>
>>>> Alexander,
>>>>
>>>> I see there are conflicts again, could you plase resolve them, I'm going
>>>> to
>>>> review and merge these changes today.
>>>>
>>>> Thanks!
>>>>
>>>> On Fri, Mar 10, 2017 at 5:50 PM, Yakov Zhdanov <yz...@apache.org>
>>>> wrote:
>>>>
>>>>> Thanks, Alex!
>>>>>
>>>>> Sam, can you please also take a look to make sure we catch all
>> possible
>>>>> issues on review? Let's merge this on Monday since this is very
>>>>> conflict-prone change.
>>>>>
>>>>> --Yakov
>>>>>
>>>>> 2017-03-10 12:57 GMT+03:00 Alexander Fedotov <
>>>> alexander.fedotoff@gmail.com
>>>>>> :
>>>>>
>>>>>> Hi,
>>>>>> PR updated. Currently no conflicts at
>>>>>> https://github.com/apache/ignite/pull/1435.
>>>>>>
>>>>>> On Thu, Mar 9, 2017 at 6:50 PM, Alexander Fedotov <
>>>>>> alexander.fedotoff@gmail.com> wrote:
>>>>>>
>>>>>>> Sure. Will take a look.
>>>>>>>
>>>>>>> On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov <
>> yzhdanov@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>>> Alexander,
>>>>>>>>
>>>>>>>> Page https://github.com/apache/ignite/pull/1435 reports several
>>>>>>>> conflicts.
>>>>>>>> Can you please check and resolve if necessary. Then resubmit for
>>>>> review
>>>>>>>> again.
>>>>>>>>
>>>>>>>> --Yakov
>>>>>>>>
>>>>>>>> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov <
>>>>>>>> alexander.fedotoff@gmail.com>:
>>>>>>>>
>>>>>>>>> Hi, it's ready for review
>>>>>>>>> http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
>>>>>>>>>
>>>>>>>>> On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <
>>>> yzhdanov@apache.org
>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Guys, I want to bring this up. What is the status of this
>>>> ticket
>>>>> and
>>>>>>>>>> further steps?
>>>>>>>>>>
>>>>>>>>>> --Yakov
>>>>>>>>>>
>>>>>>>>>> 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
>>>>>>>>> alexander.fedotoff@gmail.com
>>>>>>>>>>> :
>>>>>>>>>>
>>>>>>>>>>> Done. But it looks like something went wrong since Upsource
>>>>>> reports:
>>>>>>>>>>> "Review has too many files (1244), aborting".
>>>>>>>>>>>
>>>>>>>>>>> Also guys, I believe we need to merge this change in short
>>>> time
>>>>>>>> because
>>>>>>>>>>> it's targeted for 2.0 and chances for a conflict are high.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
>>>>>>>> ptupitsyn@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Alexander,
>>>>>>>>>>>>
>>>>>>>>>>>> Please name the review appropriately and link it in the
>>>> ticket
>>>>>> as
>>>>>>>>>>>> described:
>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/How+
>>>>>>>>>>>> to+Contribute#HowtoContribute-ReviewWithUpsource
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Pavel
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
>>>>>>>>>>>> alexander.fedotoff@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Created Upsource review for the subject:
>>>>>>>>>>>>> http://reviews.ignite.apache.o
>>>> rg/ignite/review/IGNT-CR-81
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
>>>>>>>>>>>>> alexander.fedotoff@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've completed working on IGNITE-3207
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3207
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looks like TC test results don't have problems
>> related
>>>> to
>>>>> my
>>>>>>>>>> changes
>>>>>>>>>>>>>> http://ci.ignite.apache.org/vi
>>>> ewLog.html?buildId=423955&
>>>>>>>>>>>>>> tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Kindly take a look at PR https://github.com/apache/
>>>>>>>>>> ignite/pull/1435/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
>>>>>>>> dmagda@apache.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Support Pavel’s point of view.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also Alexander please make sure that your changes
>> are
>>>>>> merged
>>>>>>>>> into
>>>>>>>>>>>>>>> ignite-2.0 branch rather than to the master. I think
>>>> this
>>>>>>>>>>>> functionality
>>>>>>>>>>>>>>> has to be available in 2.0 first. Finally, please
>>>> update
>>>>>> 2.0
>>>>>>>>>>> Migration
>>>>>>>>>>>>>>> Guide once you’ve finished with this task:
>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
>>>>> Apache+
>>>>>>>>>>>>>>> Ignite+2.0+Migration+Guide <
>>>>> https://cwiki.apache.org/conf
>>>>>>>>>>>>>>> luence/display/IGNITE/Apache+I
>>>> gnite+2.0+Migration+Guide>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> —
>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
>>>>>>>>>> ptupitsyn@apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>> Alexander.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>> Alexander.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Kind regards,
>>>>>>>>>>> Alexander.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Kind regards,
>>>>>>>>> Alexander.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Kind regards,
>>>>>>> Alexander.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Kind regards,
>>>>>> Alexander.
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Kind regards,
>>> Alex.
>>>
>>
>>
>>
>> --
>> Kind regards,
>> Alex.
>>
Re: IgniteConfiguration.gridName is very confusing
Posted by Semyon Boikov <sb...@gridgain.com>.
Thank you Alexander, I merged these changes.
I recommend everybody get latest chages from ignite-2.0.
Thanks!
On Mon, Mar 13, 2017 at 1:23 PM, Alexander Fedotov <
alexander.fedotoff@gmail.com> wrote:
> PR updated
>
> On Mon, Mar 13, 2017 at 1:05 PM, Alexander Fedotov <
> alexander.fedotoff@gmail.com> wrote:
>
> > Okay. Will do it shortly.
> >
> > On Mon, Mar 13, 2017 at 1:03 PM, Semyon Boikov <sb...@gridgain.com>
> > wrote:
> >
> >> Alexander,
> >>
> >> I see there are conflicts again, could you plase resolve them, I'm going
> >> to
> >> review and merge these changes today.
> >>
> >> Thanks!
> >>
> >> On Fri, Mar 10, 2017 at 5:50 PM, Yakov Zhdanov <yz...@apache.org>
> >> wrote:
> >>
> >> > Thanks, Alex!
> >> >
> >> > Sam, can you please also take a look to make sure we catch all
> possible
> >> > issues on review? Let's merge this on Monday since this is very
> >> > conflict-prone change.
> >> >
> >> > --Yakov
> >> >
> >> > 2017-03-10 12:57 GMT+03:00 Alexander Fedotov <
> >> alexander.fedotoff@gmail.com
> >> > >:
> >> >
> >> > > Hi,
> >> > > PR updated. Currently no conflicts at
> >> > > https://github.com/apache/ignite/pull/1435.
> >> > >
> >> > > On Thu, Mar 9, 2017 at 6:50 PM, Alexander Fedotov <
> >> > > alexander.fedotoff@gmail.com> wrote:
> >> > >
> >> > > > Sure. Will take a look.
> >> > > >
> >> > > > On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov <
> yzhdanov@apache.org>
> >> > > wrote:
> >> > > >
> >> > > >> Alexander,
> >> > > >>
> >> > > >> Page https://github.com/apache/ignite/pull/1435 reports several
> >> > > >> conflicts.
> >> > > >> Can you please check and resolve if necessary. Then resubmit for
> >> > review
> >> > > >> again.
> >> > > >>
> >> > > >> --Yakov
> >> > > >>
> >> > > >> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov <
> >> > > >> alexander.fedotoff@gmail.com>:
> >> > > >>
> >> > > >> > Hi, it's ready for review
> >> > > >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> >> > > >> >
> >> > > >> > On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <
> >> yzhdanov@apache.org
> >> > >
> >> > > >> > wrote:
> >> > > >> >
> >> > > >> > > Guys, I want to bring this up. What is the status of this
> >> ticket
> >> > and
> >> > > >> > > further steps?
> >> > > >> > >
> >> > > >> > > --Yakov
> >> > > >> > >
> >> > > >> > > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
> >> > > >> > alexander.fedotoff@gmail.com
> >> > > >> > > >:
> >> > > >> > >
> >> > > >> > > > Done. But it looks like something went wrong since Upsource
> >> > > reports:
> >> > > >> > > > "Review has too many files (1244), aborting".
> >> > > >> > > >
> >> > > >> > > > Also guys, I believe we need to merge this change in short
> >> time
> >> > > >> because
> >> > > >> > > > it's targeted for 2.0 and chances for a conflict are high.
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
> >> > > >> ptupitsyn@apache.org>
> >> > > >> > > > wrote:
> >> > > >> > > >
> >> > > >> > > > > Alexander,
> >> > > >> > > > >
> >> > > >> > > > > Please name the review appropriately and link it in the
> >> ticket
> >> > > as
> >> > > >> > > > > described:
> >> > > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> >> > > >> > > > > to+Contribute#HowtoContribute-ReviewWithUpsource
> >> > > >> > > > >
> >> > > >> > > > > Thanks,
> >> > > >> > > > > Pavel
> >> > > >> > > > >
> >> > > >> > > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> >> > > >> > > > > alexander.fedotoff@gmail.com> wrote:
> >> > > >> > > > >
> >> > > >> > > > > > Hi,
> >> > > >> > > > > >
> >> > > >> > > > > > Created Upsource review for the subject:
> >> > > >> > > > > > http://reviews.ignite.apache.o
> >> rg/ignite/review/IGNT-CR-81
> >> > > >> > > > > >
> >> > > >> > > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> >> > > >> > > > > > alexander.fedotoff@gmail.com> wrote:
> >> > > >> > > > > >
> >> > > >> > > > > > > Hi,
> >> > > >> > > > > > >
> >> > > >> > > > > > > I've completed working on IGNITE-3207
> >> > > >> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
> >> > > >> > > > > > >
> >> > > >> > > > > > > Looks like TC test results don't have problems
> related
> >> to
> >> > my
> >> > > >> > > changes
> >> > > >> > > > > > > http://ci.ignite.apache.org/vi
> >> ewLog.html?buildId=423955&
> >> > > >> > > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> >> > > >> > > > > > >
> >> > > >> > > > > > > Kindly take a look at PR https://github.com/apache/
> >> > > >> > > ignite/pull/1435/
> >> > > >> > > > > > >
> >> > > >> > > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
> >> > > >> dmagda@apache.org>
> >> > > >> > > > > wrote:
> >> > > >> > > > > > >
> >> > > >> > > > > > >> Support Pavel’s point of view.
> >> > > >> > > > > > >>
> >> > > >> > > > > > >> Also Alexander please make sure that your changes
> are
> >> > > merged
> >> > > >> > into
> >> > > >> > > > > > >> ignite-2.0 branch rather than to the master. I think
> >> this
> >> > > >> > > > > functionality
> >> > > >> > > > > > >> has to be available in 2.0 first. Finally, please
> >> update
> >> > > 2.0
> >> > > >> > > > Migration
> >> > > >> > > > > > >> Guide once you’ve finished with this task:
> >> > > >> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/
> >> > Apache+
> >> > > >> > > > > > >> Ignite+2.0+Migration+Guide <
> >> > https://cwiki.apache.org/conf
> >> > > >> > > > > > >> luence/display/IGNITE/Apache+I
> >> gnite+2.0+Migration+Guide>
> >> > > >> > > > > > >>
> >> > > >> > > > > > >> —
> >> > > >> > > > > > >> Denis
> >> > > >> > > > > > >>
> >> > > >> > > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
> >> > > >> > > ptupitsyn@apache.org
> >> > > >> > > > >
> >> > > >> > > > > > >> wrote:
> >> > > >> > > > > > >> >
> >> > > >> > > > > > >> > 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.
> >> > > >> > > > > > >> >>
> >> > > >> > > > > > >>
> >> > > >> > > > > > >>
> >> > > >> > > > > > >
> >> > > >> > > > > > >
> >> > > >> > > > > > > --
> >> > > >> > > > > > > Kind regards,
> >> > > >> > > > > > > Alexander.
> >> > > >> > > > > > >
> >> > > >> > > > > >
> >> > > >> > > > > >
> >> > > >> > > > > >
> >> > > >> > > > > > --
> >> > > >> > > > > > Kind regards,
> >> > > >> > > > > > Alexander.
> >> > > >> > > > > >
> >> > > >> > > > >
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > > --
> >> > > >> > > > Kind regards,
> >> > > >> > > > Alexander.
> >> > > >> > > >
> >> > > >> > >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > --
> >> > > >> > Kind regards,
> >> > > >> > Alexander.
> >> > > >> >
> >> > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Kind regards,
> >> > > > Alexander.
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Kind regards,
> >> > > Alexander.
> >> > >
> >> >
> >>
> >
> >
> >
> > --
> > Kind regards,
> > Alex.
> >
>
>
>
> --
> Kind regards,
> Alex.
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
PR updated
On Mon, Mar 13, 2017 at 1:05 PM, Alexander Fedotov <
alexander.fedotoff@gmail.com> wrote:
> Okay. Will do it shortly.
>
> On Mon, Mar 13, 2017 at 1:03 PM, Semyon Boikov <sb...@gridgain.com>
> wrote:
>
>> Alexander,
>>
>> I see there are conflicts again, could you plase resolve them, I'm going
>> to
>> review and merge these changes today.
>>
>> Thanks!
>>
>> On Fri, Mar 10, 2017 at 5:50 PM, Yakov Zhdanov <yz...@apache.org>
>> wrote:
>>
>> > Thanks, Alex!
>> >
>> > Sam, can you please also take a look to make sure we catch all possible
>> > issues on review? Let's merge this on Monday since this is very
>> > conflict-prone change.
>> >
>> > --Yakov
>> >
>> > 2017-03-10 12:57 GMT+03:00 Alexander Fedotov <
>> alexander.fedotoff@gmail.com
>> > >:
>> >
>> > > Hi,
>> > > PR updated. Currently no conflicts at
>> > > https://github.com/apache/ignite/pull/1435.
>> > >
>> > > On Thu, Mar 9, 2017 at 6:50 PM, Alexander Fedotov <
>> > > alexander.fedotoff@gmail.com> wrote:
>> > >
>> > > > Sure. Will take a look.
>> > > >
>> > > > On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov <yz...@apache.org>
>> > > wrote:
>> > > >
>> > > >> Alexander,
>> > > >>
>> > > >> Page https://github.com/apache/ignite/pull/1435 reports several
>> > > >> conflicts.
>> > > >> Can you please check and resolve if necessary. Then resubmit for
>> > review
>> > > >> again.
>> > > >>
>> > > >> --Yakov
>> > > >>
>> > > >> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov <
>> > > >> alexander.fedotoff@gmail.com>:
>> > > >>
>> > > >> > Hi, it's ready for review
>> > > >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
>> > > >> >
>> > > >> > On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <
>> yzhdanov@apache.org
>> > >
>> > > >> > wrote:
>> > > >> >
>> > > >> > > Guys, I want to bring this up. What is the status of this
>> ticket
>> > and
>> > > >> > > further steps?
>> > > >> > >
>> > > >> > > --Yakov
>> > > >> > >
>> > > >> > > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
>> > > >> > alexander.fedotoff@gmail.com
>> > > >> > > >:
>> > > >> > >
>> > > >> > > > Done. But it looks like something went wrong since Upsource
>> > > reports:
>> > > >> > > > "Review has too many files (1244), aborting".
>> > > >> > > >
>> > > >> > > > Also guys, I believe we need to merge this change in short
>> time
>> > > >> because
>> > > >> > > > it's targeted for 2.0 and chances for a conflict are high.
>> > > >> > > >
>> > > >> > > >
>> > > >> > > >
>> > > >> > > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
>> > > >> ptupitsyn@apache.org>
>> > > >> > > > wrote:
>> > > >> > > >
>> > > >> > > > > Alexander,
>> > > >> > > > >
>> > > >> > > > > Please name the review appropriately and link it in the
>> ticket
>> > > as
>> > > >> > > > > described:
>> > > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
>> > > >> > > > > to+Contribute#HowtoContribute-ReviewWithUpsource
>> > > >> > > > >
>> > > >> > > > > Thanks,
>> > > >> > > > > Pavel
>> > > >> > > > >
>> > > >> > > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
>> > > >> > > > > alexander.fedotoff@gmail.com> wrote:
>> > > >> > > > >
>> > > >> > > > > > Hi,
>> > > >> > > > > >
>> > > >> > > > > > Created Upsource review for the subject:
>> > > >> > > > > > http://reviews.ignite.apache.o
>> rg/ignite/review/IGNT-CR-81
>> > > >> > > > > >
>> > > >> > > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
>> > > >> > > > > > alexander.fedotoff@gmail.com> wrote:
>> > > >> > > > > >
>> > > >> > > > > > > Hi,
>> > > >> > > > > > >
>> > > >> > > > > > > I've completed working on IGNITE-3207
>> > > >> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
>> > > >> > > > > > >
>> > > >> > > > > > > Looks like TC test results don't have problems related
>> to
>> > my
>> > > >> > > changes
>> > > >> > > > > > > http://ci.ignite.apache.org/vi
>> ewLog.html?buildId=423955&
>> > > >> > > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
>> > > >> > > > > > >
>> > > >> > > > > > > Kindly take a look at PR https://github.com/apache/
>> > > >> > > ignite/pull/1435/
>> > > >> > > > > > >
>> > > >> > > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
>> > > >> dmagda@apache.org>
>> > > >> > > > > wrote:
>> > > >> > > > > > >
>> > > >> > > > > > >> Support Pavel’s point of view.
>> > > >> > > > > > >>
>> > > >> > > > > > >> Also Alexander please make sure that your changes are
>> > > merged
>> > > >> > into
>> > > >> > > > > > >> ignite-2.0 branch rather than to the master. I think
>> this
>> > > >> > > > > functionality
>> > > >> > > > > > >> has to be available in 2.0 first. Finally, please
>> update
>> > > 2.0
>> > > >> > > > Migration
>> > > >> > > > > > >> Guide once you’ve finished with this task:
>> > > >> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/
>> > Apache+
>> > > >> > > > > > >> Ignite+2.0+Migration+Guide <
>> > https://cwiki.apache.org/conf
>> > > >> > > > > > >> luence/display/IGNITE/Apache+I
>> gnite+2.0+Migration+Guide>
>> > > >> > > > > > >>
>> > > >> > > > > > >> —
>> > > >> > > > > > >> Denis
>> > > >> > > > > > >>
>> > > >> > > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
>> > > >> > > ptupitsyn@apache.org
>> > > >> > > > >
>> > > >> > > > > > >> wrote:
>> > > >> > > > > > >> >
>> > > >> > > > > > >> > 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.
>> > > >> > > > > > >> >>
>> > > >> > > > > > >>
>> > > >> > > > > > >>
>> > > >> > > > > > >
>> > > >> > > > > > >
>> > > >> > > > > > > --
>> > > >> > > > > > > Kind regards,
>> > > >> > > > > > > Alexander.
>> > > >> > > > > > >
>> > > >> > > > > >
>> > > >> > > > > >
>> > > >> > > > > >
>> > > >> > > > > > --
>> > > >> > > > > > Kind regards,
>> > > >> > > > > > Alexander.
>> > > >> > > > > >
>> > > >> > > > >
>> > > >> > > >
>> > > >> > > >
>> > > >> > > >
>> > > >> > > > --
>> > > >> > > > Kind regards,
>> > > >> > > > Alexander.
>> > > >> > > >
>> > > >> > >
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > --
>> > > >> > Kind regards,
>> > > >> > Alexander.
>> > > >> >
>> > > >>
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Kind regards,
>> > > > Alexander.
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Kind regards,
>> > > Alexander.
>> > >
>> >
>>
>
>
>
> --
> Kind regards,
> Alex.
>
--
Kind regards,
Alex.
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
Okay. Will do it shortly.
On Mon, Mar 13, 2017 at 1:03 PM, Semyon Boikov <sb...@gridgain.com> wrote:
> Alexander,
>
> I see there are conflicts again, could you plase resolve them, I'm going to
> review and merge these changes today.
>
> Thanks!
>
> On Fri, Mar 10, 2017 at 5:50 PM, Yakov Zhdanov <yz...@apache.org>
> wrote:
>
> > Thanks, Alex!
> >
> > Sam, can you please also take a look to make sure we catch all possible
> > issues on review? Let's merge this on Monday since this is very
> > conflict-prone change.
> >
> > --Yakov
> >
> > 2017-03-10 12:57 GMT+03:00 Alexander Fedotov <
> alexander.fedotoff@gmail.com
> > >:
> >
> > > Hi,
> > > PR updated. Currently no conflicts at
> > > https://github.com/apache/ignite/pull/1435.
> > >
> > > On Thu, Mar 9, 2017 at 6:50 PM, Alexander Fedotov <
> > > alexander.fedotoff@gmail.com> wrote:
> > >
> > > > Sure. Will take a look.
> > > >
> > > > On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov <yz...@apache.org>
> > > wrote:
> > > >
> > > >> Alexander,
> > > >>
> > > >> Page https://github.com/apache/ignite/pull/1435 reports several
> > > >> conflicts.
> > > >> Can you please check and resolve if necessary. Then resubmit for
> > review
> > > >> again.
> > > >>
> > > >> --Yakov
> > > >>
> > > >> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov <
> > > >> alexander.fedotoff@gmail.com>:
> > > >>
> > > >> > Hi, it's ready for review
> > > >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > > >> >
> > > >> > On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <
> yzhdanov@apache.org
> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Guys, I want to bring this up. What is the status of this ticket
> > and
> > > >> > > further steps?
> > > >> > >
> > > >> > > --Yakov
> > > >> > >
> > > >> > > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
> > > >> > alexander.fedotoff@gmail.com
> > > >> > > >:
> > > >> > >
> > > >> > > > Done. But it looks like something went wrong since Upsource
> > > reports:
> > > >> > > > "Review has too many files (1244), aborting".
> > > >> > > >
> > > >> > > > Also guys, I believe we need to merge this change in short
> time
> > > >> because
> > > >> > > > it's targeted for 2.0 and chances for a conflict are high.
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
> > > >> ptupitsyn@apache.org>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > Alexander,
> > > >> > > > >
> > > >> > > > > Please name the review appropriately and link it in the
> ticket
> > > as
> > > >> > > > > described:
> > > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > > >> > > > > to+Contribute#HowtoContribute-ReviewWithUpsource
> > > >> > > > >
> > > >> > > > > Thanks,
> > > >> > > > > Pavel
> > > >> > > > >
> > > >> > > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> > > >> > > > > alexander.fedotoff@gmail.com> wrote:
> > > >> > > > >
> > > >> > > > > > Hi,
> > > >> > > > > >
> > > >> > > > > > Created Upsource review for the subject:
> > > >> > > > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > > >> > > > > >
> > > >> > > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> > > >> > > > > > alexander.fedotoff@gmail.com> wrote:
> > > >> > > > > >
> > > >> > > > > > > Hi,
> > > >> > > > > > >
> > > >> > > > > > > I've completed working on IGNITE-3207
> > > >> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
> > > >> > > > > > >
> > > >> > > > > > > Looks like TC test results don't have problems related
> to
> > my
> > > >> > > changes
> > > >> > > > > > > http://ci.ignite.apache.org/
> viewLog.html?buildId=423955&
> > > >> > > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> > > >> > > > > > >
> > > >> > > > > > > Kindly take a look at PR https://github.com/apache/
> > > >> > > ignite/pull/1435/
> > > >> > > > > > >
> > > >> > > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
> > > >> dmagda@apache.org>
> > > >> > > > > wrote:
> > > >> > > > > > >
> > > >> > > > > > >> Support Pavel’s point of view.
> > > >> > > > > > >>
> > > >> > > > > > >> Also Alexander please make sure that your changes are
> > > merged
> > > >> > into
> > > >> > > > > > >> ignite-2.0 branch rather than to the master. I think
> this
> > > >> > > > > functionality
> > > >> > > > > > >> has to be available in 2.0 first. Finally, please
> update
> > > 2.0
> > > >> > > > Migration
> > > >> > > > > > >> Guide once you’ve finished with this task:
> > > >> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/
> > Apache+
> > > >> > > > > > >> Ignite+2.0+Migration+Guide <
> > https://cwiki.apache.org/conf
> > > >> > > > > > >> luence/display/IGNITE/Apache+
> Ignite+2.0+Migration+Guide>
> > > >> > > > > > >>
> > > >> > > > > > >> —
> > > >> > > > > > >> Denis
> > > >> > > > > > >>
> > > >> > > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
> > > >> > > ptupitsyn@apache.org
> > > >> > > > >
> > > >> > > > > > >> wrote:
> > > >> > > > > > >> >
> > > >> > > > > > >> > 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.
> > > >> > > > > > >> >>
> > > >> > > > > > >>
> > > >> > > > > > >>
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > --
> > > >> > > > > > > Kind regards,
> > > >> > > > > > > Alexander.
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > --
> > > >> > > > > > Kind regards,
> > > >> > > > > > Alexander.
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > Kind regards,
> > > >> > > > Alexander.
> > > >> > > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Kind regards,
> > > >> > Alexander.
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Kind regards,
> > > > Alexander.
> > > >
> > >
> > >
> > >
> > > --
> > > Kind regards,
> > > Alexander.
> > >
> >
>
--
Kind regards,
Alex.
Re: IgniteConfiguration.gridName is very confusing
Posted by Semyon Boikov <sb...@gridgain.com>.
Alexander,
I see there are conflicts again, could you plase resolve them, I'm going to
review and merge these changes today.
Thanks!
On Fri, Mar 10, 2017 at 5:50 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> Thanks, Alex!
>
> Sam, can you please also take a look to make sure we catch all possible
> issues on review? Let's merge this on Monday since this is very
> conflict-prone change.
>
> --Yakov
>
> 2017-03-10 12:57 GMT+03:00 Alexander Fedotov <alexander.fedotoff@gmail.com
> >:
>
> > Hi,
> > PR updated. Currently no conflicts at
> > https://github.com/apache/ignite/pull/1435.
> >
> > On Thu, Mar 9, 2017 at 6:50 PM, Alexander Fedotov <
> > alexander.fedotoff@gmail.com> wrote:
> >
> > > Sure. Will take a look.
> > >
> > > On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov <yz...@apache.org>
> > wrote:
> > >
> > >> Alexander,
> > >>
> > >> Page https://github.com/apache/ignite/pull/1435 reports several
> > >> conflicts.
> > >> Can you please check and resolve if necessary. Then resubmit for
> review
> > >> again.
> > >>
> > >> --Yakov
> > >>
> > >> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov <
> > >> alexander.fedotoff@gmail.com>:
> > >>
> > >> > Hi, it's ready for review
> > >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > >> >
> > >> > On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <yzhdanov@apache.org
> >
> > >> > wrote:
> > >> >
> > >> > > Guys, I want to bring this up. What is the status of this ticket
> and
> > >> > > further steps?
> > >> > >
> > >> > > --Yakov
> > >> > >
> > >> > > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
> > >> > alexander.fedotoff@gmail.com
> > >> > > >:
> > >> > >
> > >> > > > Done. But it looks like something went wrong since Upsource
> > reports:
> > >> > > > "Review has too many files (1244), aborting".
> > >> > > >
> > >> > > > Also guys, I believe we need to merge this change in short time
> > >> because
> > >> > > > it's targeted for 2.0 and chances for a conflict are high.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
> > >> ptupitsyn@apache.org>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Alexander,
> > >> > > > >
> > >> > > > > Please name the review appropriately and link it in the ticket
> > as
> > >> > > > > described:
> > >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > >> > > > > to+Contribute#HowtoContribute-ReviewWithUpsource
> > >> > > > >
> > >> > > > > Thanks,
> > >> > > > > Pavel
> > >> > > > >
> > >> > > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> > >> > > > > alexander.fedotoff@gmail.com> wrote:
> > >> > > > >
> > >> > > > > > Hi,
> > >> > > > > >
> > >> > > > > > Created Upsource review for the subject:
> > >> > > > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > >> > > > > >
> > >> > > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> > >> > > > > > alexander.fedotoff@gmail.com> wrote:
> > >> > > > > >
> > >> > > > > > > Hi,
> > >> > > > > > >
> > >> > > > > > > I've completed working on IGNITE-3207
> > >> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
> > >> > > > > > >
> > >> > > > > > > Looks like TC test results don't have problems related to
> my
> > >> > > changes
> > >> > > > > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&
> > >> > > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> > >> > > > > > >
> > >> > > > > > > Kindly take a look at PR https://github.com/apache/
> > >> > > ignite/pull/1435/
> > >> > > > > > >
> > >> > > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
> > >> dmagda@apache.org>
> > >> > > > > wrote:
> > >> > > > > > >
> > >> > > > > > >> Support Pavel’s point of view.
> > >> > > > > > >>
> > >> > > > > > >> Also Alexander please make sure that your changes are
> > merged
> > >> > into
> > >> > > > > > >> ignite-2.0 branch rather than to the master. I think this
> > >> > > > > functionality
> > >> > > > > > >> has to be available in 2.0 first. Finally, please update
> > 2.0
> > >> > > > Migration
> > >> > > > > > >> Guide once you’ve finished with this task:
> > >> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/
> Apache+
> > >> > > > > > >> Ignite+2.0+Migration+Guide <
> https://cwiki.apache.org/conf
> > >> > > > > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> > >> > > > > > >>
> > >> > > > > > >> —
> > >> > > > > > >> Denis
> > >> > > > > > >>
> > >> > > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
> > >> > > ptupitsyn@apache.org
> > >> > > > >
> > >> > > > > > >> wrote:
> > >> > > > > > >> >
> > >> > > > > > >> > 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.
> > >> > > > > > >> >>
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > --
> > >> > > > > > > Kind regards,
> > >> > > > > > > Alexander.
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > --
> > >> > > > > > Kind regards,
> > >> > > > > > Alexander.
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Kind regards,
> > >> > > > Alexander.
> > >> > > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Kind regards,
> > >> > Alexander.
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Kind regards,
> > > Alexander.
> > >
> >
> >
> >
> > --
> > Kind regards,
> > Alexander.
> >
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Yakov Zhdanov <yz...@apache.org>.
Thanks, Alex!
Sam, can you please also take a look to make sure we catch all possible
issues on review? Let's merge this on Monday since this is very
conflict-prone change.
--Yakov
2017-03-10 12:57 GMT+03:00 Alexander Fedotov <al...@gmail.com>:
> Hi,
> PR updated. Currently no conflicts at
> https://github.com/apache/ignite/pull/1435.
>
> On Thu, Mar 9, 2017 at 6:50 PM, Alexander Fedotov <
> alexander.fedotoff@gmail.com> wrote:
>
> > Sure. Will take a look.
> >
> > On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov <yz...@apache.org>
> wrote:
> >
> >> Alexander,
> >>
> >> Page https://github.com/apache/ignite/pull/1435 reports several
> >> conflicts.
> >> Can you please check and resolve if necessary. Then resubmit for review
> >> again.
> >>
> >> --Yakov
> >>
> >> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov <
> >> alexander.fedotoff@gmail.com>:
> >>
> >> > Hi, it's ready for review
> >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> >> >
> >> > On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <yz...@apache.org>
> >> > wrote:
> >> >
> >> > > Guys, I want to bring this up. What is the status of this ticket and
> >> > > further steps?
> >> > >
> >> > > --Yakov
> >> > >
> >> > > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
> >> > alexander.fedotoff@gmail.com
> >> > > >:
> >> > >
> >> > > > Done. But it looks like something went wrong since Upsource
> reports:
> >> > > > "Review has too many files (1244), aborting".
> >> > > >
> >> > > > Also guys, I believe we need to merge this change in short time
> >> because
> >> > > > it's targeted for 2.0 and chances for a conflict are high.
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
> >> ptupitsyn@apache.org>
> >> > > > wrote:
> >> > > >
> >> > > > > Alexander,
> >> > > > >
> >> > > > > Please name the review appropriately and link it in the ticket
> as
> >> > > > > described:
> >> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> >> > > > > to+Contribute#HowtoContribute-ReviewWithUpsource
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Pavel
> >> > > > >
> >> > > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> >> > > > > alexander.fedotoff@gmail.com> wrote:
> >> > > > >
> >> > > > > > Hi,
> >> > > > > >
> >> > > > > > Created Upsource review for the subject:
> >> > > > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> >> > > > > >
> >> > > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> >> > > > > > alexander.fedotoff@gmail.com> wrote:
> >> > > > > >
> >> > > > > > > Hi,
> >> > > > > > >
> >> > > > > > > I've completed working on IGNITE-3207
> >> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
> >> > > > > > >
> >> > > > > > > Looks like TC test results don't have problems related to my
> >> > > changes
> >> > > > > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&
> >> > > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> >> > > > > > >
> >> > > > > > > Kindly take a look at PR https://github.com/apache/
> >> > > ignite/pull/1435/
> >> > > > > > >
> >> > > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
> >> dmagda@apache.org>
> >> > > > > wrote:
> >> > > > > > >
> >> > > > > > >> Support Pavel’s point of view.
> >> > > > > > >>
> >> > > > > > >> Also Alexander please make sure that your changes are
> merged
> >> > into
> >> > > > > > >> ignite-2.0 branch rather than to the master. I think this
> >> > > > > functionality
> >> > > > > > >> has to be available in 2.0 first. Finally, please update
> 2.0
> >> > > > Migration
> >> > > > > > >> Guide once you’ve finished with this task:
> >> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
> >> > > > > > >> Ignite+2.0+Migration+Guide <https://cwiki.apache.org/conf
> >> > > > > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> >> > > > > > >>
> >> > > > > > >> —
> >> > > > > > >> Denis
> >> > > > > > >>
> >> > > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
> >> > > ptupitsyn@apache.org
> >> > > > >
> >> > > > > > >> wrote:
> >> > > > > > >> >
> >> > > > > > >> > 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.
> >> > > > > > >> >>
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Kind regards,
> >> > > > > > > Alexander.
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Kind regards,
> >> > > > > > Alexander.
> >> > > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Kind regards,
> >> > > > Alexander.
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Kind regards,
> >> > Alexander.
> >> >
> >>
> >
> >
> >
> > --
> > Kind regards,
> > Alexander.
> >
>
>
>
> --
> Kind regards,
> Alexander.
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
Hi,
PR updated. Currently no conflicts at
https://github.com/apache/ignite/pull/1435.
On Thu, Mar 9, 2017 at 6:50 PM, Alexander Fedotov <
alexander.fedotoff@gmail.com> wrote:
> Sure. Will take a look.
>
> On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov <yz...@apache.org> wrote:
>
>> Alexander,
>>
>> Page https://github.com/apache/ignite/pull/1435 reports several
>> conflicts.
>> Can you please check and resolve if necessary. Then resubmit for review
>> again.
>>
>> --Yakov
>>
>> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov <
>> alexander.fedotoff@gmail.com>:
>>
>> > Hi, it's ready for review
>> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
>> >
>> > On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <yz...@apache.org>
>> > wrote:
>> >
>> > > Guys, I want to bring this up. What is the status of this ticket and
>> > > further steps?
>> > >
>> > > --Yakov
>> > >
>> > > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
>> > alexander.fedotoff@gmail.com
>> > > >:
>> > >
>> > > > Done. But it looks like something went wrong since Upsource reports:
>> > > > "Review has too many files (1244), aborting".
>> > > >
>> > > > Also guys, I believe we need to merge this change in short time
>> because
>> > > > it's targeted for 2.0 and chances for a conflict are high.
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
>> ptupitsyn@apache.org>
>> > > > wrote:
>> > > >
>> > > > > Alexander,
>> > > > >
>> > > > > Please name the review appropriately and link it in the ticket as
>> > > > > described:
>> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
>> > > > > to+Contribute#HowtoContribute-ReviewWithUpsource
>> > > > >
>> > > > > Thanks,
>> > > > > Pavel
>> > > > >
>> > > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
>> > > > > alexander.fedotoff@gmail.com> wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > Created Upsource review for the subject:
>> > > > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
>> > > > > >
>> > > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
>> > > > > > alexander.fedotoff@gmail.com> wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > I've completed working on IGNITE-3207
>> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
>> > > > > > >
>> > > > > > > Looks like TC test results don't have problems related to my
>> > > changes
>> > > > > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&
>> > > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
>> > > > > > >
>> > > > > > > Kindly take a look at PR https://github.com/apache/
>> > > ignite/pull/1435/
>> > > > > > >
>> > > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
>> dmagda@apache.org>
>> > > > > wrote:
>> > > > > > >
>> > > > > > >> Support Pavel’s point of view.
>> > > > > > >>
>> > > > > > >> Also Alexander please make sure that your changes are merged
>> > into
>> > > > > > >> ignite-2.0 branch rather than to the master. I think this
>> > > > > functionality
>> > > > > > >> has to be available in 2.0 first. Finally, please update 2.0
>> > > > Migration
>> > > > > > >> Guide once you’ve finished with this task:
>> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
>> > > > > > >> Ignite+2.0+Migration+Guide <https://cwiki.apache.org/conf
>> > > > > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
>> > > > > > >>
>> > > > > > >> —
>> > > > > > >> Denis
>> > > > > > >>
>> > > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
>> > > ptupitsyn@apache.org
>> > > > >
>> > > > > > >> wrote:
>> > > > > > >> >
>> > > > > > >> > 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.
>> > > > > > >> >>
>> > > > > > >>
>> > > > > > >>
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Kind regards,
>> > > > > > > Alexander.
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Kind regards,
>> > > > > > Alexander.
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Kind regards,
>> > > > Alexander.
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Kind regards,
>> > Alexander.
>> >
>>
>
>
>
> --
> Kind regards,
> Alexander.
>
--
Kind regards,
Alexander.
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
Sure. Will take a look.
On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> Alexander,
>
> Page https://github.com/apache/ignite/pull/1435 reports several conflicts.
> Can you please check and resolve if necessary. Then resubmit for review
> again.
>
> --Yakov
>
> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov <alexander.fedotoff@gmail.com
> >:
>
> > Hi, it's ready for review
> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> >
> > On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <yz...@apache.org>
> > wrote:
> >
> > > Guys, I want to bring this up. What is the status of this ticket and
> > > further steps?
> > >
> > > --Yakov
> > >
> > > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
> > alexander.fedotoff@gmail.com
> > > >:
> > >
> > > > Done. But it looks like something went wrong since Upsource reports:
> > > > "Review has too many files (1244), aborting".
> > > >
> > > > Also guys, I believe we need to merge this change in short time
> because
> > > > it's targeted for 2.0 and chances for a conflict are high.
> > > >
> > > >
> > > >
> > > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
> ptupitsyn@apache.org>
> > > > wrote:
> > > >
> > > > > Alexander,
> > > > >
> > > > > Please name the review appropriately and link it in the ticket as
> > > > > described:
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > > > > to+Contribute#HowtoContribute-ReviewWithUpsource
> > > > >
> > > > > Thanks,
> > > > > Pavel
> > > > >
> > > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> > > > > alexander.fedotoff@gmail.com> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Created Upsource review for the subject:
> > > > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > > > > >
> > > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> > > > > > alexander.fedotoff@gmail.com> wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I've completed working on IGNITE-3207
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
> > > > > > >
> > > > > > > Looks like TC test results don't have problems related to my
> > > changes
> > > > > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&
> > > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> > > > > > >
> > > > > > > Kindly take a look at PR https://github.com/apache/
> > > ignite/pull/1435/
> > > > > > >
> > > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
> dmagda@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > >> Support Pavel’s point of view.
> > > > > > >>
> > > > > > >> Also Alexander please make sure that your changes are merged
> > into
> > > > > > >> ignite-2.0 branch rather than to the master. I think this
> > > > > functionality
> > > > > > >> has to be available in 2.0 first. Finally, please update 2.0
> > > > Migration
> > > > > > >> Guide once you’ve finished with this task:
> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
> > > > > > >> Ignite+2.0+Migration+Guide <https://cwiki.apache.org/conf
> > > > > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> > > > > > >>
> > > > > > >> —
> > > > > > >> Denis
> > > > > > >>
> > > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
> > > ptupitsyn@apache.org
> > > > >
> > > > > > >> wrote:
> > > > > > >> >
> > > > > > >> > 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.
> > > > > > >> >>
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Kind regards,
> > > > > > > Alexander.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Kind regards,
> > > > > > Alexander.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Kind regards,
> > > > Alexander.
> > > >
> > >
> >
> >
> >
> > --
> > Kind regards,
> > Alexander.
> >
>
--
Kind regards,
Alexander.
Re: IgniteConfiguration.gridName is very confusing
Posted by Yakov Zhdanov <yz...@apache.org>.
Alexander,
Page https://github.com/apache/ignite/pull/1435 reports several conflicts.
Can you please check and resolve if necessary. Then resubmit for review
again.
--Yakov
2017-03-03 13:24 GMT+03:00 Alexander Fedotov <al...@gmail.com>:
> Hi, it's ready for review
> http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
>
> On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <yz...@apache.org>
> wrote:
>
> > Guys, I want to bring this up. What is the status of this ticket and
> > further steps?
> >
> > --Yakov
> >
> > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
> alexander.fedotoff@gmail.com
> > >:
> >
> > > Done. But it looks like something went wrong since Upsource reports:
> > > "Review has too many files (1244), aborting".
> > >
> > > Also guys, I believe we need to merge this change in short time because
> > > it's targeted for 2.0 and chances for a conflict are high.
> > >
> > >
> > >
> > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <pt...@apache.org>
> > > wrote:
> > >
> > > > Alexander,
> > > >
> > > > Please name the review appropriately and link it in the ticket as
> > > > described:
> > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > > > to+Contribute#HowtoContribute-ReviewWithUpsource
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> > > > alexander.fedotoff@gmail.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Created Upsource review for the subject:
> > > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > > > >
> > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> > > > > alexander.fedotoff@gmail.com> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I've completed working on IGNITE-3207
> > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
> > > > > >
> > > > > > Looks like TC test results don't have problems related to my
> > changes
> > > > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&
> > > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> > > > > >
> > > > > > Kindly take a look at PR https://github.com/apache/
> > ignite/pull/1435/
> > > > > >
> > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <dm...@apache.org>
> > > > wrote:
> > > > > >
> > > > > >> Support Pavel’s point of view.
> > > > > >>
> > > > > >> Also Alexander please make sure that your changes are merged
> into
> > > > > >> ignite-2.0 branch rather than to the master. I think this
> > > > functionality
> > > > > >> has to be available in 2.0 first. Finally, please update 2.0
> > > Migration
> > > > > >> Guide once you’ve finished with this task:
> > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
> > > > > >> Ignite+2.0+Migration+Guide <https://cwiki.apache.org/conf
> > > > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> > > > > >>
> > > > > >> —
> > > > > >> Denis
> > > > > >>
> > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
> > ptupitsyn@apache.org
> > > >
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > 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.
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Kind regards,
> > > > > > Alexander.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Kind regards,
> > > > > Alexander.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Kind regards,
> > > Alexander.
> > >
> >
>
>
>
> --
> Kind regards,
> Alexander.
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
Hi, it's ready for review
http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> Guys, I want to bring this up. What is the status of this ticket and
> further steps?
>
> --Yakov
>
> 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <alexander.fedotoff@gmail.com
> >:
>
> > Done. But it looks like something went wrong since Upsource reports:
> > "Review has too many files (1244), aborting".
> >
> > Also guys, I believe we need to merge this change in short time because
> > it's targeted for 2.0 and chances for a conflict are high.
> >
> >
> >
> > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <pt...@apache.org>
> > wrote:
> >
> > > Alexander,
> > >
> > > Please name the review appropriately and link it in the ticket as
> > > described:
> > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > > to+Contribute#HowtoContribute-ReviewWithUpsource
> > >
> > > Thanks,
> > > Pavel
> > >
> > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> > > alexander.fedotoff@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Created Upsource review for the subject:
> > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > > >
> > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> > > > alexander.fedotoff@gmail.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I've completed working on IGNITE-3207
> > > > > https://issues.apache.org/jira/browse/IGNITE-3207
> > > > >
> > > > > Looks like TC test results don't have problems related to my
> changes
> > > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&
> > > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> > > > >
> > > > > Kindly take a look at PR https://github.com/apache/
> ignite/pull/1435/
> > > > >
> > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <dm...@apache.org>
> > > wrote:
> > > > >
> > > > >> Support Pavel’s point of view.
> > > > >>
> > > > >> Also Alexander please make sure that your changes are merged into
> > > > >> ignite-2.0 branch rather than to the master. I think this
> > > functionality
> > > > >> has to be available in 2.0 first. Finally, please update 2.0
> > Migration
> > > > >> Guide once you’ve finished with this task:
> > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
> > > > >> Ignite+2.0+Migration+Guide <https://cwiki.apache.org/conf
> > > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> > > > >>
> > > > >> —
> > > > >> Denis
> > > > >>
> > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
> ptupitsyn@apache.org
> > >
> > > > >> wrote:
> > > > >> >
> > > > >> > 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.
> > > > >> >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Kind regards,
> > > > > Alexander.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Kind regards,
> > > > Alexander.
> > > >
> > >
> >
> >
> >
> > --
> > Kind regards,
> > Alexander.
> >
>
--
Kind regards,
Alexander.
Re: IgniteConfiguration.gridName is very confusing
Posted by Yakov Zhdanov <yz...@apache.org>.
Guys, I want to bring this up. What is the status of this ticket and
further steps?
--Yakov
2017-01-30 16:37 GMT+03:00 Alexander Fedotov <al...@gmail.com>:
> Done. But it looks like something went wrong since Upsource reports:
> "Review has too many files (1244), aborting".
>
> Also guys, I believe we need to merge this change in short time because
> it's targeted for 2.0 and chances for a conflict are high.
>
>
>
> On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <pt...@apache.org>
> wrote:
>
> > Alexander,
> >
> > Please name the review appropriately and link it in the ticket as
> > described:
> > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > to+Contribute#HowtoContribute-ReviewWithUpsource
> >
> > Thanks,
> > Pavel
> >
> > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> > alexander.fedotoff@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Created Upsource review for the subject:
> > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> > >
> > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> > > alexander.fedotoff@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > I've completed working on IGNITE-3207
> > > > https://issues.apache.org/jira/browse/IGNITE-3207
> > > >
> > > > Looks like TC test results don't have problems related to my changes
> > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&
> > > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> > > >
> > > > Kindly take a look at PR https://github.com/apache/ignite/pull/1435/
> > > >
> > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <dm...@apache.org>
> > wrote:
> > > >
> > > >> Support Pavel’s point of view.
> > > >>
> > > >> Also Alexander please make sure that your changes are merged into
> > > >> ignite-2.0 branch rather than to the master. I think this
> > functionality
> > > >> has to be available in 2.0 first. Finally, please update 2.0
> Migration
> > > >> Guide once you’ve finished with this task:
> > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
> > > >> Ignite+2.0+Migration+Guide <https://cwiki.apache.org/conf
> > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> > > >>
> > > >> —
> > > >> Denis
> > > >>
> > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <ptupitsyn@apache.org
> >
> > > >> wrote:
> > > >> >
> > > >> > 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.
> > > >> >>
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > Kind regards,
> > > > Alexander.
> > > >
> > >
> > >
> > >
> > > --
> > > Kind regards,
> > > Alexander.
> > >
> >
>
>
>
> --
> Kind regards,
> Alexander.
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
Done. But it looks like something went wrong since Upsource reports:
"Review has too many files (1244), aborting".
Also guys, I believe we need to merge this change in short time because
it's targeted for 2.0 and chances for a conflict are high.
On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <pt...@apache.org>
wrote:
> Alexander,
>
> Please name the review appropriately and link it in the ticket as
> described:
> https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+Contribute#HowtoContribute-ReviewWithUpsource
>
> Thanks,
> Pavel
>
> On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
> alexander.fedotoff@gmail.com> wrote:
>
> > Hi,
> >
> > Created Upsource review for the subject:
> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
> >
> > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> > alexander.fedotoff@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I've completed working on IGNITE-3207
> > > https://issues.apache.org/jira/browse/IGNITE-3207
> > >
> > > Looks like TC test results don't have problems related to my changes
> > > http://ci.ignite.apache.org/viewLog.html?buildId=423955&
> > > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> > >
> > > Kindly take a look at PR https://github.com/apache/ignite/pull/1435/
> > >
> > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <dm...@apache.org>
> wrote:
> > >
> > >> Support Pavel’s point of view.
> > >>
> > >> Also Alexander please make sure that your changes are merged into
> > >> ignite-2.0 branch rather than to the master. I think this
> functionality
> > >> has to be available in 2.0 first. Finally, please update 2.0 Migration
> > >> Guide once you’ve finished with this task:
> > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
> > >> Ignite+2.0+Migration+Guide <https://cwiki.apache.org/conf
> > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> > >>
> > >> —
> > >> Denis
> > >>
> > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <pt...@apache.org>
> > >> wrote:
> > >> >
> > >> > 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.
> > >> >>
> > >>
> > >>
> > >
> > >
> > > --
> > > Kind regards,
> > > Alexander.
> > >
> >
> >
> >
> > --
> > Kind regards,
> > Alexander.
> >
>
--
Kind regards,
Alexander.
Re: IgniteConfiguration.gridName is very confusing
Posted by Pavel Tupitsyn <pt...@apache.org>.
Alexander,
Please name the review appropriately and link it in the ticket as described:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewWithUpsource
Thanks,
Pavel
On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
alexander.fedotoff@gmail.com> wrote:
> Hi,
>
> Created Upsource review for the subject:
> http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
>
> On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
> alexander.fedotoff@gmail.com> wrote:
>
> > Hi,
> >
> > I've completed working on IGNITE-3207
> > https://issues.apache.org/jira/browse/IGNITE-3207
> >
> > Looks like TC test results don't have problems related to my changes
> > http://ci.ignite.apache.org/viewLog.html?buildId=423955&
> > tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
> >
> > Kindly take a look at PR https://github.com/apache/ignite/pull/1435/
> >
> > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <dm...@apache.org> wrote:
> >
> >> Support Pavel’s point of view.
> >>
> >> Also Alexander please make sure that your changes are merged into
> >> ignite-2.0 branch rather than to the master. I think this functionality
> >> has to be available in 2.0 first. Finally, please update 2.0 Migration
> >> Guide once you’ve finished with this task:
> >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
> >> Ignite+2.0+Migration+Guide <https://cwiki.apache.org/conf
> >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
> >>
> >> —
> >> Denis
> >>
> >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <pt...@apache.org>
> >> wrote:
> >> >
> >> > 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 <dm...@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.
> >> >>
> >>
> >>
> >
> >
> > --
> > Kind regards,
> > Alexander.
> >
>
>
>
> --
> Kind regards,
> Alexander.
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
Hi,
Created Upsource review for the subject:
http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
alexander.fedotoff@gmail.com> wrote:
> Hi,
>
> I've completed working on IGNITE-3207
> https://issues.apache.org/jira/browse/IGNITE-3207
>
> Looks like TC test results don't have problems related to my changes
> http://ci.ignite.apache.org/viewLog.html?buildId=423955&
> tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
>
> Kindly take a look at PR https://github.com/apache/ignite/pull/1435/
>
> On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <dm...@apache.org> wrote:
>
>> Support Pavel’s point of view.
>>
>> Also Alexander please make sure that your changes are merged into
>> ignite-2.0 branch rather than to the master. I think this functionality
>> has to be available in 2.0 first. Finally, please update 2.0 Migration
>> Guide once you’ve finished with this task:
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
>> Ignite+2.0+Migration+Guide <https://cwiki.apache.org/conf
>> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
>>
>> —
>> Denis
>>
>> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <pt...@apache.org>
>> wrote:
>> >
>> > 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 <dm...@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 <dm...@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 <dm...@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.
>> >>
>>
>>
>
>
> --
> Kind regards,
> Alexander.
>
--
Kind regards,
Alexander.
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
Hi,
I've completed working on IGNITE-3207
https://issues.apache.org/jira/browse/IGNITE-3207
Looks like TC test results don't have problems related to my changes
http://ci.ignite.apache.org/viewLog.html?buildId=423955&tab=buildResultsDiv&buildTypeId=IgniteTests_RunAll
Kindly take a look at PR https://github.com/apache/ignite/pull/1435/
On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <dm...@apache.org> wrote:
> Support Pavel’s point of view.
>
> Also Alexander please make sure that your changes are merged into
> ignite-2.0 branch rather than to the master. I think this functionality
> has to be available in 2.0 first. Finally, please update 2.0 Migration
> Guide once you’ve finished with this task:
> https://cwiki.apache.org/confluence/display/IGNITE/
> Apache+Ignite+2.0+Migration+Guide <https://cwiki.apache.org/
> confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
>
> —
> Denis
>
> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <pt...@apache.org>
> wrote:
> >
> > 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 <dm...@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 <dm...@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 <dm...@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.
> >>
>
>
--
Kind regards,
Alexander.
Re: IgniteConfiguration.gridName is very confusing
Posted by Denis Magda <dm...@apache.org>.
Support Pavel’s point of view.
Also Alexander please make sure that your changes are merged into ignite-2.0 branch rather than to the master. I think this functionality has to be available in 2.0 first. Finally, please update 2.0 Migration Guide once you’ve finished with this task:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide <https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
—
Denis
> On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <pt...@apache.org> wrote:
>
> 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 <dm...@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 <dm...@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 <dm...@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.
>>
Re: IgniteConfiguration.gridName is very confusing
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <dm...@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 <dm...@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 <dm...@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.
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
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 <dm...@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 <dm...@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 <dm...@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 <dm...@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.
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
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 <dm...@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 <dm...@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 <dm...@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 <dm...@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?
> >> >>>
> >> >>>
> >> >
> >>
> >
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Dmitriy Setrakyan <ds...@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 <dm...@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 <dm...@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 <dm...@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 <dm...@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?
> >> >>>
> >> >>>
> >> >
> >>
> >
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Denis Magda <dm...@gridgain.com>.
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 <dm...@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" <dm...@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 <ds...@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 <dm...@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 <dm...@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?
>> >>>
>> >>>
>> >
>>
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Valentin Kulichenko <va...@gmail.com>.
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 <dm...@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" <dm...@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 <ds...@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 <dm...@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 <dm...@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?
> >>>
> >>>
> >
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Denis Magda <dm...@gridgain.com>.
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" <dm...@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 <ds...@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 <dm...@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 <ds...@apache.org>
>>> wrote:
>>>>
>>>> On Fri, Dec 30, 2016 at 1:12 PM, Denis Magda <dm...@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?
>>>
>>>
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Alexander Fedotov <al...@gmail.com>.
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" <dm...@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 <ds...@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 <dm...@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 <ds...@apache.org>
>> wrote:
>>>
>>> On Fri, Dec 30, 2016 at 1:12 PM, Denis Magda <dm...@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?
>>
>>
Re: IgniteConfiguration.gridName is very confusing
Posted by Denis Magda <dm...@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 <ds...@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 <dm...@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 <ds...@apache.org>
>> wrote:
>>>
>>> On Fri, Dec 30, 2016 at 1:12 PM, Denis Magda <dm...@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?
>>
>>
Re: IgniteConfiguration.gridName is very confusing
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Now I am confused. What is the purpose of this configuration parameter?
On Fri, Dec 30, 2016 at 1:15 PM, Denis Magda <dm...@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 <ds...@apache.org>
> wrote:
> >
> > On Fri, Dec 30, 2016 at 1:12 PM, Denis Magda <dm...@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?
>
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Denis Magda <dm...@apache.org>.
See Val’s concern in the discussion. I’m absolutely fine with ‘nodeName’.
—
Denis
> On Dec 30, 2016, at 1:13 PM, Dmitriy Setrakyan <ds...@apache.org> wrote:
>
> On Fri, Dec 30, 2016 at 1:12 PM, Denis Magda <dm...@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?
Re: IgniteConfiguration.gridName is very confusing
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Dec 30, 2016 at 1:12 PM, Denis Magda <dm...@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?
Re: IgniteConfiguration.gridName is very confusing
Posted by Denis Magda <dm...@apache.org>.
What’s about ‘localNodeName’?
—
Denis
> On Dec 30, 2016, at 1:11 PM, Denis Magda <dm...@apache.org> wrote:
>
>
>> On Dec 30, 2016, at 1:06 PM, Valentin Kulichenko <va...@gmail.com> wrote:
>>
>> 'nodeName' sounds like it has to be unique across nodes in topology, which
>> is wrong.
>
> If to follow your logic then for me neither ‘igniteInstanceName’ nor ‘igniteName’ makes it clear whether the name has to be unique or not cluster wide :) So I wouldn’t try to convey this characteristic in the new name.
>
> —
> Denis
Re: IgniteConfiguration.gridName is very confusing
Posted by Denis Magda <dm...@apache.org>.
> On Dec 30, 2016, at 1:06 PM, Valentin Kulichenko <va...@gmail.com> wrote:
>
> 'nodeName' sounds like it has to be unique across nodes in topology, which
> is wrong.
If to follow your logic then for me neither ‘igniteInstanceName’ nor ‘igniteName’ makes it clear whether the name has to be unique or not cluster wide :) So I wouldn’t try to convey this characteristic in the new name.
—
Denis
Re: IgniteConfiguration.gridName is very confusing
Posted by Valentin Kulichenko <va...@gmail.com>.
'nodeName' sounds like it has to be unique across nodes in topology, which
is wrong.
I don't think there is a perfect name for this, but 'igniteName' or
'igniteInstanceName' seem to be the best options for me.
-Val
On Fri, Dec 30, 2016 at 12:13 PM, Denis Magda <dm...@apache.org> wrote:
> To be honest both instanceName and igniteInstanceName sound confusing to
> me. I still need to go to the documentation to figure out what the hell
> “instance” is. Personally, if the property was called “nodeName” or
> “igniteNodeName” then I would’t need to refer to the docs because everyone
> knows what “node”, “cluster”, “grid” is.
>
> What are the main arguments against “nodeName”?
>
> —
> Denis
>
> > On Dec 30, 2016, at 11:58 AM, Yakov Zhdanov <yz...@gridgain.com>
> wrote:
> >
> > instanceName is confusing in, for example, SpringCacheManager and several
> > other places. See email from Alexander.
> >
> > Btw, gridName was OK for GridConfiguration:)
> >
> > --
> > Yakov Zhdanov
>
>
Re: IgniteConfiguration.gridName is very confusing
Posted by Denis Magda <dm...@apache.org>.
To be honest both instanceName and igniteInstanceName sound confusing to me. I still need to go to the documentation to figure out what the hell “instance” is. Personally, if the property was called “nodeName” or “igniteNodeName” then I would’t need to refer to the docs because everyone knows what “node”, “cluster”, “grid” is.
What are the main arguments against “nodeName”?
—
Denis
> On Dec 30, 2016, at 11:58 AM, Yakov Zhdanov <yz...@gridgain.com> wrote:
>
> instanceName is confusing in, for example, SpringCacheManager and several
> other places. See email from Alexander.
>
> Btw, gridName was OK for GridConfiguration:)
>
> --
> Yakov Zhdanov
Re: IgniteConfiguration.gridName is very confusing
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Dec 30, 2016 at 11:58 AM, Yakov Zhdanov <yz...@gridgain.com>
wrote:
> instanceName is confusing in, for example, SpringCacheManager and several
> other places. See email from Alexander.
>
Not sure why "instanceName" is confusing, but if it is, I would prefer
"nodeName" then.
Re: IgniteConfiguration.gridName is very confusing
Posted by Yakov Zhdanov <yz...@gridgain.com>.
instanceName is confusing in, for example, SpringCacheManager and several
other places. See email from Alexander.
Btw, gridName was OK for GridConfiguration:)
--
Yakov Zhdanov
Re: IgniteConfiguration.gridName is very confusing
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Dec 30, 2016 at 4:35 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> Alexander, your point makes sense to me. Please go on with
> 'igniteInstanceName' and let me review the PR so we can take the final
> decision.
>
How about just "instanceName"?
Re: IgniteConfiguration.gridName is very confusing
Posted by Yakov Zhdanov <yz...@apache.org>.
Alexander, your point makes sense to me. Please go on with
'igniteInstanceName' and let me review the PR so we can take the final
decision.
--Yakov