Re: Update the rebalance configuration documentation

[Artem Budnikov]

Hi Maxim,

Please create a documentation ticket as described here [1] or here [2].

Garrett, this improvement will be released in Ignite 2.8.


[1]: 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document#HowtoDocument-Basics 



[2]: 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Documentingaticket


-Artem

On 27.08.2019 22:05, Garrett Alley wrote:

Hello Maxim,

I'll take a look at this soon and make sure the documentation is up to date.

Also, you're always welcome to make suggested edits to the readme.io page.

Thanks!
===

Garrett Alley
Documentation
GridGain Systems


On Tue, Aug 27, 2019 at 10:38 AM Maxim Muzafarov  wrote:


Igniters,

I'm worrying about updating the Ignite documentation.

Can you advise who will or should update the Ignite documentation
rebalancing page [2] since the [1] issue has merged to the master
branch and some of the parameters have moved to the
IgniteConfiguration level?

I've marked this issue [1] as `Docs Required` but should I make some
changes at readme.io page?

[1] https://issues.apache.org/jira/browse/IGNITE-11821
[2] https://apacheignite.readme.io/docs/rebalancing

[jira] [Created] (IGNITE-12114) Missing information from JavaDoc - CacheConfiguration setGroupName

[Moti Nisenson-Ken (Jira)]

Moti Nisenson-Ken created IGNITE-12114:
--

 Summary: Missing information from JavaDoc - CacheConfiguration 
setGroupName
 Key: IGNITE-12114
 URL: https://issues.apache.org/jira/browse/IGNITE-12114
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.7.5, 2.7, 2.6, 2.5, 2.4
Reporter: Moti Nisenson-Ken


All caches in a group must have the same number of backups, otherwise an 
exception is thrown. CacheConfiguration#setGroupName doesn't document this.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Replacing default work dir from tmp to current dir

[Denis Magda]

Ok, seems like we came to a consensus. Let’s ensure that the path for our
work dir is user.dir/ignite/work and restart the vote.

Denis

On Tuesday, August 27, 2019, Ilya Kasnacheev 
wrote:

> Hello!
>
> I have took the liberty to implement the change to existing code base to
> remove concern about work/ directory:
>
> https://github.com/apache/ignite/pull/6816/files
>
> Some advocacy for this patch:
> - Minimal change.
> - Storing in user.dir/ignite/work (current directory, e.g. project root)
> which is consistent with behavior of unzipped binary release.
> - We can re-use user.dir/ignite for other uses in the future, such as
> storing logs there.
>
> I have to admit that my previous reaction to the change was too strong. It
> turned out the default was user.dir/work (project root) and not
> user.home/work (home dir with imminent Work collision).
> Nevertheless, I think that after this change it would be good enough to
> last for a few years.
>
> What do you think?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk  >:
>
> > In the current state of the project, we cannot directly compare Ignite
> > setup process to the one of postgresql or another database. In many
> Ignite
> > examples, an embedded node (even with persistence) is started and it is
> > supposed to run without any additional FS rights grants or init steps.
> This
> > may be changed in 3.0, but not in a maintenance release. If we are to
> > change the directory to /var/lib, I would rather fail Ignite node start
> > asking a user to explicitly provide work directory path. Let alone
> /var/lib
> > is not portable and I would not add an OS-switch to the code for no
> reason.
> >
> > I vote for storing the work in ~/ignite/work - agree with Ilya that
> writing
> > large amounts of data in a hidden folder is a bad idea.
> >
> > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov :
> >
> > > Hi Igniters,
> > >
> > > I agree that user home maybe not the best place from Linux perspective
> > and
> > > philosophy, but  "user.home"/ignite/work  is more or less portable.
> > >
> > > For the Linux environment, we can add a suggestion about where to place
> > > persisted data. For very first testing of Apache Ignite user home still
> > > looks good for me.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > вт, 27 авг. 2019 г. в 11:56, Pavel Pereslegin :
> > >
> > > > Or instead of a WARNING, we can add a suggestion with a
> recommendation
> > > > for the production environment.
> > > >
> > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov :
> > > > >
> > > > > /opt is either does not exist on fresh system, or has the same
> > > > restriction: no user access without admin intervention.
> > > > > /usr/local, /var/lib, etc. — all this is implemented in our DEB /
> RPM
> > > > packages already.
> > > > >
> > > > > For ZIP installation %HOME% seems to be the best approach for
> > "2-click"
> > > > launch.
> > > > > Later user can update preferences and set working dir to whatever
> > > > directory he would like.
> > > > >
> > > > > Also — we can put WARNING message to log noting that WORK_DIR is
> set
> > to
> > > > default.
> > > > >
> > > > > > On 27 Aug 2019, at 10:16, Zhenya Stanilovsky
> > > >  wrote:
> > > > > >
> > > > > >
> > > > > > And what about /opt/ignite ?
> > > > > >
> > > > > > copy-paste:
> > > > > > "
> > > > > > The basic difference is that  /usr/local  is for software not
> > managed
> > > > by the system packager, but still following the standard unix
> > deployment
> > > > rules.
> > > > > > That's why you have  /usr/local/bin ,  /usr/local/sbin
> > > >  /usr/local/include  etc...
> > > > > > /opt  on the other hand is for software that doesn't follow this
> > and
> > > > is deployed in a monolithic fashion. This usually includes commercial
> > > > and/or cross-platform software that is packaged in the "Windows"
> > style. "
> > > > > >
> > > > > >
> > > > > >> Понедельник, 26 августа 2019, 22:49 +03:00 от Denis Magda <
> > > > dma...@apache.org>:
> > > > > >>
> > > > > >> Igniters,
> > > > > >>
> > > > > >> I can't disagree with Nikolay that, as a database, Ignite needs
> to
> > > > persist
> > > > > >> changes to a folder different from "user.home" one. But with the
> > > > current
> > > > > >> rate of project growth and adoption, I would encourage us to
> > > > eliminate any
> > > > > >> possible obstacles a user might come across during the getting
> > > started
> > > > > >> phase with Ignite. Unfortunately, folders different from
> > "user.home"
> > > > imply
> > > > > >> a significant restriction - the user needs to allow access to
> > > folders
> > > > like
> > > > > >> /lib, /etc; which can make every getting started demo or app
> fail.
> > > > > >>
> > > > > >> Thus, today, I'm casting my vote for "user.home"/ignite/work
> > > > directory.
> > > > > >> Please don't forget about Windows and MacOS.
> > > > > >>
> > > > > >> -
> > > > > >> Denis
> > > > > >>
> > > > > >>
> > > > > >> On Mon, Aug 26, 20

Re: Update the rebalance configuration documentation

[Garrett Alley]

Hello Maxim,

I'll take a look at this soon and make sure the documentation is up to date.

Also, you're always welcome to make suggested edits to the readme.io page.

Thanks!
===

Garrett Alley
Documentation
GridGain Systems


On Tue, Aug 27, 2019 at 10:38 AM Maxim Muzafarov  wrote:

> Igniters,
>
> I'm worrying about updating the Ignite documentation.
>
> Can you advise who will or should update the Ignite documentation
> rebalancing page [2] since the [1] issue has merged to the master
> branch and some of the parameters have moved to the
> IgniteConfiguration level?
>
> I've marked this issue [1] as `Docs Required` but should I make some
> changes at readme.io page?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11821
> [2] https://apacheignite.readme.io/docs/rebalancing
>

Update the rebalance configuration documentation

[Maxim Muzafarov]

Igniters,

I'm worrying about updating the Ignite documentation.

Can you advise who will or should update the Ignite documentation
rebalancing page [2] since the [1] issue has merged to the master
branch and some of the parameters have moved to the
IgniteConfiguration level?

I've marked this issue [1] as `Docs Required` but should I make some
changes at readme.io page?

[1] https://issues.apache.org/jira/browse/IGNITE-11821
[2] https://apacheignite.readme.io/docs/rebalancing

Re: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[Dmitriy Pavlov]

Hi Igniters,



I've updated release process
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process,

now it requires to run  [4] Check RC: Licenses, compile, chksum
https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum

as step 4.4.3.


Also, I've changed this suite name & config. Now, TC always asks for
parameters like Ignite and JIRA version ( display='prompt' ).



Sincerely,

Dmitriy Pavlov


пн, 26 авг. 2019 г. в 14:20, Nikolay Izhikov :

> Thanks, Dmitriy.
>
> В Пн, 26/08/2019 в 14:18 +0300, Dmitriy Pavlov пишет:
> > Yes, AFAIK, no one tested it. Each TC build uses Java 8 and then some
> newer
> > random Java for running.
> >
> > Umbrella ticket:
> > https://issues.apache.org/jira/browse/IGNITE-11189
> >
> > пн, 26 авг. 2019 г. в 14:16, Nikolay Izhikov :
> >
> > > Hello, Dmitriy.
> > >
> > > We can't create Ignite distribution from sources on jdk9+.
> > > Is it true? Am I understand you correctly?
> > >
> > > Should we mention it in DEVNOTES.txt or README.txt?
> > > Do we have a ticket(umbrella ticket, IEP) to make it happen?
> > >
> > > В Пн, 26/08/2019 в 14:03 +0300, Dmitriy Pavlov пишет:
> > > > Hi Nikolay
> > > > > build on JDK8+
> > > >
> > > > Officially Ignite does not support build (compilation) under Java
> version
> > > > > 8. I could find a ticket if it is necessary.
> > > >
> > > > There are some changes which should help to bypass IgniteLinkTaglet
> > >
> > > issue,
> > > > but I couldn't call these changes completed. You can try to enable
> > >
> > > java-9+
> > > > maven profile.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > >
> > > > пн, 26 авг. 2019 г. в 10:43, Nikolay Izhikov :
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > I tried to build Ignite locally from sources on java 12 and got
> error.
> > > > > With java8 Ignite builts OK.
> > > > >
> > > > > Is it expected behavior?
> > > > >
> > > > >
> > > > > ```
> > > > > dragon:~/download/apache-ignite-2.7.6-src:[]$ mvn clean install
> > > > > -Pall-java,all-scala,licenses -DskipTests
> > > > > ...
> > > > > [ERROR] Failed to execute goal
> > > > > org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> > > > > (default-compile) on project ignite-tools: Compilation failure:
> > >
> > > Compilation
> > > > > failure:
> > > > > [ERROR]
> > > > >
> > >
> > >
> /home/dragon/download/apache-ignite-2.7.6-src/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[21,29]
> > > > > package com.sun.tools.doclets does not exist
> > > > > [ERROR]
> > > > >
> > >
> > >
> /home/dragon/download/apache-ignite-2.7.6-src/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[30,42]
> > > > > cannot find symbol
> > > > > [ERROR]   symbol: class Taglet
> > > > > [ERROR]
> > > > >
> > >
> > >
> /home/dragon/download/apache-ignite-2.7.6-src/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[37,5]
> > > > > method does not override or implement a method from a
> > > > > supertype
> > > > > [ERROR]
> > > > >
> > >
> > >
> /home/dragon/download/apache-ignite-2.7.6-src/modules/tools/src/main/java/org/apache/ignite/tools/javadoc/IgniteLinkTaglet.java:[44,5]
> > > > > method does not override or implement a met
> > > > >
> > > > > dragon:~/download/apache-ignite-2.7.6-src:[]$ java -version
> > > > > openjdk version "12.0.1" 2019-04-16
> > > > > OpenJDK Runtime Environment AdoptOpenJDK (build 12.0.1+12)
> > > > > OpenJDK 64-Bit Server VM AdoptOpenJDK (build 12.0.1+12, mixed mode,
> > > > > sharing)
> > > > >
> > > > > В Пт, 23/08/2019 в 18:12 +0300, Alexey Goncharuk пишет:
> > > > > > Who has created the task in the first place and can check why it
> > >
> > > fails? I
> > > > > > see no reason to fail the release unless somebody can reasonably
> > >
> > > explain
> > > > > > what exactly wrong with the provided source package.
> > > > > >
> > > > > > пт, 23 авг. 2019 г. в 17:51, Alexey Goncharuk <
> > > > >
> > > > > alexey.goncha...@gmail.com>:
> > > > > >
> > > > > > > I confirm that the release candidate can be successfully built
> > >
> > > locally,
> > > > > > > and it is also clear from the build log that the TC task tries
> to
> > > > >
> > > > > access a
> > > > > > > wrong repository.
> > > > > > >
> > > > > > > Who has access to the TC and can clean the .m2 cache?
> > > > > > >
> > > > > > > пт, 23 авг. 2019 г. в 16:27, Dmitriy Pavlov <
> dpav...@apache.org>:
> > > > > > >
> > > > > > > > I suppose the issue is in TC task or infra since I can
> clearly
> > >
> > > see
> > > > > > > > artifacts there
> > > > > > > >
> > > > > > > >
> > > > >
> > > > >
> > >
> > >
> https://mvnrepository.com/artifact/org.jacorb/jacorb-idl/2.2.3-jonas-patch-20071018
> > > > > > > >
> > > > > > > >
> > > > > > > > also, it may be the same issue with
> > > > > > > >
> > > > > > > >
> > > > >
> > > > >
> > >
> > >
> http://apache-ignite-users.70518.x6.nabble.com/Fail-to-compile-apache-ig

Re: Control.sh usability & possible bugs

[Alexey Goncharuk]

The ticket is created, the patch is attached:
https://issues.apache.org/jira/browse/IGNITE-12113

Also, I see some weird stuff going on in control.sh - I see no reason for
calling findAvailableJmxPort, restart file, interactive mode and restart
loop in the end. Looks like the script can be significantly simplified,
will create a separate ticket for this as well.

вт, 27 авг. 2019 г. в 19:06, Alexey Goncharuk :

> Got to the bottom of the issue with empty output and no JAVA_HOME.
>
> The reason is the following line in bin/control.sh:
>
> javaMajorVersion "${JAVA_HOME}/bin/java"
>
> Since JAVA_HOME is empty, the argument passed to the function is invalid
> and terminates the script. I suggest to replace the "${JAVA_HOME}/bin/java"
> with just "$JAVA" because it is already determined earlier in the scope.
> The suggested fix works in my environment for all options of JAVA_HOME. I
> will create a ticket for 2.7.6 scope if there are no objections.
>
> Petr, do you have any idea how we can change the script to not fail
> silently and print at least some hint if it terminates early?
>
> вт, 27 авг. 2019 г. в 18:27, Sergey Antonov :
>
>> Hi everyone!
>>
>> Issue 3 fixed in master.
>> In master control.sh now is:
>> *> control.sh --help*
>>
>> Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
>> 2019 Copyright(C) Apache Software Foundation
>> User: santonov
>> Time: 2019-08-27T18:22:45.023
>> Control utility script is used to execute admin commands on cluster or get
>> common cluster info. The command has the following syntax:
>>
>>   control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
>> [--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
>> PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
>> SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
>> SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
>> KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
>> KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
>> TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] [command]
>> 
>>
>>
>> This utility can do the following commands:
>>   Activate cluster:
>> control.(sh|bat) --activate
>>
>>   Deactivate cluster:
>> control.(sh|bat) --deactivate [--yes]
>>
>>   Print current cluster state:
>> control.(sh|bat) --state
>>
>>   Print cluster baseline topology:
>> control.(sh|bat) --baseline
>>
>>   Add nodes into baseline topology:
>> control.(sh|bat) --baseline add
>> consistentId1[,consistentId2,,consistentIdN] [--yes]
>>
>>   Remove nodes from baseline topology:
>> control.(sh|bat) --baseline remove
>> consistentId1[,consistentId2,,consistentIdN] [--yes]
>>
>>   Set baseline topology:
>> control.(sh|bat) --baseline set
>> consistentId1[,consistentId2,,consistentIdN] [--yes]
>>
>>   Set baseline topology based on version:
>> control.(sh|bat) --baseline version topologyVersion [--yes]
>>
>>   Set baseline autoadjustment settings:
>> control.(sh|bat) --baseline auto_adjust [disable|enable] [timeout
>> ] [--yes]
>>
>>   List or kill transactions:
>> control.(sh|bat) --tx [--xid XID] [--min-duration SECONDS] [--min-size
>> SIZE] [--label PATTERN_REGEX] [--servers|--clients] [--nodes
>> consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER]
>> [--order
>> DURATION|SIZE|START_TIME] [--kill] [--info] [--yes]
>>
>>   Print detailed information (topology and key lock ownership) about
>> specific transaction:
>> control.(sh|bat) --tx --info > [topVer=..., order=..., nodeOrder=...] (can be found in logs)>|> identifier as UUID (can be retrieved via --tx command)>
>>
>>   View caches information in a cluster. For more details type:
>> control.(sh|bat) --cache help
>>
>>   Print absolute paths of unused archived wal segments on each node:
>> control.(sh|bat) --wal print
>> [consistentId1,consistentId2,,consistentIdN]
>>
>>   Delete unused archived wal segments on each node:
>> control.(sh|bat) --wal delete
>> [consistentId1,consistentId2,,consistentIdN] [--yes]
>>
>>   View diagnostic information in a cluster. For more details type:
>> control.(sh|bat) --diagnostic
>>
>>   Enable read-only mode on active cluster:
>> control.(sh|bat) --read-only-on [--yes]
>>
>>   Disable read-only mode on active cluster:
>>  

[jira] [Created] (IGNITE-12113) control.sh terminates silently when JAVA_HOME is not set

[Alexey Goncharuk (Jira)]

Alexey Goncharuk created IGNITE-12113:
-

 Summary: control.sh terminates silently when JAVA_HOME is not set
 Key: IGNITE-12113
 URL: https://issues.apache.org/jira/browse/IGNITE-12113
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk


Running control.sh from ignite-2.7.6 release candidate on MacOS with empty 
JAVA_HOME produces no output - the script terminates without any action.

The reason is the following line in {{bin/control.sh}}:

{code}
javaMajorVersion "${JAVA_HOME}/bin/java"
{code}

Since {{JAVA_HOME}} is empty, the argument passed to the function is invalid 
and the function terminates the script. I suggest replacing the 
{{${JAVA_HOME}/bin/java}} with just {{$JAVA}} because it is already determined 
earlier in the scope. The suggested fix works in my environment for all options 
of {{JAVA_HOME}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Developer team membership

[Dmitriy Pavlov]

Hi Ilya, Diana,

I've added permissions, please double-check.
Ilya, I've added your account to Administrators group, so now you could add
contributors in JIRA.

Diana, I found ASF JIRA user Diana Iakovleva (Diana) and added this user to
the contributors' group.  Now you should be able to assign an issue to
yourself.

Please let us know here if you have any questions. As a starting point, you
can read short guide on how to contribute
https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#contributing-to-apache-ignite


Welcome to the Apache Ignite Community.

Sincerely,
Dmitriy Pavlov

вт, 27 авг. 2019 г. в 17:16, Ilya Kasnacheev :

> Hello, Diana!
>
> Do you have jira username registered on https://issues.apache.org/jira/
>
> You need such an account to be assigned tickets. Please share your username
> as soon as you have one.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 27 авг. 2019 г. в 16:45, Диана Яковлева :
>
> > Hi,
> >
> > I'd like to contribute to Ignite project, so can you please give to user
> > Diana necessary rights to be able to work on tickets?
> >
> > Full name: Diana Iakovleva
> >
> >
> > Thanks,
> >
> > Diana
> >
>

Re: Control.sh usability & possible bugs

[Alexey Goncharuk]

Got to the bottom of the issue with empty output and no JAVA_HOME.

The reason is the following line in bin/control.sh:

javaMajorVersion "${JAVA_HOME}/bin/java"

Since JAVA_HOME is empty, the argument passed to the function is invalid
and terminates the script. I suggest to replace the "${JAVA_HOME}/bin/java"
with just "$JAVA" because it is already determined earlier in the scope.
The suggested fix works in my environment for all options of JAVA_HOME. I
will create a ticket for 2.7.6 scope if there are no objections.

Petr, do you have any idea how we can change the script to not fail
silently and print at least some hint if it terminates early?

вт, 27 авг. 2019 г. в 18:27, Sergey Antonov :

> Hi everyone!
>
> Issue 3 fixed in master.
> In master control.sh now is:
> *> control.sh --help*
>
> Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
> 2019 Copyright(C) Apache Software Foundation
> User: santonov
> Time: 2019-08-27T18:22:45.023
> Control utility script is used to execute admin commands on cluster or get
> common cluster info. The command has the following syntax:
>
>   control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
> [--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
> PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
> SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
> SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
> KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
> KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
> TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] [command]
> 
>
>
> This utility can do the following commands:
>   Activate cluster:
> control.(sh|bat) --activate
>
>   Deactivate cluster:
> control.(sh|bat) --deactivate [--yes]
>
>   Print current cluster state:
> control.(sh|bat) --state
>
>   Print cluster baseline topology:
> control.(sh|bat) --baseline
>
>   Add nodes into baseline topology:
> control.(sh|bat) --baseline add
> consistentId1[,consistentId2,,consistentIdN] [--yes]
>
>   Remove nodes from baseline topology:
> control.(sh|bat) --baseline remove
> consistentId1[,consistentId2,,consistentIdN] [--yes]
>
>   Set baseline topology:
> control.(sh|bat) --baseline set
> consistentId1[,consistentId2,,consistentIdN] [--yes]
>
>   Set baseline topology based on version:
> control.(sh|bat) --baseline version topologyVersion [--yes]
>
>   Set baseline autoadjustment settings:
> control.(sh|bat) --baseline auto_adjust [disable|enable] [timeout
> ] [--yes]
>
>   List or kill transactions:
> control.(sh|bat) --tx [--xid XID] [--min-duration SECONDS] [--min-size
> SIZE] [--label PATTERN_REGEX] [--servers|--clients] [--nodes
> consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER] [--order
> DURATION|SIZE|START_TIME] [--kill] [--info] [--yes]
>
>   Print detailed information (topology and key lock ownership) about
> specific transaction:
> control.(sh|bat) --tx --info  [topVer=..., order=..., nodeOrder=...] (can be found in logs)>| identifier as UUID (can be retrieved via --tx command)>
>
>   View caches information in a cluster. For more details type:
> control.(sh|bat) --cache help
>
>   Print absolute paths of unused archived wal segments on each node:
> control.(sh|bat) --wal print
> [consistentId1,consistentId2,,consistentIdN]
>
>   Delete unused archived wal segments on each node:
> control.(sh|bat) --wal delete
> [consistentId1,consistentId2,,consistentIdN] [--yes]
>
>   View diagnostic information in a cluster. For more details type:
> control.(sh|bat) --diagnostic
>
>   Enable read-only mode on active cluster:
> control.(sh|bat) --read-only-on [--yes]
>
>   Disable read-only mode on active cluster:
> control.(sh|bat) --read-only-off [--yes]
>
> By default commands affecting the cluster require interactive confirmation.
> Use --yes option to disable it.
>
> Default values:
> HOST_OR_IP=127.0.0.1
> PORT=11211
> PING_INTERVAL=5000
> PING_TIMEOUT=3
> SSL_PROTOCOL=TLS
> SSL_KEY_ALGORITHM=SunX509
> KEYSTORE_TYPE=JKS
> TRUSTSTORE_TYPE=JKS
>
> Exit codes:
> 0 - successful execution.
> 1 - invalid arguments.
> 2 - connection failed.
> 3 - authentication failed.
> 4 - unexpected error.
> Control utility has completed execution at: 2019-08-27T18:22:45.193
> Execution time: 170 ms
>
> *> control.sh --cache help*
>
> Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
> 2019 Copyright(C) Apache Software F

Re: Log level changes in GridCacheWriteBehindStore.updateStore

[Ilya Kasnacheev]

Hello!

I think you should go ahead and create a JIRA ticket about it, then someone
(or even you) can check it and fix it.

Regards,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 09:17, Sunny Chan, CLSA :

> Hello,
>
>
>
> In the GridCacheWriteBehindStore
> ,
> when the updateStore failed to write to underlying store, it logs this as
> error:
>
>
>
> LT.error(log, e, "Unable to update underlying store: " + store);
>
>
>
> After this line logged the error, it would return false so that it would
> retry the store (by returning false).
>
>
>
> While later on in the updatStore function, when the writeCache overflows,
> it would log this:
>
>
>
> log.warning("Failed to update store (value will be lost as current buffer
> size is greater " + …
>
>
>
> then it will remove the failed entry.
>
>
>
> I think the severity of the log messages is not right, as the fail update
> would still be retried.
>
>
>
> So I propose to change the log severity level so that the first one would
> be a warn, and second one would be error. Is that acceptable?
>
>
>
> *Sunny Chan*
>
> *Senior Lead Engineer, Executive Services*
>
> D  +852 2600 8907  |  M  +852 6386 1835  |  T  +852 2600 
>
> 5/F, One Island East, 18 Westlands Road, Island East, Hong Kong
>
>
>
> [image: :1. Social Media Icons:CLSA_Social Media Icons_linkedin.png]
> [image: :1. Social Media
> Icons:CLSA_Social Media Icons_twitter.png]
> [image: :1. Social Media
> Icons:CLSA_Social Media Icons_youtube.png]
> [image: :1.
> Social Media Icons:CLSA_Social Media Icons_facebook.png]
> 
>
>
>
> *clsa.com* 
>
> *Insights. Liquidity. Capital. *
>
>
>
> [image: CLSA_RGB] 
>
>
>
> *A CITIC Securities Company*
>
>
>
> The content of this communication is intended for the recipient and is
> subject to CLSA Legal and Regulatory Notices.
> These can be viewed at https://www.clsa.com/disclaimer.html or sent to
> you upon request.
> Please consider before printing. CLSA is ISO14001 certified and committed
> to reducing its impact on the environment.
>

Re: Replacing default work dir from tmp to current dir

[Ilya Kasnacheev]

Hello!

I have took the liberty to implement the change to existing code base to
remove concern about work/ directory:

https://github.com/apache/ignite/pull/6816/files

Some advocacy for this patch:
- Minimal change.
- Storing in user.dir/ignite/work (current directory, e.g. project root)
which is consistent with behavior of unzipped binary release.
- We can re-use user.dir/ignite for other uses in the future, such as
storing logs there.

I have to admit that my previous reaction to the change was too strong. It
turned out the default was user.dir/work (project root) and not
user.home/work (home dir with imminent Work collision).
Nevertheless, I think that after this change it would be good enough to
last for a few years.

What do you think?

Regards,
-- 
Ilya Kasnacheev


вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk :

> In the current state of the project, we cannot directly compare Ignite
> setup process to the one of postgresql or another database. In many Ignite
> examples, an embedded node (even with persistence) is started and it is
> supposed to run without any additional FS rights grants or init steps. This
> may be changed in 3.0, but not in a maintenance release. If we are to
> change the directory to /var/lib, I would rather fail Ignite node start
> asking a user to explicitly provide work directory path. Let alone /var/lib
> is not portable and I would not add an OS-switch to the code for no reason.
>
> I vote for storing the work in ~/ignite/work - agree with Ilya that writing
> large amounts of data in a hidden folder is a bad idea.
>
> вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov :
>
> > Hi Igniters,
> >
> > I agree that user home maybe not the best place from Linux perspective
> and
> > philosophy, but  "user.home"/ignite/work  is more or less portable.
> >
> > For the Linux environment, we can add a suggestion about where to place
> > persisted data. For very first testing of Apache Ignite user home still
> > looks good for me.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вт, 27 авг. 2019 г. в 11:56, Pavel Pereslegin :
> >
> > > Or instead of a WARNING, we can add a suggestion with a recommendation
> > > for the production environment.
> > >
> > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov :
> > > >
> > > > /opt is either does not exist on fresh system, or has the same
> > > restriction: no user access without admin intervention.
> > > > /usr/local, /var/lib, etc. — all this is implemented in our DEB / RPM
> > > packages already.
> > > >
> > > > For ZIP installation %HOME% seems to be the best approach for
> "2-click"
> > > launch.
> > > > Later user can update preferences and set working dir to whatever
> > > directory he would like.
> > > >
> > > > Also — we can put WARNING message to log noting that WORK_DIR is set
> to
> > > default.
> > > >
> > > > > On 27 Aug 2019, at 10:16, Zhenya Stanilovsky
> > >  wrote:
> > > > >
> > > > >
> > > > > And what about /opt/ignite ?
> > > > >
> > > > > copy-paste:
> > > > > "
> > > > > The basic difference is that  /usr/local  is for software not
> managed
> > > by the system packager, but still following the standard unix
> deployment
> > > rules.
> > > > > That's why you have  /usr/local/bin ,  /usr/local/sbin
> > >  /usr/local/include  etc...
> > > > > /opt  on the other hand is for software that doesn't follow this
> and
> > > is deployed in a monolithic fashion. This usually includes commercial
> > > and/or cross-platform software that is packaged in the "Windows"
> style. "
> > > > >
> > > > >
> > > > >> Понедельник, 26 августа 2019, 22:49 +03:00 от Denis Magda <
> > > dma...@apache.org>:
> > > > >>
> > > > >> Igniters,
> > > > >>
> > > > >> I can't disagree with Nikolay that, as a database, Ignite needs to
> > > persist
> > > > >> changes to a folder different from "user.home" one. But with the
> > > current
> > > > >> rate of project growth and adoption, I would encourage us to
> > > eliminate any
> > > > >> possible obstacles a user might come across during the getting
> > started
> > > > >> phase with Ignite. Unfortunately, folders different from
> "user.home"
> > > imply
> > > > >> a significant restriction - the user needs to allow access to
> > folders
> > > like
> > > > >> /lib, /etc; which can make every getting started demo or app fail.
> > > > >>
> > > > >> Thus, today, I'm casting my vote for "user.home"/ignite/work
> > > directory.
> > > > >> Please don't forget about Windows and MacOS.
> > > > >>
> > > > >> -
> > > > >> Denis
> > > > >>
> > > > >>
> > > > >> On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn <
> > ptupit...@apache.org
> > > > wrote:
> > > > >>
> > > > >>> +1 for  ~/.ignite/work
> > > > >>>
> > > > >>> As Petr mentioned above, this translates well to Windows and
> MacOS
> > > too, we
> > > > >>> can use "home directory" term in documentation and it works for
> any
> > > OS.
> > > > >>>
> > > > >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov <
> > > nizhi...@apache.org >
> > > > >>> wrote:
> > > > >>>
> > > >  A

[jira] [Created] (IGNITE-12112) H2TreeIndex should throw CorruptTreeException with cacheId, cacheName and indexName

[Denis Chudov (Jira)]

Denis Chudov created IGNITE-12112:
-

 Summary: H2TreeIndex should throw CorruptTreeException with 
cacheId, cacheName and indexName
 Key: IGNITE-12112
 URL: https://issues.apache.org/jira/browse/IGNITE-12112
 Project: Ignite
  Issue Type: Improvement
Reporter: Denis Chudov
Assignee: Denis Chudov


At the moment we can't define problem cache, If we have many caches in one 
cache group and CorruptTreeException was thrown CorruptTreeException. 
For example:
{code:java}
org.h2.message.DbException: General error: "class 
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
 Runtime failure on row: Row@346ba4aa[ key: 29003, val: 
com.sbt.acquiring.processing.entities.dictionaries.TurnoverRange_DPL_PROXY 
[idHash=492721050, hash=-616731792, valueStart=2001, isImmutable=false, 
lastChangeDate=1560917668719, name=Ñâûøå 20, valueEnd=null, 
changeState=null, id=29003, pkey=7c0d0d59-f33e-41d7-a5c9-4d8c7e74b976, 
ownerId=acquiring-processing-replication, base=true], ver: GridCacheVersion 
[topVer=172396060, order=1560917613306, nodeOrder=2] ][ Ñâûøå 20, null, 
2001, TRUE, null, 29003, 7c0d0d59-f33e-41d7-a5c9-4d8c7e74b976 ]" [5-195]
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:251)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:548)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:480)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:709)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1863)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1402)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1263)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1625)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:358)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3629)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2793)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:902)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:772)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:344)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:418)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:408)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1061)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:586)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1624)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.Th

Re: Replacing default work dir from tmp to current dir

[Alexey Goncharuk]

In the current state of the project, we cannot directly compare Ignite
setup process to the one of postgresql or another database. In many Ignite
examples, an embedded node (even with persistence) is started and it is
supposed to run without any additional FS rights grants or init steps. This
may be changed in 3.0, but not in a maintenance release. If we are to
change the directory to /var/lib, I would rather fail Ignite node start
asking a user to explicitly provide work directory path. Let alone /var/lib
is not portable and I would not add an OS-switch to the code for no reason.

I vote for storing the work in ~/ignite/work - agree with Ilya that writing
large amounts of data in a hidden folder is a bad idea.

вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov :

> Hi Igniters,
>
> I agree that user home maybe not the best place from Linux perspective and
> philosophy, but  "user.home"/ignite/work  is more or less portable.
>
> For the Linux environment, we can add a suggestion about where to place
> persisted data. For very first testing of Apache Ignite user home still
> looks good for me.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 27 авг. 2019 г. в 11:56, Pavel Pereslegin :
>
> > Or instead of a WARNING, we can add a suggestion with a recommendation
> > for the production environment.
> >
> > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov :
> > >
> > > /opt is either does not exist on fresh system, or has the same
> > restriction: no user access without admin intervention.
> > > /usr/local, /var/lib, etc. — all this is implemented in our DEB / RPM
> > packages already.
> > >
> > > For ZIP installation %HOME% seems to be the best approach for "2-click"
> > launch.
> > > Later user can update preferences and set working dir to whatever
> > directory he would like.
> > >
> > > Also — we can put WARNING message to log noting that WORK_DIR is set to
> > default.
> > >
> > > > On 27 Aug 2019, at 10:16, Zhenya Stanilovsky
> >  wrote:
> > > >
> > > >
> > > > And what about /opt/ignite ?
> > > >
> > > > copy-paste:
> > > > "
> > > > The basic difference is that  /usr/local  is for software not managed
> > by the system packager, but still following the standard unix deployment
> > rules.
> > > > That's why you have  /usr/local/bin ,  /usr/local/sbin
> >  /usr/local/include  etc...
> > > > /opt  on the other hand is for software that doesn't follow this and
> > is deployed in a monolithic fashion. This usually includes commercial
> > and/or cross-platform software that is packaged in the "Windows" style. "
> > > >
> > > >
> > > >> Понедельник, 26 августа 2019, 22:49 +03:00 от Denis Magda <
> > dma...@apache.org>:
> > > >>
> > > >> Igniters,
> > > >>
> > > >> I can't disagree with Nikolay that, as a database, Ignite needs to
> > persist
> > > >> changes to a folder different from "user.home" one. But with the
> > current
> > > >> rate of project growth and adoption, I would encourage us to
> > eliminate any
> > > >> possible obstacles a user might come across during the getting
> started
> > > >> phase with Ignite. Unfortunately, folders different from "user.home"
> > imply
> > > >> a significant restriction - the user needs to allow access to
> folders
> > like
> > > >> /lib, /etc; which can make every getting started demo or app fail.
> > > >>
> > > >> Thus, today, I'm casting my vote for "user.home"/ignite/work
> > directory.
> > > >> Please don't forget about Windows and MacOS.
> > > >>
> > > >> -
> > > >> Denis
> > > >>
> > > >>
> > > >> On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn <
> ptupit...@apache.org
> > > wrote:
> > > >>
> > > >>> +1 for  ~/.ignite/work
> > > >>>
> > > >>> As Petr mentioned above, this translates well to Windows and MacOS
> > too, we
> > > >>> can use "home directory" term in documentation and it works for any
> > OS.
> > > >>>
> > > >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov <
> > nizhi...@apache.org >
> > > >>> wrote:
> > > >>>
> > >  AFAIK server admin expects software will store it's data in /var/
> > >  directory, not in /home directory.
> > > 
> > > > In Docker age, packages are becoming extinct.
> > > 
> > >  I don't agree with that, but seems, it's not a subject of
> > discussion. :)
> > > 
> > > > we don't even have very good packages today
> > > 
> > >  Why do you think we don't have good packages?
> > >  What is wrong with the current one?
> > > 
> > > > I also think we should not copy what other DBMS do since their
> > >  ease-of-use
> > > > is usually lacking
> > > 
> > >  We should define 'easy-of-use' here.
> > >  My experience with the modern dbms(postgres and mysql) is
> different.
> > > 
> > > 
> > >  В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет:
> > > > Hello!
> > > >
> > > > I think it is 2., because if a node is run from Ignite binary
> > >  distribution
> > > > it has its root as a ignite work directory. I think it it another
> > >  argument
> > > 

Re: Control.sh usability & possible bugs

[Sergey Antonov]

Hi everyone!

Issue 3 fixed in master.
In master control.sh now is:
*> control.sh --help*

Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
2019 Copyright(C) Apache Software Foundation
User: santonov
Time: 2019-08-27T18:22:45.023
Control utility script is used to execute admin commands on cluster or get
common cluster info. The command has the following syntax:

  control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
[--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] [command]



This utility can do the following commands:
  Activate cluster:
control.(sh|bat) --activate

  Deactivate cluster:
control.(sh|bat) --deactivate [--yes]

  Print current cluster state:
control.(sh|bat) --state

  Print cluster baseline topology:
control.(sh|bat) --baseline

  Add nodes into baseline topology:
control.(sh|bat) --baseline add
consistentId1[,consistentId2,,consistentIdN] [--yes]

  Remove nodes from baseline topology:
control.(sh|bat) --baseline remove
consistentId1[,consistentId2,,consistentIdN] [--yes]

  Set baseline topology:
control.(sh|bat) --baseline set
consistentId1[,consistentId2,,consistentIdN] [--yes]

  Set baseline topology based on version:
control.(sh|bat) --baseline version topologyVersion [--yes]

  Set baseline autoadjustment settings:
control.(sh|bat) --baseline auto_adjust [disable|enable] [timeout
] [--yes]

  List or kill transactions:
control.(sh|bat) --tx [--xid XID] [--min-duration SECONDS] [--min-size
SIZE] [--label PATTERN_REGEX] [--servers|--clients] [--nodes
consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER] [--order
DURATION|SIZE|START_TIME] [--kill] [--info] [--yes]

  Print detailed information (topology and key lock ownership) about
specific transaction:
control.(sh|bat) --tx --info |

  View caches information in a cluster. For more details type:
control.(sh|bat) --cache help

  Print absolute paths of unused archived wal segments on each node:
control.(sh|bat) --wal print
[consistentId1,consistentId2,,consistentIdN]

  Delete unused archived wal segments on each node:
control.(sh|bat) --wal delete
[consistentId1,consistentId2,,consistentIdN] [--yes]

  View diagnostic information in a cluster. For more details type:
control.(sh|bat) --diagnostic

  Enable read-only mode on active cluster:
control.(sh|bat) --read-only-on [--yes]

  Disable read-only mode on active cluster:
control.(sh|bat) --read-only-off [--yes]

By default commands affecting the cluster require interactive confirmation.
Use --yes option to disable it.

Default values:
HOST_OR_IP=127.0.0.1
PORT=11211
PING_INTERVAL=5000
PING_TIMEOUT=3
SSL_PROTOCOL=TLS
SSL_KEY_ALGORITHM=SunX509
KEYSTORE_TYPE=JKS
TRUSTSTORE_TYPE=JKS

Exit codes:
0 - successful execution.
1 - invalid arguments.
2 - connection failed.
3 - authentication failed.
4 - unexpected error.
Control utility has completed execution at: 2019-08-27T18:22:45.193
Execution time: 170 ms

*> control.sh --cache help*

Control utility [ver. 2.8.0-SNAPSHOT#20190827-sha1:DEV]
2019 Copyright(C) Apache Software Foundation
User: santonov
Time: 2019-08-27T18:25:01.577
Command [CACHE] started
Arguments: --cache help --yes

  The '--cache subcommand' is used to get information about and perform
actions with caches. The command has the following syntax:

  control.(sh|bat) [--host HOST_OR_IP] [--port PORT] [--user USER]
[--password PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
PING_TIMEOUT] [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ...,
SSL_PROTOCOL_N]] [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ...,
SSL_CIPHER_N]] [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type
KEYSTORE_TYPE] [--keystore KEYSTORE_PATH] [--keystore-password
KEYSTORE_PASSWORD] [--truststore-type TRUSTSTORE_TYPE] [--truststore
TRUSTSTORE_PATH] [--truststore-password TRUSTSTORE_PASSWORD] --cache
[subcommand] 

  The subcommands that take [nodeId] as an argument ('list',
'find_garbage', 'contention' and 'validate_indexes') will be executed on
the given node or on all server nodes if the option is not specified. Other
commands will run on a random server node.


  Subcommands:

  --cache idle_verify [--dump] [--skip-zeros] [--check-crc]
[--exclude-caches cacheName1,...,cacheNameN] [--cache-filter
DEFAULT|SYSTEM|PERSISTENT|NOT_PERSISTENT|USER|ALL]
[cacheName1,...,

Re: Control.sh usability & possible bugs

[Alexey Goncharuk]

Dmitriy,

I confirm the first issue but did not get to the bottom of it yet; will
keep you posted.

вт, 27 авг. 2019 г. в 17:34, Dmitriy Pavlov :

> Hi Artem, thank you for your reply.
>
> Since this change is on its way, let's wait for 2.8.
>
>
> Petr Ivanov, Alexey Goncharuck, Ivan Rakov, could you please step in and
> provide your feedback related to Issue 1 & 2?
>
>
>
>
>
> вт, 27 авг. 2019 г. в 17:30, Artem Budnikov :
>
> > Hi everyone,
> >
> > Re Issue 3:
> >
> > That's a good idea, but as far as I remember this was done in
> > https://jira.apache.org/jira/browse/IGNITE-10279 and is waiting to be
> > released in Ignite 2.8.
> >
> > -Artem
> >
> > On 26.08.2019 15:18, Anton Kalashnikov wrote:
> > > Hello, Igniters.
> > >
> > > +1 for Script help usability - issue 3
> > >
> > > Looks like it will be great if we avoid the repeated output of the
> > commands, ex.:
> > >
> > > control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
> > PASSWORD]  [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
> > [] [--yes]
> > >
> > > Allowable :
> > > --activate - ...
> > > --deactivate - ...
> > > ...
> > >
> > > --
> > > Best regards,
> > > Anton Kalashnikov
> > >
> > >
> > > 26.08.2019, 15:00, "Dmitriy Pavlov" :
> > >> Hi Igniters,
> > >>
> > >> During voting on 2.7.6-rc1, I saw how experienced Ignite contributor
> > >> committer and PMC member were trying to activate cluster using
> > control.sh
> > >> command.
> > >>
> > >> We usually just call cluster().active(true), but end users have to use
> > the
> > >> script provided in the distribution.
> > >>
> > >> Related to control.sh there are 3 concerns:
> > >>
> > >> Issue 1: On Mac OS if there is an empty (unset) JAVA_HOME variable,
> > script
> > >> outputs noting and probably does not execute its comment.
> > >>
> > >> Petr Ivanov, Alexey Goncharuck, could you please double-check if it
> > could
> > >> be fixed?
> > >>
> > >> Issue 2: Control.sh was not able to connect to cluster (local). AFAIK
> > >> multicast is still our defaults. so it should be possible to connect
> to
> > >> cluster without any options.
> > >>
> > >> Ivan Rakov, could you please chime in? Is it a local issue or bug?
> > >>
> > >> Issue 3: Script help usability
> > >>
> > >> Example of output:
> > >>
> > >>   Activate cluster:
> > >>
> > >>  control.sh [--host HOST_OR_IP] [--port PORT] [--user USER]
> > [--password
> > >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
> PING_TIMEOUT]
> > >> --activate
> > >>
> > >>Deactivate cluster:
> > >>
> > >>  control.sh [--host HOST_OR_IP] [--port PORT] [--user USER]
> > [--password
> > >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout
> PING_TIMEOUT]
> > >> --deactivate [--yes]
> > >>
> > >>   ...
> > >>
> > >> Why do we repeat tons of parameters each time? Is it better for users
> to
> > >> enlist options and commands separately?
> > >>
> > >>   control.sh [options] command
> > >>
> > >> and then enlist options
> > >>
> > >> [--host HOST_OR_IP]
> > >>
> > >> [--port PORT]
> > >>
> > >> [--user USER]
> > >>
> > >> [--password PASSWORD]
> > >>
> > >> [--ping-interval PING_INTERVAL]
> > >>
> > >> [--ping-timeout PING_TIMEOUT]
> > >>
> > >> and describe several commands we have?
> > >>
> > >> In coding WET is not the best solution. So maybe we could DRY in our
> > help,
> > >> should we?
> > >>
> > >> Artem Boudnikov, could you evaluate this idea?
> > >>
> > >> Sincerely,
> > >> Dmitriy Pavlov
> >
>

[jira] [Created] (IGNITE-12111) Cluster ID and tag: properties to identify the cluster

[Sergey Chugunov (Jira)]

Sergey Chugunov created IGNITE-12111:


 Summary: Cluster ID and tag: properties to identify the cluster
 Key: IGNITE-12111
 URL: https://issues.apache.org/jira/browse/IGNITE-12111
 Project: Ignite
  Issue Type: New Feature
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov
 Fix For: 2.8


To improve cluster management capabilities two new properties of the cluster 
are introduced:

# A unique cluster ID (may be either a random UUID or random IgniteUUID). 
Generated upon cluster start and saved to the distributed metastorage. 
Immutable. Persistent clusters must persist the value. In-memory clusters 
should keep the generated ID in memory and regenerate it upon restart.
# Human-readable cluster tag. Generated by default to some random (but still 
meaningful) string, may be changed by user. Again survives restart in 
persistent clusters and is regenerated in in-memory clusters on every restart.

These properties are exposed to standard APIs:
# EVT_CLUSTER_TAG_CHANGED event generated when tag is changed by user;
# JMX bean and control utility APIs to view ID and tag and change tag.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Control.sh usability & possible bugs

[Dmitriy Pavlov]

Hi Artem, thank you for your reply.

Since this change is on its way, let's wait for 2.8.


Petr Ivanov, Alexey Goncharuck, Ivan Rakov, could you please step in and
provide your feedback related to Issue 1 & 2?





вт, 27 авг. 2019 г. в 17:30, Artem Budnikov :

> Hi everyone,
>
> Re Issue 3:
>
> That's a good idea, but as far as I remember this was done in
> https://jira.apache.org/jira/browse/IGNITE-10279 and is waiting to be
> released in Ignite 2.8.
>
> -Artem
>
> On 26.08.2019 15:18, Anton Kalashnikov wrote:
> > Hello, Igniters.
> >
> > +1 for Script help usability - issue 3
> >
> > Looks like it will be great if we avoid the repeated output of the
> commands, ex.:
> >
> > control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
> PASSWORD]  [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
> [] [--yes]
> >
> > Allowable :
> > --activate - ...
> > --deactivate - ...
> > ...
> >
> > --
> > Best regards,
> > Anton Kalashnikov
> >
> >
> > 26.08.2019, 15:00, "Dmitriy Pavlov" :
> >> Hi Igniters,
> >>
> >> During voting on 2.7.6-rc1, I saw how experienced Ignite contributor
> >> committer and PMC member were trying to activate cluster using
> control.sh
> >> command.
> >>
> >> We usually just call cluster().active(true), but end users have to use
> the
> >> script provided in the distribution.
> >>
> >> Related to control.sh there are 3 concerns:
> >>
> >> Issue 1: On Mac OS if there is an empty (unset) JAVA_HOME variable,
> script
> >> outputs noting and probably does not execute its comment.
> >>
> >> Petr Ivanov, Alexey Goncharuck, could you please double-check if it
> could
> >> be fixed?
> >>
> >> Issue 2: Control.sh was not able to connect to cluster (local). AFAIK
> >> multicast is still our defaults. so it should be possible to connect to
> >> cluster without any options.
> >>
> >> Ivan Rakov, could you please chime in? Is it a local issue or bug?
> >>
> >> Issue 3: Script help usability
> >>
> >> Example of output:
> >>
> >>   Activate cluster:
> >>
> >>  control.sh [--host HOST_OR_IP] [--port PORT] [--user USER]
> [--password
> >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
> >> --activate
> >>
> >>Deactivate cluster:
> >>
> >>  control.sh [--host HOST_OR_IP] [--port PORT] [--user USER]
> [--password
> >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
> >> --deactivate [--yes]
> >>
> >>   ...
> >>
> >> Why do we repeat tons of parameters each time? Is it better for users to
> >> enlist options and commands separately?
> >>
> >>   control.sh [options] command
> >>
> >> and then enlist options
> >>
> >> [--host HOST_OR_IP]
> >>
> >> [--port PORT]
> >>
> >> [--user USER]
> >>
> >> [--password PASSWORD]
> >>
> >> [--ping-interval PING_INTERVAL]
> >>
> >> [--ping-timeout PING_TIMEOUT]
> >>
> >> and describe several commands we have?
> >>
> >> In coding WET is not the best solution. So maybe we could DRY in our
> help,
> >> should we?
> >>
> >> Artem Boudnikov, could you evaluate this idea?
> >>
> >> Sincerely,
> >> Dmitriy Pavlov
>

Re: Control.sh usability & possible bugs

[Artem Budnikov]

Hi everyone,

Re Issue 3:

That's a good idea, but as far as I remember this was done in 
https://jira.apache.org/jira/browse/IGNITE-10279 and is waiting to be 
released in Ignite 2.8.


-Artem

On 26.08.2019 15:18, Anton Kalashnikov wrote:

Hello, Igniters.

+1 for Script help usability - issue 3

Looks like it will be great if we avoid the repeated output of the commands, 
ex.:

control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password PASSWORD]  
[--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT] [] 
[--yes]

Allowable :
--activate - ...
--deactivate - ...
...

--
Best regards,
Anton Kalashnikov


26.08.2019, 15:00, "Dmitriy Pavlov" :

Hi Igniters,

During voting on 2.7.6-rc1, I saw how experienced Ignite contributor
committer and PMC member were trying to activate cluster using control.sh
command.

We usually just call cluster().active(true), but end users have to use the
script provided in the distribution.

Related to control.sh there are 3 concerns:

Issue 1: On Mac OS if there is an empty (unset) JAVA_HOME variable, script
outputs noting and probably does not execute its comment.

Petr Ivanov, Alexey Goncharuck, could you please double-check if it could
be fixed?

Issue 2: Control.sh was not able to connect to cluster (local). AFAIK
multicast is still our defaults. so it should be possible to connect to
cluster without any options.

Ivan Rakov, could you please chime in? Is it a local issue or bug?

Issue 3: Script help usability

Example of output:

  Activate cluster:

 control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
--activate

   Deactivate cluster:

 control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
--deactivate [--yes]

  ...

Why do we repeat tons of parameters each time? Is it better for users to
enlist options and commands separately?

  control.sh [options] command

and then enlist options

[--host HOST_OR_IP]

[--port PORT]

[--user USER]

[--password PASSWORD]

[--ping-interval PING_INTERVAL]

[--ping-timeout PING_TIMEOUT]

and describe several commands we have?

In coding WET is not the best solution. So maybe we could DRY in our help,
should we?

Artem Boudnikov, could you evaluate this idea?

Sincerely,
Dmitriy Pavlov

Re: Developer team membership

[Ilya Kasnacheev]

Hello, Diana!

Do you have jira username registered on https://issues.apache.org/jira/

You need such an account to be assigned tickets. Please share your username
as soon as you have one.

Regards,
-- 
Ilya Kasnacheev


вт, 27 авг. 2019 г. в 16:45, Диана Яковлева :

> Hi,
>
> I'd like to contribute to Ignite project, so can you please give to user
> Diana necessary rights to be able to work on tickets?
>
> Full name: Diana Iakovleva
>
>
> Thanks,
>
> Diana
>

Re: Thin client: transactions support

[Alex Plehanov]

Ilya, Igor,

Nested property is what exactly I've done in the last fix.
ClientConnectorConfiguration now includes ThinClientConfiguration which
contain only one property MaxActiveTxPerConnection for now.

Pavel,

Why do you think that nested ThinClientConfiguration is more confusing than
property in common configuration which related only to part of configurable
elements? In case of nested configuration, user will know that property is
related only to thin client even without reference to JavaDoc.
Now it's only one such property, but if continue to introduce specific
properties to the common configuration in the future, after a while there
will be a mess.


вт, 27 авг. 2019 г. в 15:18, Ilya Kasnacheev :

> Hello!
>
> I think the nested property approach is correct. Sorry for causing the
> confusion.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 27 авг. 2019 г. в 15:06, Igor Sapego :
>
> > Ilya,
> >
> > Sorry, I've just got your first message wrong. I though, you were
> > proposing to remove ClientConnectorConfiguration altogether, my bad.
> >
> > Now, about separating ClientConnectorConfiguration and - I do not
> > propose to make it a copy with the same options. What I was proposing
> > is to keep common settings in ClientConnectorConfiguration and place
> > thin client specific things in a separate class which is going to be
> nested
> > as a property of ClientConnectorConfiguration.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > I don't see why it should break backward compatibility and protocol.
> Can
> > > you please elaborate? I imagine that Thin client with TX muxing support
> > > will just send different requests to which server will respond
> > differently.
> > > Why would anything break?
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
> > >
> > > > Ilya,
> > > >
> > > > This will break backward compatibility and probably protocol, and
> this
> > is
> > > > not something we should discuss in the context of this specific task.
> > > More
> > > > like this is a topic for 3.0 wishlist.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > Also, let's not add IGNITE_ settings for options that can
> reasonably
> > be
> > > > > configured from IgniteConfiguration. Let's keep it for very edge
> > cases.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > > >:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > Do we still need to separate client connector configuration from
> > thin
> > > > > > connector configuration from ODBC connector configuration?
> > > > > >
> > > > > > I think this is a bad practice: For example, people often turn on
> > SSL
> > > > or
> > > > > > auth on just a subset of connectors, think they are secure, when
> in
> > > > fact
> > > > > > they still have unsecured connector around (e.g. ODBC) and their
> > data
> > > > is
> > > > > > not protected at all.
> > > > > >
> > > > > > It may solve some specific issue that you are facing, but for
> > > newcomers
> > > > > to
> > > > > > project it is a drawback. I think we should seek to not add
> > connector
> > > > > > configurations anymore.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov <
> > plehanov.a...@gmail.com
> > > >:
> > > > > >
> > > > > >> Pavel,
> > > > > >>
> > > > > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> > > > clients,
> > > > > >> the
> > > > > >> new property only related to thin clients. If we put the new
> > > property
> > > > > >> directly into ClientConnectorConfiguration, someone might think
> > that
> > > > it
> > > > > >> also affects JDBC and ODBC.
> > > > > >>
> > > > > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn <
> ptupit...@apache.org
> > >:
> > > > > >>
> > > > > >> > Igor, Alex,
> > > > > >> >
> > > > > >> > Not sure I agree with this: ThinClientConfiguration inside
> > > > > >> > ClientConnectorConfiguration.
> > > > > >> > Very confusing IMO, because ClientConnectorConfiguration is
> > > already
> > > > > >> related
> > > > > >> > to thin clients only.
> > > > > >> >
> > > > > >> > Why not put the new property directly into
> > > > > ClientConnectorConfiguration?
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Developer team membership

[Диана Яковлева]

Hi,

I'd like to contribute to Ignite project, so can you please give to user
Diana necessary rights to be able to work on tickets?

Full name: Diana Iakovleva


Thanks,

Diana

Aggregation functions

[Pavel Vinokurov]

Hi Igniters!

I often meet the following use case.
Id
Company_id
Name
Birthday(dd.mm.)
1 1 John 01.01.2000
2 1 Mike 01.01.2010
3 1 Nick 01.01.2015

Having table Person, it requires to select min and max birth-dates and name
of the youngest and oldest person for each company.

The current possible solution is  write the query using join between the
same table. Such query has poor performance and looks quite clumsy. Also it
requires to handle same birth dates:
*Ignite Query(simplified)*
SELECT
  MIN_MAX.company_id,
  p1.name as oldest_name,
  MIN_MAX.min_date,
  p2.name as youngest,
  MIN_MAX.max_date
FROM
(SELECT
 company_id,
 min(birthday) as min_date,
 max(birthday) as max_date
group by company_id) MIN_MAX
INNER JOIN Person p1 on p1.birthday=MIN_MAX.MIN_DATE and
p1.company_id=MIN_MAX.company_id
INNER JOIN Person p2 on p2.birthday=MIN_MAX.MAX_DATE and
p2.company_id=MIN_MAX.company_id

Given performance of this query, it's make sense to re-implement this
usecase using pure java code.

But in H2 it's possible to execute the following query:
SELECT
 company_id,
 first_value(name) over( ORDER BY birthday) as oldest_name,
 min(birthday)
 last_value(name) over( ORDER BY birthday) as youngest_name,
 max(birthday)
group by company_id

Ignite doesn't provide any window or inside grouping functions excepting
GROUP_CONCAT, so we could make the similar query.
SELECT
 company_id,
 PARSE_STRING_AND_GET_FIRST_STRING(GROUP_CONCAT( name order by birthday
SEPARATOR ',')) as oldest_name
 min(birthday)
 PARSE_STRING_AND_GET_LAST_STRING(GROUP_CONCAT( name order by birthday
SEPARATOR ',')) as youngest_name
 max(birthday)
group by company_id

These last 2 queries are much faster(10-100x) than the first one.

Thus I want to clarify a few questions:

   1. Does GROUP_CONCAT[2] function really work and make aggregation
   inside  group( in collocated case)?
   2. Are queries 2 and 3 equivalent?
   3. Is there any options to implement first_value[1], last_value without
   custom partitioning. IMHO first_value is the simplified version of
   GROUP_CONCAT. Am I right?


[1] http://www.h2database.com/html/functions.html#first_value


[2] https://apacheignite-sql.readme.io/docs/group_concat


Thanks,

Pavel



-- 

Regards

Pavel Vinokurov

Re: Thin client: transactions support

[Ilya Kasnacheev]

Hello!

I think the nested property approach is correct. Sorry for causing the
confusion.

Regards,
-- 
Ilya Kasnacheev


вт, 27 авг. 2019 г. в 15:06, Igor Sapego :

> Ilya,
>
> Sorry, I've just got your first message wrong. I though, you were
> proposing to remove ClientConnectorConfiguration altogether, my bad.
>
> Now, about separating ClientConnectorConfiguration and - I do not
> propose to make it a copy with the same options. What I was proposing
> is to keep common settings in ClientConnectorConfiguration and place
> thin client specific things in a separate class which is going to be nested
> as a property of ClientConnectorConfiguration.
>
> Best Regards,
> Igor
>
>
> On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> wrote:
>
> > Hello!
> >
> > I don't see why it should break backward compatibility and protocol. Can
> > you please elaborate? I imagine that Thin client with TX muxing support
> > will just send different requests to which server will respond
> differently.
> > Why would anything break?
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
> >
> > > Ilya,
> > >
> > > This will break backward compatibility and probably protocol, and this
> is
> > > not something we should discuss in the context of this specific task.
> > More
> > > like this is a topic for 3.0 wishlist.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > Also, let's not add IGNITE_ settings for options that can reasonably
> be
> > > > configured from IgniteConfiguration. Let's keep it for very edge
> cases.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >:
> > > >
> > > > > Hello!
> > > > >
> > > > > Do we still need to separate client connector configuration from
> thin
> > > > > connector configuration from ODBC connector configuration?
> > > > >
> > > > > I think this is a bad practice: For example, people often turn on
> SSL
> > > or
> > > > > auth on just a subset of connectors, think they are secure, when in
> > > fact
> > > > > they still have unsecured connector around (e.g. ODBC) and their
> data
> > > is
> > > > > not protected at all.
> > > > >
> > > > > It may solve some specific issue that you are facing, but for
> > newcomers
> > > > to
> > > > > project it is a drawback. I think we should seek to not add
> connector
> > > > > configurations anymore.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov <
> plehanov.a...@gmail.com
> > >:
> > > > >
> > > > >> Pavel,
> > > > >>
> > > > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> > > clients,
> > > > >> the
> > > > >> new property only related to thin clients. If we put the new
> > property
> > > > >> directly into ClientConnectorConfiguration, someone might think
> that
> > > it
> > > > >> also affects JDBC and ODBC.
> > > > >>
> > > > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn  >:
> > > > >>
> > > > >> > Igor, Alex,
> > > > >> >
> > > > >> > Not sure I agree with this: ThinClientConfiguration inside
> > > > >> > ClientConnectorConfiguration.
> > > > >> > Very confusing IMO, because ClientConnectorConfiguration is
> > already
> > > > >> related
> > > > >> > to thin clients only.
> > > > >> >
> > > > >> > Why not put the new property directly into
> > > > ClientConnectorConfiguration?
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: Replacing default work dir from tmp to current dir

[Dmitriy Pavlov]

Hi Igniters,

I agree that user home maybe not the best place from Linux perspective and
philosophy, but  "user.home"/ignite/work  is more or less portable.

For the Linux environment, we can add a suggestion about where to place
persisted data. For very first testing of Apache Ignite user home still
looks good for me.

Sincerely,
Dmitriy Pavlov

вт, 27 авг. 2019 г. в 11:56, Pavel Pereslegin :

> Or instead of a WARNING, we can add a suggestion with a recommendation
> for the production environment.
>
> вт, 27 авг. 2019 г. в 11:41, Petr Ivanov :
> >
> > /opt is either does not exist on fresh system, or has the same
> restriction: no user access without admin intervention.
> > /usr/local, /var/lib, etc. — all this is implemented in our DEB / RPM
> packages already.
> >
> > For ZIP installation %HOME% seems to be the best approach for "2-click"
> launch.
> > Later user can update preferences and set working dir to whatever
> directory he would like.
> >
> > Also — we can put WARNING message to log noting that WORK_DIR is set to
> default.
> >
> > > On 27 Aug 2019, at 10:16, Zhenya Stanilovsky
>  wrote:
> > >
> > >
> > > And what about /opt/ignite ?
> > >
> > > copy-paste:
> > > "
> > > The basic difference is that  /usr/local  is for software not managed
> by the system packager, but still following the standard unix deployment
> rules.
> > > That's why you have  /usr/local/bin ,  /usr/local/sbin
>  /usr/local/include  etc...
> > > /opt  on the other hand is for software that doesn't follow this and
> is deployed in a monolithic fashion. This usually includes commercial
> and/or cross-platform software that is packaged in the "Windows" style. "
> > >
> > >
> > >> Понедельник, 26 августа 2019, 22:49 +03:00 от Denis Magda <
> dma...@apache.org>:
> > >>
> > >> Igniters,
> > >>
> > >> I can't disagree with Nikolay that, as a database, Ignite needs to
> persist
> > >> changes to a folder different from "user.home" one. But with the
> current
> > >> rate of project growth and adoption, I would encourage us to
> eliminate any
> > >> possible obstacles a user might come across during the getting started
> > >> phase with Ignite. Unfortunately, folders different from "user.home"
> imply
> > >> a significant restriction - the user needs to allow access to folders
> like
> > >> /lib, /etc; which can make every getting started demo or app fail.
> > >>
> > >> Thus, today, I'm casting my vote for "user.home"/ignite/work
> directory.
> > >> Please don't forget about Windows and MacOS.
> > >>
> > >> -
> > >> Denis
> > >>
> > >>
> > >> On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn < ptupit...@apache.org
> > wrote:
> > >>
> > >>> +1 for  ~/.ignite/work
> > >>>
> > >>> As Petr mentioned above, this translates well to Windows and MacOS
> too, we
> > >>> can use "home directory" term in documentation and it works for any
> OS.
> > >>>
> > >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov <
> nizhi...@apache.org >
> > >>> wrote:
> > >>>
> >  AFAIK server admin expects software will store it's data in /var/
> >  directory, not in /home directory.
> > 
> > > In Docker age, packages are becoming extinct.
> > 
> >  I don't agree with that, but seems, it's not a subject of
> discussion. :)
> > 
> > > we don't even have very good packages today
> > 
> >  Why do you think we don't have good packages?
> >  What is wrong with the current one?
> > 
> > > I also think we should not copy what other DBMS do since their
> >  ease-of-use
> > > is usually lacking
> > 
> >  We should define 'easy-of-use' here.
> >  My experience with the modern dbms(postgres and mysql) is different.
> > 
> > 
> >  В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет:
> > > Hello!
> > >
> > > I think it is 2., because if a node is run from Ignite binary
> >  distribution
> > > it has its root as a ignite work directory. I think it it another
> >  argument
> > > for keeping data under current dir - Ignite binary distribution
> already
> > > does it, why should embedded scenario be different?
> > >
> > > In Docker age, packages are becoming extinct. Nobody wants them
> > >>> anymore,
> > > anyway. I don't see why we should aim for those since we don't even
> > >>> have
> > > very good packages today, and nobody wants to contribute towards
> their
> > > improvement.
> > >
> > > I also think we should not copy what other DBMS do since their
> >  ease-of-use
> > > is usually lacking (this is from someone who had to support mysql
> and
> >  pgsql
> > > deployments).
> > >
> > > Regards,
> > 
> > >>>
> > >
> > >
> > > --
> > > Zhenya Stanilovsky
> >
>

Re: Thin client: transactions support

[Igor Sapego]

Ilya,

Sorry, I've just got your first message wrong. I though, you were
proposing to remove ClientConnectorConfiguration altogether, my bad.

Now, about separating ClientConnectorConfiguration and - I do not
propose to make it a copy with the same options. What I was proposing
is to keep common settings in ClientConnectorConfiguration and place
thin client specific things in a separate class which is going to be nested
as a property of ClientConnectorConfiguration.

Best Regards,
Igor


On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> I don't see why it should break backward compatibility and protocol. Can
> you please elaborate? I imagine that Thin client with TX muxing support
> will just send different requests to which server will respond differently.
> Why would anything break?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
>
> > Ilya,
> >
> > This will break backward compatibility and probably protocol, and this is
> > not something we should discuss in the context of this specific task.
> More
> > like this is a topic for 3.0 wishlist.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > Also, let's not add IGNITE_ settings for options that can reasonably be
> > > configured from IgniteConfiguration. Let's keep it for very edge cases.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >:
> > >
> > > > Hello!
> > > >
> > > > Do we still need to separate client connector configuration from thin
> > > > connector configuration from ODBC connector configuration?
> > > >
> > > > I think this is a bad practice: For example, people often turn on SSL
> > or
> > > > auth on just a subset of connectors, think they are secure, when in
> > fact
> > > > they still have unsecured connector around (e.g. ODBC) and their data
> > is
> > > > not protected at all.
> > > >
> > > > It may solve some specific issue that you are facing, but for
> newcomers
> > > to
> > > > project it is a drawback. I think we should seek to not add connector
> > > > configurations anymore.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov  >:
> > > >
> > > >> Pavel,
> > > >>
> > > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> > clients,
> > > >> the
> > > >> new property only related to thin clients. If we put the new
> property
> > > >> directly into ClientConnectorConfiguration, someone might think that
> > it
> > > >> also affects JDBC and ODBC.
> > > >>
> > > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn :
> > > >>
> > > >> > Igor, Alex,
> > > >> >
> > > >> > Not sure I agree with this: ThinClientConfiguration inside
> > > >> > ClientConnectorConfiguration.
> > > >> > Very confusing IMO, because ClientConnectorConfiguration is
> already
> > > >> related
> > > >> > to thin clients only.
> > > >> >
> > > >> > Why not put the new property directly into
> > > ClientConnectorConfiguration?
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: Nabble message wrapping

[Dmitriy Pavlov]

Hi Denis,

AFAIK, nabble forums are service, which resides outside of ASF infra. They
have their separate support/feedback form.

Maybe some PMC members could have some credentials for this service. If so,
please share login info in SVN/private/credentials.

Sincerely,
Dmitriy Pavlov

вт, 27 авг. 2019 г. в 12:12, Denis Mekhanikov :

> Hi!
>
> The Nabble forum formats emails in a way that makes quoted messages
> unreadable.
>
> For example, take a look at the latest messages in the following thread:
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-6-Time-Scope-and-Release-manager-td42944.html
>
> The beginning of the messages look fine, but by the end they turn into
> something like
>
> >> > > > > > > > > > > > > > > If nobody minds, I will create branch 2.7.6
> >> based
> >> > > on
> >> > > > >
> >> > > > > 2.7.5
> >> > > > > > > and
> >> > > > > > > > > > set up
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > in
> >> > > > > > > > > > > > > > > the TC Bot during the weekend.
> >> > > > > > > > > > > > > > >
> >> > > > > > > > > > > > > > >
> >> > > > > > > > > > > > > > >
> >> > > > > > > > > > > > > > > Sincerely,
> >> > > > > > > > > > > > > > >
> >> > > > > > > > > > > > > > > Dmitriy Pavlov
> >> > > > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > --
> >> > > > > > > > > > > > > Best regards,
> >> > > > > > > > > > > > > Ivan Pavlukhin
> >> > > > > > > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > --
> >> > > > > > > > Zhenya Stanilovsky
> >> > > > > > > >
> >> > >
> >> >
> >>
>
> Email clients suffer from such formatting. Some start working extremely
> slowly, some just apply psychedelic colouring.
> Can we do something with it? It seems to me that line wrapping is causing
> this.
>
> Nabble forum for users list doesn’t seem to suffer from such issue:
> http://apache-ignite-users.70518.x6.nabble.com/
> For example, the following thread is long, but it’s formatted just fine:
> http://apache-ignite-users.70518.x6.nabble.com/Access-a-cache-loaded-by-DataStreamer-with-SQL-td27180.html
> Can we configure the dev list forum in the same way?
>
> Denis
>

Re: [Discussion] Documentation process improvement: Release notes

[Dmitriy Pavlov]

Hi Igniters,

Thanks to everyone, https://issues.apache.org/jira/browse/INFRA-18944 created.
For relatively small releases like 2.7.5,2.7.6, it is ok to collect RN
manually, but for a major release, I assume we need a separate field for it.

I also found not completed issue, which could benefit from separate field
creation:
https://issues.apache.org/jira/browse/IGNITE-5355

Sincerely,
Dmitriy Pavlov

пн, 20 мая 2019 г. в 18:30, Garrett Alley :

> I like the flag, it would help cut down on the work involved in creating
> the release notes. Eventually, we may want to group the fixes "by
> component" in the release notes.
>
> -g-
>
> On Mon, May 20, 2019 at 4:28 AM Ilya Kasnacheev  >
> wrote:
>
> > Hello!
> >
> > I think it definitely makes sense to have Release Notes field in JIRA
> > tickets (start using it if it is already present?). Not sure about the
> > flag.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 20 мая 2019 г. в 13:23, Dmitriy Pavlov :
> >
> > > Hi Ignite Developers,
> > >
> > > Kindly Reminder, please review the proposed changes and share your
> > vision.
> > > I would appreciate if this change will be approved by community
> members,
> > > but not via silence.
> > >
> > > Sincerely
> > > Dmitriy Pavlov
> > >
> > > вт, 14 мая 2019 г. в 15:19, Dmitriy Pavlov :
> > >
> > > > Hi Igniters,
> > > >
> > > > During the preparation of release candidate 2.7.5, I’ve missed the
> > > > development of Release notes for it, and this caused delay for a
> vote.
> > > >
> > > > I want to suggest simple changes in our documentation process. Some
> > time
> > > > ago Artem B. proposed similar for the doc, but I would like to adapt
> it
> > > for
> > > > release notes.
> > > >
> > > > Let us
> > > > - Enrich Ignite flags with 'Release Notes required' flag (default is,
> > as
> > > > always, true)
> > > > - Add field 'Release Notes' to Ignite project.
> > > >
> > > > All tickets with empty Release Notes fields but with flag set may be
> > > > checked with contributor if it needs to be mentioned in
> > > RELEASE_NOTES.txt.
> > > >
> > > > If we agree on these changes, I’ll ask infra to add these fields in 3
> > > > days.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-12110) Bugs & tests fixes

[Dmitriy Govorukhin (Jira)]

Dmitriy Govorukhin created IGNITE-12110:
---

 Summary:  Bugs & tests fixes
 Key: IGNITE-12110
 URL: https://issues.apache.org/jira/browse/IGNITE-12110
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin






--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Nabble message wrapping

[Denis Mekhanikov]

Hi!

The Nabble forum formats emails in a way that makes quoted messages unreadable.

For example, take a look at the latest messages in the following thread: 
http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-6-Time-Scope-and-Release-manager-td42944.html

The beginning of the messages look fine, but by the end they turn into 
something like

>> > > > > > > > > > > > > > > If nobody minds, I will create branch 2.7.6
>> based
>> > > on
>> > > > >
>> > > > > 2.7.5
>> > > > > > > and
>> > > > > > > > > > set up
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > in
>> > > > > > > > > > > > > > > the TC Bot during the weekend.
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > Sincerely,
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > Dmitriy Pavlov
>> > > > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > --
>> > > > > > > > > > > > > Best regards,
>> > > > > > > > > > > > > Ivan Pavlukhin
>> > > > > > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Zhenya Stanilovsky
>> > > > > > > >
>> > >
>> >
>>

Email clients suffer from such formatting. Some start working extremely slowly, 
some just apply psychedelic colouring.
Can we do something with it? It seems to me that line wrapping is causing this.

Nabble forum for users list doesn’t seem to suffer from such issue: 
http://apache-ignite-users.70518.x6.nabble.com/
For example, the following thread is long, but it’s formatted just fine: 
http://apache-ignite-users.70518.x6.nabble.com/Access-a-cache-loaded-by-DataStreamer-with-SQL-td27180.html
Can we configure the dev list forum in the same way?

Denis

Re: Thin client: transactions support

[Ilya Kasnacheev]

Hello!

I don't see why it should break backward compatibility and protocol. Can
you please elaborate? I imagine that Thin client with TX muxing support
will just send different requests to which server will respond differently.
Why would anything break?

Regards,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 14:16, Igor Sapego :

> Ilya,
>
> This will break backward compatibility and probably protocol, and this is
> not something we should discuss in the context of this specific task. More
> like this is a topic for 3.0 wishlist.
>
> Best Regards,
> Igor
>
>
> On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> wrote:
>
> > Hello!
> >
> > Also, let's not add IGNITE_ settings for options that can reasonably be
> > configured from IgniteConfiguration. Let's keep it for very edge cases.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev  >:
> >
> > > Hello!
> > >
> > > Do we still need to separate client connector configuration from thin
> > > connector configuration from ODBC connector configuration?
> > >
> > > I think this is a bad practice: For example, people often turn on SSL
> or
> > > auth on just a subset of connectors, think they are secure, when in
> fact
> > > they still have unsecured connector around (e.g. ODBC) and their data
> is
> > > not protected at all.
> > >
> > > It may solve some specific issue that you are facing, but for newcomers
> > to
> > > project it is a drawback. I think we should seek to not add connector
> > > configurations anymore.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov :
> > >
> > >> Pavel,
> > >>
> > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> clients,
> > >> the
> > >> new property only related to thin clients. If we put the new property
> > >> directly into ClientConnectorConfiguration, someone might think that
> it
> > >> also affects JDBC and ODBC.
> > >>
> > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn :
> > >>
> > >> > Igor, Alex,
> > >> >
> > >> > Not sure I agree with this: ThinClientConfiguration inside
> > >> > ClientConnectorConfiguration.
> > >> > Very confusing IMO, because ClientConnectorConfiguration is already
> > >> related
> > >> > to thin clients only.
> > >> >
> > >> > Why not put the new property directly into
> > ClientConnectorConfiguration?
> > >> >
> > >>
> > >
> >
>

Re: Replacing default work dir from tmp to current dir

[Pavel Pereslegin]

Or instead of a WARNING, we can add a suggestion with a recommendation
for the production environment.

вт, 27 авг. 2019 г. в 11:41, Petr Ivanov :
>
> /opt is either does not exist on fresh system, or has the same restriction: 
> no user access without admin intervention.
> /usr/local, /var/lib, etc. — all this is implemented in our DEB / RPM 
> packages already.
>
> For ZIP installation %HOME% seems to be the best approach for "2-click" 
> launch.
> Later user can update preferences and set working dir to whatever directory 
> he would like.
>
> Also — we can put WARNING message to log noting that WORK_DIR is set to 
> default.
>
> > On 27 Aug 2019, at 10:16, Zhenya Stanilovsky  
> > wrote:
> >
> >
> > And what about /opt/ignite ?
> >
> > copy-paste:
> > "
> > The basic difference is that  /usr/local  is for software not managed by 
> > the system packager, but still following the standard unix deployment rules.
> > That's why you have  /usr/local/bin ,  /usr/local/sbin   /usr/local/include 
> >  etc...
> > /opt  on the other hand is for software that doesn't follow this and is 
> > deployed in a monolithic fashion. This usually includes commercial and/or 
> > cross-platform software that is packaged in the "Windows" style. "
> >
> >
> >> Понедельник, 26 августа 2019, 22:49 +03:00 от Denis Magda 
> >> :
> >>
> >> Igniters,
> >>
> >> I can't disagree with Nikolay that, as a database, Ignite needs to persist
> >> changes to a folder different from "user.home" one. But with the current
> >> rate of project growth and adoption, I would encourage us to eliminate any
> >> possible obstacles a user might come across during the getting started
> >> phase with Ignite. Unfortunately, folders different from "user.home" imply
> >> a significant restriction - the user needs to allow access to folders like
> >> /lib, /etc; which can make every getting started demo or app fail.
> >>
> >> Thus, today, I'm casting my vote for "user.home"/ignite/work directory.
> >> Please don't forget about Windows and MacOS.
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn < ptupit...@apache.org > 
> >> wrote:
> >>
> >>> +1 for  ~/.ignite/work
> >>>
> >>> As Petr mentioned above, this translates well to Windows and MacOS too, we
> >>> can use "home directory" term in documentation and it works for any OS.
> >>>
> >>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov < nizhi...@apache.org >
> >>> wrote:
> >>>
>  AFAIK server admin expects software will store it's data in /var/
>  directory, not in /home directory.
> 
> > In Docker age, packages are becoming extinct.
> 
>  I don't agree with that, but seems, it's not a subject of discussion. :)
> 
> > we don't even have very good packages today
> 
>  Why do you think we don't have good packages?
>  What is wrong with the current one?
> 
> > I also think we should not copy what other DBMS do since their
>  ease-of-use
> > is usually lacking
> 
>  We should define 'easy-of-use' here.
>  My experience with the modern dbms(postgres and mysql) is different.
> 
> 
>  В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет:
> > Hello!
> >
> > I think it is 2., because if a node is run from Ignite binary
>  distribution
> > it has its root as a ignite work directory. I think it it another
>  argument
> > for keeping data under current dir - Ignite binary distribution already
> > does it, why should embedded scenario be different?
> >
> > In Docker age, packages are becoming extinct. Nobody wants them
> >>> anymore,
> > anyway. I don't see why we should aim for those since we don't even
> >>> have
> > very good packages today, and nobody wants to contribute towards their
> > improvement.
> >
> > I also think we should not copy what other DBMS do since their
>  ease-of-use
> > is usually lacking (this is from someone who had to support mysql and
>  pgsql
> > deployments).
> >
> > Regards,
> 
> >>>
> >
> >
> > --
> > Zhenya Stanilovsky
>

[jira] [Created] (IGNITE-12109) The distributed metastorage must support read/write operation on an inactive cluster.

[Ivan Bessonov (Jira)]

Ivan Bessonov created IGNITE-12109:
--

 Summary: The distributed metastorage must support read/write 
operation on an inactive cluster.
 Key: IGNITE-12109
 URL: https://issues.apache.org/jira/browse/IGNITE-12109
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


The metastorage isn't able to propagate value on an inactive cluster.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Replacing default work dir from tmp to current dir

[Petr Ivanov]

/opt is either does not exist on fresh system, or has the same restriction: no 
user access without admin intervention.
/usr/local, /var/lib, etc. — all this is implemented in our DEB / RPM packages 
already.

For ZIP installation %HOME% seems to be the best approach for "2-click" launch.
Later user can update preferences and set working dir to whatever directory he 
would like.

Also — we can put WARNING message to log noting that WORK_DIR is set to default.

> On 27 Aug 2019, at 10:16, Zhenya Stanilovsky  
> wrote:
> 
> 
> And what about /opt/ignite ? 
> 
> copy-paste:
> "
> The basic difference is that  /usr/local  is for software not managed by the 
> system packager, but still following the standard unix deployment rules.
> That's why you have  /usr/local/bin ,  /usr/local/sbin   /usr/local/include  
> etc...
> /opt  on the other hand is for software that doesn't follow this and is 
> deployed in a monolithic fashion. This usually includes commercial and/or 
> cross-platform software that is packaged in the "Windows" style. "
> 
> 
>> Понедельник, 26 августа 2019, 22:49 +03:00 от Denis Magda 
>> :
>> 
>> Igniters,
>> 
>> I can't disagree with Nikolay that, as a database, Ignite needs to persist
>> changes to a folder different from "user.home" one. But with the current
>> rate of project growth and adoption, I would encourage us to eliminate any
>> possible obstacles a user might come across during the getting started
>> phase with Ignite. Unfortunately, folders different from "user.home" imply
>> a significant restriction - the user needs to allow access to folders like
>> /lib, /etc; which can make every getting started demo or app fail.
>> 
>> Thus, today, I'm casting my vote for "user.home"/ignite/work directory.
>> Please don't forget about Windows and MacOS.
>> 
>> -
>> Denis
>> 
>> 
>> On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn < ptupit...@apache.org > 
>> wrote:
>> 
>>> +1 for  ~/.ignite/work
>>> 
>>> As Petr mentioned above, this translates well to Windows and MacOS too, we
>>> can use "home directory" term in documentation and it works for any OS.
>>> 
>>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov < nizhi...@apache.org >
>>> wrote:
>>> 
 AFAIK server admin expects software will store it's data in /var/
 directory, not in /home directory.
 
> In Docker age, packages are becoming extinct.
 
 I don't agree with that, but seems, it's not a subject of discussion. :)
 
> we don't even have very good packages today
 
 Why do you think we don't have good packages?
 What is wrong with the current one?
 
> I also think we should not copy what other DBMS do since their
 ease-of-use
> is usually lacking
 
 We should define 'easy-of-use' here.
 My experience with the modern dbms(postgres and mysql) is different.
 
 
 В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет:
> Hello!
> 
> I think it is 2., because if a node is run from Ignite binary
 distribution
> it has its root as a ignite work directory. I think it it another
 argument
> for keeping data under current dir - Ignite binary distribution already
> does it, why should embedded scenario be different?
> 
> In Docker age, packages are becoming extinct. Nobody wants them
>>> anymore,
> anyway. I don't see why we should aim for those since we don't even
>>> have
> very good packages today, and nobody wants to contribute towards their
> improvement.
> 
> I also think we should not copy what other DBMS do since their
 ease-of-use
> is usually lacking (this is from someone who had to support mysql and
 pgsql
> deployments).
> 
> Regards,
 
>>> 
> 
> 
> -- 
> Zhenya Stanilovsky

[jira] [Created] (IGNITE-12108) [IEP-35] Migrate Communication Metrics.

[Ivan Bessonov (Jira)]

Ivan Bessonov created IGNITE-12108:
--

 Summary: [IEP-35] Migrate Communication Metrics.
 Key: IGNITE-12108
 URL: https://issues.apache.org/jira/browse/IGNITE-12108
 Project: Ignite
  Issue Type: New Feature
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


||*Name*||*Description*||
|communication.tcp.outboundMessagesQueueSize|Number of messages waiting to be 
sent|
|communication.tcp.sentBytes|Total number of bytes received by current node|
|communication.tcp.receivedBytes|Total number of bytes sent by current node|
|communication.tcp.sentMessagesCount|Total number of messages sent by current 
node|
|communication.tcp.receivedMessagesCount|Total number of messages received by 
current node|
|communication.tcp.sentMessagesByType.|Total number of messages 
with given type sent by current node|
|communication.tcp.receivedMessagesByType.|Total number of messages 
with given type received by current node|
|communication.tcp..sentMessagesToNode|Total number of messages sent by 
current node to the given node|
|communication.tcp..receivedMessagesFromNode|Total number of messages 
received by current node from the given node|

 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re[2]: Replacing default work dir from tmp to current dir

[Zhenya Stanilovsky]

And what about /opt/ignite ? 

copy-paste:
"
The basic difference is that  /usr/local  is for software not managed by the 
system packager, but still following the standard unix deployment rules.
That's why you have  /usr/local/bin ,  /usr/local/sbin   /usr/local/include  
etc...
/opt  on the other hand is for software that doesn't follow this and is 
deployed in a monolithic fashion. This usually includes commercial and/or 
cross-platform software that is packaged in the "Windows" style. "


>Понедельник, 26 августа 2019, 22:49 +03:00 от Denis Magda :
>
>Igniters,
>
>I can't disagree with Nikolay that, as a database, Ignite needs to persist
>changes to a folder different from "user.home" one. But with the current
>rate of project growth and adoption, I would encourage us to eliminate any
>possible obstacles a user might come across during the getting started
>phase with Ignite. Unfortunately, folders different from "user.home" imply
>a significant restriction - the user needs to allow access to folders like
>/lib, /etc; which can make every getting started demo or app fail.
>
>Thus, today, I'm casting my vote for "user.home"/ignite/work directory.
>Please don't forget about Windows and MacOS.
>
>-
>Denis
>
>
>On Mon, Aug 26, 2019 at 7:09 AM Pavel Tupitsyn < ptupit...@apache.org > wrote:
>
>> +1 for  ~/.ignite/work
>>
>> As Petr mentioned above, this translates well to Windows and MacOS too, we
>> can use "home directory" term in documentation and it works for any OS.
>>
>> On Mon, Aug 26, 2019 at 4:03 PM Nikolay Izhikov < nizhi...@apache.org >
>> wrote:
>>
>> > AFAIK server admin expects software will store it's data in /var/
>> > directory, not in /home directory.
>> >
>> > > In Docker age, packages are becoming extinct.
>> >
>> > I don't agree with that, but seems, it's not a subject of discussion. :)
>> >
>> > > we don't even have very good packages today
>> >
>> > Why do you think we don't have good packages?
>> > What is wrong with the current one?
>> >
>> > > I also think we should not copy what other DBMS do since their
>> > ease-of-use
>> > > is usually lacking
>> >
>> > We should define 'easy-of-use' here.
>> > My experience with the modern dbms(postgres and mysql) is different.
>> >
>> >
>> > В Пн, 26/08/2019 в 15:47 +0300, Ilya Kasnacheev пишет:
>> > > Hello!
>> > >
>> > > I think it is 2., because if a node is run from Ignite binary
>> > distribution
>> > > it has its root as a ignite work directory. I think it it another
>> > argument
>> > > for keeping data under current dir - Ignite binary distribution already
>> > > does it, why should embedded scenario be different?
>> > >
>> > > In Docker age, packages are becoming extinct. Nobody wants them
>> anymore,
>> > > anyway. I don't see why we should aim for those since we don't even
>> have
>> > > very good packages today, and nobody wants to contribute towards their
>> > > improvement.
>> > >
>> > > I also think we should not copy what other DBMS do since their
>> > ease-of-use
>> > > is usually lacking (this is from someone who had to support mysql and
>> > pgsql
>> > > deployments).
>> > >
>> > > Regards,
>> >
>>


-- 
Zhenya Stanilovsky