Re: Replacing default work dir from tmp to current dir

[Dmitriy Pavlov]

I agree that ~/work is not expected. I was pretty sure it will be
~/ignite/work or ~/.ignite/work

Sorry, but ~/work I may use for my day job stuff. I don't expect any files
appear there if I start to play with Apache Ignite for the first time.

Since it is a potential usability issue, which is very hard to change once
we release product,

I keep the vote open to having an option to cancel it if this discussion we
come to conclusion product should use ~/ignite.

пн, 26 авг. 2019 г. в 01:42, Павлухин Иван :

> Ilya,
>
> 2 points:
> 1. It is a good point that a directory name "work" in arbitrary place
> can cause a lot of confusion.
> 2. As far as I got, default directory is not in e.g. /home/username
> but in one pointed by "user.dir" system property which is a directory
> where a java process started (if property was not overridden).
>
> 2019-08-26 1:59 GMT+11:00, Ilya Kasnacheev :
> > Hello!
> >
> > I am really worried by the fact that previously we had /tmp/ignite and in
> > it work/, whereas now we're going to write to /home/username/work
> >
> > I doubt that users can attribute work/ directory in their home to Ignite,
> > especially when it is used as library by something else.
> >
> > Is there a chance we could move this work dir to /home/username/ignite
> with
> > work/ (and possibly logs/) dir in it? WDYT?
> >
> > We could even auto-create README.TXT in this /home/username/ignite/ to
> > describe that it's Apache Ignite work directory and how to change it.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 12 авг. 2019 г. в 19:02, Denis Magda :
> >
> >> +1 for the user.dir as a default one.
> >>
> >> Denis
> >>
> >> On Monday, August 12, 2019, Dmitriy Pavlov  wrote:
> >>
> >> > +1 to user home directory. A number of open source products create
> >> > their
> >> > dirs there. For me, it is a kind of expected behavior.
> >> >
> >> > Ivan mentioned an important point: binary meta & marshaller. We should
> >> > update documentation and stop require PDS dir setup, but require home
> >> setup
> >> > (for older versions of Ignite, it is relevant anyway).
> >> >
> >> > пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn :
> >> >
> >> > > Hi Ivan,
> >> > >
> >> > > >  fail Ignite node in case neither IGNITE_HOME
> >> > > nor IgniteConfiguration#igniteWorkDir is set
> >> > > I strongly disagree, this is bad usability.
> >> > > Ignition.start() should work without any extra configuration as is
> it
> >> > right
> >> > > now.
> >> > >
> >> > > Let's come up with reasonable defaults instead, user dir sounds good
> >> > > to
> >> > me.
> >> > >
> >> > > On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
> >> > > stephen.darling...@gridgain.com> wrote:
> >> > >
> >> > > > Yes, when data is a stake, fail early is the absolutely the right
> >> thing
> >> > > to
> >> > > > do.
> >> > > >
> >> > > > Regards,
> >> > > > Stephen
> >> > > >
> >> > > > > On 12 Aug 2019, at 16:37, Ivan Rakov 
> >> wrote:
> >> > > > >
> >> > > > > Hi Anton,
> >> > > > >
> >> > > > > Actually, the issue is even more unpleasant.
> >> > > > >
> >> > > > > Official Ignite documentation says that it's possible to
> >> > > > > configure
> >> > path
> >> > > > where your persistence files will be stored:
> >> > > > https://apacheignite.readme.io/docs/distributed-persistent-store
> >> > > > > However, even if you have set all path options (storage, WAL,
> WAL
> >> > > > archive), Ignite will still store crucial metadata in resolved
> work
> >> > > > directory (java.io.tmpdir by default). Example is binary metadata
> >> > files,
> >> > > > absence of which can make your data unavailable.
> >> > > > >
> >> > > > > I propose to fail Ignite node in case neither IGNITE_HOME nor
> >> > > > IgniteConfiguration#igniteWorkDir is set. It's better to let user
> >> know
> >> > > > about missing configuration options during startup than let OS
> >> corrupt
> >> > > > storage by cleaning temp dirs.
> >> > > > >
> >> > > > > Thoughts?
> >> > > > >
> >> > > > > Best Regards,
> >> > > > > Ivan Rakov
> >> > > > >
> >> > > > > On 12.08.2019 18:10, Anton Kalashnikov wrote:
> >> > > > >> Hello, Igniters.
> >> > > > >>
> >> > > > >> Currently, in the case, when work directory wasn't set by user
> >> > ignite
> >> > > > can resolve it to tmp directory which leads to some problem - tmp
> >> > > directory
> >> > > > can be cleared at some unexpected moment by operation system and
> >> > > different
> >> > > > types of critical data would be lost(ex. binary_meta, persistance
> >> > data).
> >> > > > >>
> >> > > > >> Looks like it is not expected behaviour and maybe it is better
> >> > instead
> >> > > > of tmp directory use the current working directory("user.dir")? Or
> >> any
> >> > > > other idea?
> >> > > > >>
> >> > > > >> A little more details you can find in the ticket -
> >> > > > https://issues.apache.org/jira/browse/IGNITE-12057
> >> > > > >> --
> >> > > > >> Best regards,
> >> > > > >> Anton Kalashnikov
> >> > > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > >
>

Re: Thin client: transactions support

[Pavel Tupitsyn]

I think it is less confusing than  ThinClientConfiguration.

On Fri, Aug 23, 2019 at 8:49 PM Alex Plehanov 
wrote:

> 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 Tupitsyn]

I was certainly expecting ~/ignite/work too, not just ~/work

On Mon, Aug 26, 2019 at 10:19 AM Dmitriy Pavlov  wrote:

> I agree that ~/work is not expected. I was pretty sure it will be
> ~/ignite/work or ~/.ignite/work
>
> Sorry, but ~/work I may use for my day job stuff. I don't expect any files
> appear there if I start to play with Apache Ignite for the first time.
>
> Since it is a potential usability issue, which is very hard to change once
> we release product,
>
> I keep the vote open to having an option to cancel it if this discussion we
> come to conclusion product should use ~/ignite.
>
> пн, 26 авг. 2019 г. в 01:42, Павлухин Иван :
>
> > Ilya,
> >
> > 2 points:
> > 1. It is a good point that a directory name "work" in arbitrary place
> > can cause a lot of confusion.
> > 2. As far as I got, default directory is not in e.g. /home/username
> > but in one pointed by "user.dir" system property which is a directory
> > where a java process started (if property was not overridden).
> >
> > 2019-08-26 1:59 GMT+11:00, Ilya Kasnacheev :
> > > Hello!
> > >
> > > I am really worried by the fact that previously we had /tmp/ignite and
> in
> > > it work/, whereas now we're going to write to /home/username/work
> > >
> > > I doubt that users can attribute work/ directory in their home to
> Ignite,
> > > especially when it is used as library by something else.
> > >
> > > Is there a chance we could move this work dir to /home/username/ignite
> > with
> > > work/ (and possibly logs/) dir in it? WDYT?
> > >
> > > We could even auto-create README.TXT in this /home/username/ignite/ to
> > > describe that it's Apache Ignite work directory and how to change it.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 12 авг. 2019 г. в 19:02, Denis Magda :
> > >
> > >> +1 for the user.dir as a default one.
> > >>
> > >> Denis
> > >>
> > >> On Monday, August 12, 2019, Dmitriy Pavlov 
> wrote:
> > >>
> > >> > +1 to user home directory. A number of open source products create
> > >> > their
> > >> > dirs there. For me, it is a kind of expected behavior.
> > >> >
> > >> > Ivan mentioned an important point: binary meta & marshaller. We
> should
> > >> > update documentation and stop require PDS dir setup, but require
> home
> > >> setup
> > >> > (for older versions of Ignite, it is relevant anyway).
> > >> >
> > >> > пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn :
> > >> >
> > >> > > Hi Ivan,
> > >> > >
> > >> > > >  fail Ignite node in case neither IGNITE_HOME
> > >> > > nor IgniteConfiguration#igniteWorkDir is set
> > >> > > I strongly disagree, this is bad usability.
> > >> > > Ignition.start() should work without any extra configuration as is
> > it
> > >> > right
> > >> > > now.
> > >> > >
> > >> > > Let's come up with reasonable defaults instead, user dir sounds
> good
> > >> > > to
> > >> > me.
> > >> > >
> > >> > > On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
> > >> > > stephen.darling...@gridgain.com> wrote:
> > >> > >
> > >> > > > Yes, when data is a stake, fail early is the absolutely the
> right
> > >> thing
> > >> > > to
> > >> > > > do.
> > >> > > >
> > >> > > > Regards,
> > >> > > > Stephen
> > >> > > >
> > >> > > > > On 12 Aug 2019, at 16:37, Ivan Rakov 
> > >> wrote:
> > >> > > > >
> > >> > > > > Hi Anton,
> > >> > > > >
> > >> > > > > Actually, the issue is even more unpleasant.
> > >> > > > >
> > >> > > > > Official Ignite documentation says that it's possible to
> > >> > > > > configure
> > >> > path
> > >> > > > where your persistence files will be stored:
> > >> > > >
> https://apacheignite.readme.io/docs/distributed-persistent-store
> > >> > > > > However, even if you have set all path options (storage, WAL,
> > WAL
> > >> > > > archive), Ignite will still store crucial metadata in resolved
> > work
> > >> > > > directory (java.io.tmpdir by default). Example is binary
> metadata
> > >> > files,
> > >> > > > absence of which can make your data unavailable.
> > >> > > > >
> > >> > > > > I propose to fail Ignite node in case neither IGNITE_HOME nor
> > >> > > > IgniteConfiguration#igniteWorkDir is set. It's better to let
> user
> > >> know
> > >> > > > about missing configuration options during startup than let OS
> > >> corrupt
> > >> > > > storage by cleaning temp dirs.
> > >> > > > >
> > >> > > > > Thoughts?
> > >> > > > >
> > >> > > > > Best Regards,
> > >> > > > > Ivan Rakov
> > >> > > > >
> > >> > > > > On 12.08.2019 18:10, Anton Kalashnikov wrote:
> > >> > > > >> Hello, Igniters.
> > >> > > > >>
> > >> > > > >> Currently, in the case, when work directory wasn't set by
> user
> > >> > ignite
> > >> > > > can resolve it to tmp directory which leads to some problem -
> tmp
> > >> > > directory
> > >> > > > can be cleared at some unexpected moment by operation system and
> > >> > > different
> > >> > > > types of critical data would be lost(ex. binary_meta,
> persistance
> > >> > data).
> > >> > > > >>
> > >> > > > >> Looks like it is not expected behaviour and maybe it is
>

Re: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[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 :
> 
> > 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 :
> > 
> > > 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-ignite-1-7-0-td7458.html
> > > 
> > > Did you check release locally?
> > > 
> > > пт, 23 авг. 2019 г. в 15:16, Nikolay Izhikov :
> > > 
> > > > Hello, Dmitriy.
> > > > 
> > > > Seems, we have some issue here.
> > > > I also run this suite and got informative error [1]. You can find it in
> > > > log:
> > > > 
> > > > ```
> > > > [15:07:05] : [Step 6/8] [Maven Watcher]
> > > > [15:07:05]E: [Step 6/8] Failed to execute goal on project
> > > 
> > > ignite-jta:
> > > > Could not resolve dependencies for project
> > > > org.apache.ignite:ignite-jta:jar:2.7.6: The following artifacts could
> > > 
> > > not be
> > > > resolved: org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018,
> > > > org.jacorb:jacorb-idl:jar:2.2.3-jonas-patch-20071018: Could not find
> > > > artifact org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 in central (
> > > > https://repo.maven.apache.org/maven2)
> > > > [15:07:05] : [Step 6/8] [Maven Watcher]
> > > > 
> > > > [15:07:05] : [Step 6/8] [INFO] ignite-aop
> > > > . SUCCESS [  2.511 s]
> > > > [15:07:05] : [Step 6/8] [INFO] ignite-ssh
> > > > . SUCCESS [  2.024 s]
> > > > [15:07:05] : [Step 6/8] [INFO] ignite-jta
> > > > . FAILURE [  0.502 s]
> > > > [15:07:05] : [Step 6/8] [INFO] ignite-aws
> > > > . SKIPPED
> > > > ```
> > > > 
> > > > [1]
> > > > 
> > > 
> > > https://ci.ignite.apache.org/viewLog.html?buildId=4530006&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv
> > > > 
> > > > В Пт, 23/08/2019 в 14:53 +0300, Dmitriy Pavlov пишет:
> > > > > My attempt was unsuccessful, please document or advice me how to use
> > > > > 
> > > 
> > > https://ci.ignite.apache.org/viewLog.html?buildId=4530004&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
> > > > > 
> > > > > 
> > > > > 
> > > > > пт, 23 авг. 2019 г. в 14:50, Dmitriy Pavlov :
> > > > > 
> > > > > > Antron,
> > > > > > 
> > > > > > it is outside of process until discussed. If I missed something
> > > 
> > > where
> > > > we
> > > > > > discussed and documented, please let me know.
> > > > > > 
> > > > > > Sorry, but one PMC member opinion about RC building process is not a
> > > > 
> > > > part
> > > > > > of the RC building process. Feel free to discuss updates with the
> > > > > > community.
> > > > > > 
> > > > > > Despite is it not yet part of RC building process, you can whatever
> > > 
> > > you
> > > > > > want 

Re: Replacing default work dir from tmp to current dir

[Nikolay Izhikov]

Hello, Igniters.

There are plenty of options to store application files in linux:

* /usr/local/ignite
* /var/ignite
* /var/lib/ignite
* ~/.ignite/
* /opt/ignite/

Seems, ~/ignite/work (without a dot in the beginning) is not a Linux-way naming.

Postgresql use '/usr/local/pgsql/`
Mysql use '/var/lib/mysql`

I, personally, like '/var/lib/ignite'.
What do you think?


> I doubt that users can attribute work/ directory in their home to Ignite,
> especially when it is used as library by something else.

I don't think we should fix this case somehow.
If some application-provider uses embedded Ignite, it must do all configuration 
stuff inside application.

Ignite should provide reasonable defaults, that's all.


В Пн, 26/08/2019 в 10:33 +0300, Pavel Tupitsyn пишет:
> I was certainly expecting ~/ignite/work too, not just ~/work
> 
> On Mon, Aug 26, 2019 at 10:19 AM Dmitriy Pavlov  wrote:
> 
> > I agree that ~/work is not expected. I was pretty sure it will be
> > ~/ignite/work or ~/.ignite/work
> > 
> > Sorry, but ~/work I may use for my day job stuff. I don't expect any files
> > appear there if I start to play with Apache Ignite for the first time.
> > 
> > Since it is a potential usability issue, which is very hard to change once
> > we release product,
> > 
> > I keep the vote open to having an option to cancel it if this discussion we
> > come to conclusion product should use ~/ignite.
> > 
> > пн, 26 авг. 2019 г. в 01:42, Павлухин Иван :
> > 
> > > Ilya,
> > > 
> > > 2 points:
> > > 1. It is a good point that a directory name "work" in arbitrary place
> > > can cause a lot of confusion.
> > > 2. As far as I got, default directory is not in e.g. /home/username
> > > but in one pointed by "user.dir" system property which is a directory
> > > where a java process started (if property was not overridden).
> > > 
> > > 2019-08-26 1:59 GMT+11:00, Ilya Kasnacheev :
> > > > Hello!
> > > > 
> > > > I am really worried by the fact that previously we had /tmp/ignite and
> > 
> > in
> > > > it work/, whereas now we're going to write to /home/username/work
> > > > 
> > > > I doubt that users can attribute work/ directory in their home to
> > 
> > Ignite,
> > > > especially when it is used as library by something else.
> > > > 
> > > > Is there a chance we could move this work dir to /home/username/ignite
> > > 
> > > with
> > > > work/ (and possibly logs/) dir in it? WDYT?
> > > > 
> > > > We could even auto-create README.TXT in this /home/username/ignite/ to
> > > > describe that it's Apache Ignite work directory and how to change it.
> > > > 
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > > 
> > > > 
> > > > пн, 12 авг. 2019 г. в 19:02, Denis Magda :
> > > > 
> > > > > +1 for the user.dir as a default one.
> > > > > 
> > > > > Denis
> > > > > 
> > > > > On Monday, August 12, 2019, Dmitriy Pavlov 
> > 
> > wrote:
> > > > > 
> > > > > > +1 to user home directory. A number of open source products create
> > > > > > their
> > > > > > dirs there. For me, it is a kind of expected behavior.
> > > > > > 
> > > > > > Ivan mentioned an important point: binary meta & marshaller. We
> > 
> > should
> > > > > > update documentation and stop require PDS dir setup, but require
> > 
> > home
> > > > > setup
> > > > > > (for older versions of Ignite, it is relevant anyway).
> > > > > > 
> > > > > > пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn :
> > > > > > 
> > > > > > > Hi Ivan,
> > > > > > > 
> > > > > > > >  fail Ignite node in case neither IGNITE_HOME
> > > > > > > 
> > > > > > > nor IgniteConfiguration#igniteWorkDir is set
> > > > > > > I strongly disagree, this is bad usability.
> > > > > > > Ignition.start() should work without any extra configuration as is
> > > 
> > > it
> > > > > > right
> > > > > > > now.
> > > > > > > 
> > > > > > > Let's come up with reasonable defaults instead, user dir sounds
> > 
> > good
> > > > > > > to
> > > > > > 
> > > > > > me.
> > > > > > > 
> > > > > > > On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
> > > > > > > stephen.darling...@gridgain.com> wrote:
> > > > > > > 
> > > > > > > > Yes, when data is a stake, fail early is the absolutely the
> > 
> > right
> > > > > thing
> > > > > > > to
> > > > > > > > do.
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Stephen
> > > > > > > > 
> > > > > > > > > On 12 Aug 2019, at 16:37, Ivan Rakov 
> > > > > 
> > > > > wrote:
> > > > > > > > > 
> > > > > > > > > Hi Anton,
> > > > > > > > > 
> > > > > > > > > Actually, the issue is even more unpleasant.
> > > > > > > > > 
> > > > > > > > > Official Ignite documentation says that it's possible to
> > > > > > > > > configure
> > > > > > 
> > > > > > path
> > > > > > > > where your persistence files will be stored:
> > > > > > > > 
> > 
> > https://apacheignite.readme.io/docs/distributed-persistent-store
> > > > > > > > > However, even if you have set all path options (storage, WAL,
> > > 
> > > WAL
> > > > > > > > archive), Ignite will still store crucial metadata in resolved
> > > 

[jira] [Created] (IGNITE-12102) idle_verify should show info about lost partitions

[Dmitriy Govorukhin (Jira)]

Dmitriy Govorukhin created IGNITE-12102:
---

 Summary: idle_verify should show info about lost partitions
 Key: IGNITE-12102
 URL: https://issues.apache.org/jira/browse/IGNITE-12102
 Project: Ignite
  Issue Type: Improvement
Reporter: Dmitriy Govorukhin


In the current implementation, idle_verify do not show lost partitions, and 
check shows that everything is fine but it is not true.



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

Re: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[Petr Ivanov]

I've made some changes that should help.

Can you rerun the build, please?


> On 23 Aug 2019, at 18:12, Alexey Goncharuk  wrote:
> 
> 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 :
> 
>> 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 :
>> 
>>> 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-ignite-1-7-0-td7458.html
>>> 
>>> Did you check release locally?
>>> 
>>> пт, 23 авг. 2019 г. в 15:16, Nikolay Izhikov :
>>> 
 Hello, Dmitriy.
 
 Seems, we have some issue here.
 I also run this suite and got informative error [1]. You can find it in
 log:
 
 ```
 [15:07:05] : [Step 6/8] [Maven Watcher]
 [15:07:05]E: [Step 6/8] Failed to execute goal on project
>>> ignite-jta:
 Could not resolve dependencies for project
 org.apache.ignite:ignite-jta:jar:2.7.6: The following artifacts could
>>> not be
 resolved: org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018,
 org.jacorb:jacorb-idl:jar:2.2.3-jonas-patch-20071018: Could not find
 artifact org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 in central (
 https://repo.maven.apache.org/maven2)
 [15:07:05] : [Step 6/8] [Maven Watcher]
 
 [15:07:05] : [Step 6/8] [INFO] ignite-aop
 . SUCCESS [  2.511 s]
 [15:07:05] : [Step 6/8] [INFO] ignite-ssh
 . SUCCESS [  2.024 s]
 [15:07:05] : [Step 6/8] [INFO] ignite-jta
 . FAILURE [  0.502 s]
 [15:07:05] : [Step 6/8] [INFO] ignite-aws
 . SKIPPED
 ```
 
 [1]
 
>>> https://ci.ignite.apache.org/viewLog.html?buildId=4530006&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv
 
 В Пт, 23/08/2019 в 14:53 +0300, Dmitriy Pavlov пишет:
> My attempt was unsuccessful, please document or advice me how to use
> 
 
>>> https://ci.ignite.apache.org/viewLog.html?buildId=4530004&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
> 
> 
> 
> пт, 23 авг. 2019 г. в 14:50, Dmitriy Pavlov :
> 
>> Antron,
>> 
>> it is outside of process until discussed. If I missed something
>>> where
 we
>> discussed and documented, please let me know.
>> 
>> Sorry, but one PMC member opinion about RC building process is not a
 part
>> of the RC building process. Feel free to discuss updates with the
>> community.
>> 
>> Despite is it not yet part of RC building process, you can whatever
>>> you
>> want as part of testing. More testing, the better the quality of the
>> release. Each maintainer is encouraged to check module he/she is
 interested
>> in.
>> 
>> Sincerely,
>> Dmitriy Pavlov
>> 
>> пт, 23 авг. 2019 г. в 14:28, Anton Vinogradov :
>> 
>>> Dmitriy,
>>> 
>>> Since the same recommendations were provided at "[VOTE] Accept
>>> Apache
>>> Ignite 2.7.5-rc3" and ... were ignored,
>>> my -1 until this becomes a part of the release process.
>>> 
>>> On Fri, Aug 23, 2019 at 1:58 PM Anton Vinogradov 
 wrote:
>>> 
 Dmitriy,
 
 I'm talking about
 
>>> 
>>> 
 
>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
 It *MUST* be checked before Vote.
 
 On Fri, Aug 23, 2019 at 1:17 PM Dmitriy Pavlov <
>>> dpav...@apache.org
> 
>>> 
>>> wrote:
 
> Which TC task should release manager run?
> 
> I see screenshots made 2 releases ago and it shows `[2]
>>> Compare
 w/
> Previous
> Release`
> 
> Also, feel free to check the whole process of release to find
 out what
> else
> can be obsolete
> 
 https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> 
> пт, 23 авг. 2019 г. в 12:22, Anton Vinogradov >>> :
> 
>> Dmitriy,
>> 
>> This task checks nothing.
>> It just compares files with previous release.
>> 
>> On Fri, Aug 23, 2019 at 12:01 PM Dmitriy Pa

Re: Replacing default work dir from tmp to current dir

[Ilya Kasnacheev]

Hello!

We are talking about development scenario where you have embedded database
in your project and it has to write data somewhere.

/var/lib/ignite is certainly not writable by user's development projects.

We could use ~/.config/ignite, which is pure UNIX way today, but I object
against potential writing of gigabytes of WAL & PDS into user's .config.
~/ignite and descendants look like a good compromise. Writing to
user.dir/ignite, i.e. current work dir, looks equally good. I will create a
ticket about it.

Regards,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 11:07, Nikolay Izhikov :

> Hello, Igniters.
>
> There are plenty of options to store application files in linux:
>
> * /usr/local/ignite
> * /var/ignite
> * /var/lib/ignite
> * ~/.ignite/
> * /opt/ignite/
>
> Seems, ~/ignite/work (without a dot in the beginning) is not a Linux-way
> naming.
>
> Postgresql use '/usr/local/pgsql/`
> Mysql use '/var/lib/mysql`
>
> I, personally, like '/var/lib/ignite'.
> What do you think?
>
>
> > I doubt that users can attribute work/ directory in their home to Ignite,
> > especially when it is used as library by something else.
>
> I don't think we should fix this case somehow.
> If some application-provider uses embedded Ignite, it must do all
> configuration stuff inside application.
>
> Ignite should provide reasonable defaults, that's all.
>
>
> В Пн, 26/08/2019 в 10:33 +0300, Pavel Tupitsyn пишет:
> > I was certainly expecting ~/ignite/work too, not just ~/work
> >
> > On Mon, Aug 26, 2019 at 10:19 AM Dmitriy Pavlov 
> wrote:
> >
> > > I agree that ~/work is not expected. I was pretty sure it will be
> > > ~/ignite/work or ~/.ignite/work
> > >
> > > Sorry, but ~/work I may use for my day job stuff. I don't expect any
> files
> > > appear there if I start to play with Apache Ignite for the first time.
> > >
> > > Since it is a potential usability issue, which is very hard to change
> once
> > > we release product,
> > >
> > > I keep the vote open to having an option to cancel it if this
> discussion we
> > > come to conclusion product should use ~/ignite.
> > >
> > > пн, 26 авг. 2019 г. в 01:42, Павлухин Иван :
> > >
> > > > Ilya,
> > > >
> > > > 2 points:
> > > > 1. It is a good point that a directory name "work" in arbitrary place
> > > > can cause a lot of confusion.
> > > > 2. As far as I got, default directory is not in e.g. /home/username
> > > > but in one pointed by "user.dir" system property which is a directory
> > > > where a java process started (if property was not overridden).
> > > >
> > > > 2019-08-26 1:59 GMT+11:00, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>:
> > > > > Hello!
> > > > >
> > > > > I am really worried by the fact that previously we had /tmp/ignite
> and
> > >
> > > in
> > > > > it work/, whereas now we're going to write to /home/username/work
> > > > >
> > > > > I doubt that users can attribute work/ directory in their home to
> > >
> > > Ignite,
> > > > > especially when it is used as library by something else.
> > > > >
> > > > > Is there a chance we could move this work dir to
> /home/username/ignite
> > > >
> > > > with
> > > > > work/ (and possibly logs/) dir in it? WDYT?
> > > > >
> > > > > We could even auto-create README.TXT in this
> /home/username/ignite/ to
> > > > > describe that it's Apache Ignite work directory and how to change
> it.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пн, 12 авг. 2019 г. в 19:02, Denis Magda :
> > > > >
> > > > > > +1 for the user.dir as a default one.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > On Monday, August 12, 2019, Dmitriy Pavlov 
> > >
> > > wrote:
> > > > > >
> > > > > > > +1 to user home directory. A number of open source products
> create
> > > > > > > their
> > > > > > > dirs there. For me, it is a kind of expected behavior.
> > > > > > >
> > > > > > > Ivan mentioned an important point: binary meta & marshaller. We
> > >
> > > should
> > > > > > > update documentation and stop require PDS dir setup, but
> require
> > >
> > > home
> > > > > > setup
> > > > > > > (for older versions of Ignite, it is relevant anyway).
> > > > > > >
> > > > > > > пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn <
> ptupit...@apache.org>:
> > > > > > >
> > > > > > > > Hi Ivan,
> > > > > > > >
> > > > > > > > >  fail Ignite node in case neither IGNITE_HOME
> > > > > > > >
> > > > > > > > nor IgniteConfiguration#igniteWorkDir is set
> > > > > > > > I strongly disagree, this is bad usability.
> > > > > > > > Ignition.start() should work without any extra configuration
> as is
> > > >
> > > > it
> > > > > > > right
> > > > > > > > now.
> > > > > > > >
> > > > > > > > Let's come up with reasonable defaults instead, user dir
> sounds
> > >
> > > good
> > > > > > > > to
> > > > > > >
> > > > > > > me.
> > > > > > > >
> > > > > > > > On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
> > > > > > > > stephen.darling...@gridgain.com> wrote:
> > > > > > > >
> > > > > > > > > Yes, when data is a 

[jira] [Created] (IGNITE-12103) Change the default ignite work directory once again to avoid writing to ~/work

[Ilya Kasnacheev (Jira)]

Ilya Kasnacheev created IGNITE-12103:


 Summary: Change the default ignite work directory once again to 
avoid writing to ~/work
 Key: IGNITE-12103
 URL: https://issues.apache.org/jira/browse/IGNITE-12103
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.7.5
Reporter: Ilya Kasnacheev
 Fix For: 2.7.6


While testing 2.7.6-RC1 it came up that we no longer write data to 
/tmp/ignite/work, which is good, but now we would instead write to 
/home/username/work, which is bad. ~/work is a generic directory not linked to 
Ignite in any obvious way, and users will be puzzled by its appearance with 
possibilities of data loss or, even worse, their own documents loss if they 
happen to have something in Work dir and it gets clobbered/removed by accident.

I suggest changing this default once more, to use either 
/home/username/ignite/{work,logs,etc} or ./ignite/{work,logs,etc} by leveraging 
user.dir property pointing to current working dir.

Please note that user.dir has its own problems since it is supposed to not be 
changeable after JVM is up, but some code still tries to change it.



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

Re: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[Ilya Kasnacheev]

Hello!

-1 (binding) for Apache Ignite 2.7.6 RC1 due to
https://issues.apache.org/jira/browse/IGNITE-12103 - let's figure out the
good default for IGNITE_WORK_DIR to avoid changing it again in future
releases.

Regards,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 11:42, Petr Ivanov :

> I've made some changes that should help.
>
> Can you rerun the build, please?
>
>
> > On 23 Aug 2019, at 18:12, Alexey Goncharuk 
> wrote:
> >
> > 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 :
> >>
> >>> 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-ignite-1-7-0-td7458.html
> >>>
> >>> Did you check release locally?
> >>>
> >>> пт, 23 авг. 2019 г. в 15:16, Nikolay Izhikov :
> >>>
>  Hello, Dmitriy.
> 
>  Seems, we have some issue here.
>  I also run this suite and got informative error [1]. You can find it
> in
>  log:
> 
>  ```
>  [15:07:05] : [Step 6/8] [Maven Watcher]
>  [15:07:05]E: [Step 6/8] Failed to execute goal on project
> >>> ignite-jta:
>  Could not resolve dependencies for project
>  org.apache.ignite:ignite-jta:jar:2.7.6: The following artifacts could
> >>> not be
>  resolved: org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018,
>  org.jacorb:jacorb-idl:jar:2.2.3-jonas-patch-20071018: Could not find
>  artifact org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 in central (
>  https://repo.maven.apache.org/maven2)
>  [15:07:05] : [Step 6/8] [Maven Watcher]
>  
>  [15:07:05] : [Step 6/8] [INFO] ignite-aop
>  . SUCCESS [  2.511 s]
>  [15:07:05] : [Step 6/8] [INFO] ignite-ssh
>  . SUCCESS [  2.024 s]
>  [15:07:05] : [Step 6/8] [INFO] ignite-jta
>  . FAILURE [  0.502 s]
>  [15:07:05] : [Step 6/8] [INFO] ignite-aws
>  . SKIPPED
>  ```
> 
>  [1]
> 
> >>>
> https://ci.ignite.apache.org/viewLog.html?buildId=4530006&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv
> 
>  В Пт, 23/08/2019 в 14:53 +0300, Dmitriy Pavlov пишет:
> > My attempt was unsuccessful, please document or advice me how to use
> >
> 
> >>>
> https://ci.ignite.apache.org/viewLog.html?buildId=4530004&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
> >
> >
> >
> > пт, 23 авг. 2019 г. в 14:50, Dmitriy Pavlov :
> >
> >> Antron,
> >>
> >> it is outside of process until discussed. If I missed something
> >>> where
>  we
> >> discussed and documented, please let me know.
> >>
> >> Sorry, but one PMC member opinion about RC building process is not a
>  part
> >> of the RC building process. Feel free to discuss updates with the
> >> community.
> >>
> >> Despite is it not yet part of RC building process, you can whatever
> >>> you
> >> want as part of testing. More testing, the better the quality of the
> >> release. Each maintainer is encouraged to check module he/she is
>  interested
> >> in.
> >>
> >> Sincerely,
> >> Dmitriy Pavlov
> >>
> >> пт, 23 авг. 2019 г. в 14:28, Anton Vinogradov :
> >>
> >>> Dmitriy,
> >>>
> >>> Since the same recommendations were provided at "[VOTE] Accept
> >>> Apache
> >>> Ignite 2.7.5-rc3" and ... were ignored,
> >>> my -1 until this becomes a part of the release process.
> >>>
> >>> On Fri, Aug 23, 2019 at 1:58 PM Anton Vinogradov 
>  wrote:
> >>>
>  Dmitriy,
> 
>  I'm talking about
> 
> >>>
> >>>
> 
> >>>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
>  It *MUST* be checked before Vote.
> 
>  On Fri, Aug 23, 2019 at 1:17 PM Dmitriy Pavlov <
> >>> dpav...@apache.org
> >
> >>>
> >>> wrote:
> 
> > Which TC task should release manager run?
> >
> > I see screenshots made 2 releases ago and it shows `[2]
> >>> 

Re: Replacing default work dir from tmp to current dir

[Nikolay Izhikov]

Ilya,

> We are talking about development scenario where you have embedded database
> in your project and it has to write data somewhere.

Why it should differs from production case?
I think we should be as close to production setup as we can.

> /var/lib/ignite is certainly not writable by user's development projects.

mysql, postgresql require some setup in dev env.
Why Ignite should differs from it?

Please, note, we are talking about scenario when user enable PDS-mode for some 
cache.
For in-memory case, no setup required.

> ~/ignite and descendants look like a good compromise

Not for me :)

> Writing to user.dir/ignite, i.e. current work dir, looks equally good

Current work dir in dev env looks good for me.


В Пн, 26/08/2019 в 12:06 +0300, Ilya Kasnacheev пишет:
> Hello!
> 
> We are talking about development scenario where you have embedded database
> in your project and it has to write data somewhere.
> 
> /var/lib/ignite is certainly not writable by user's development projects.
> 
> We could use ~/.config/ignite, which is pure UNIX way today, but I object
> against potential writing of gigabytes of WAL & PDS into user's .config.
> ~/ignite and descendants look like a good compromise. Writing to
> user.dir/ignite, i.e. current work dir, looks equally good. I will create a
> ticket about it.
> 
> Regards,


signature.asc
Description: This is a digitally signed message part

Re: Replacing default work dir from tmp to current dir

[Ilya Kasnacheev]

Hello!

In development environment one can just run Java from /var/lib/ignite
(makes total sense) and will immediately get almost correct behavior (well,
data will be stored to /var/lib/ignite/ignite/work)

However, I still think that we should write to user.dir/ignite and not just
user.dir since current directory is often crowded.

Fellows, anyone who is against using user.dir? Please share your concerns.

Regards,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 12:17, Nikolay Izhikov :

> Ilya,
>
> > We are talking about development scenario where you have embedded
> database
> > in your project and it has to write data somewhere.
>
> Why it should differs from production case?
> I think we should be as close to production setup as we can.
>
> > /var/lib/ignite is certainly not writable by user's development projects.
>
> mysql, postgresql require some setup in dev env.
> Why Ignite should differs from it?
>
> Please, note, we are talking about scenario when user enable PDS-mode for
> some cache.
> For in-memory case, no setup required.
>
> > ~/ignite and descendants look like a good compromise
>
> Not for me :)
>
> > Writing to user.dir/ignite, i.e. current work dir, looks equally good
>
> Current work dir in dev env looks good for me.
>
>
> В Пн, 26/08/2019 в 12:06 +0300, Ilya Kasnacheev пишет:
> > Hello!
> >
> > We are talking about development scenario where you have embedded
> database
> > in your project and it has to write data somewhere.
> >
> > /var/lib/ignite is certainly not writable by user's development projects.
> >
> > We could use ~/.config/ignite, which is pure UNIX way today, but I object
> > against potential writing of gigabytes of WAL & PDS into user's .config.
> > ~/ignite and descendants look like a good compromise. Writing to
> > user.dir/ignite, i.e. current work dir, looks equally good. I will
> create a
> > ticket about it.
> >
> > Regards,
>

Re: Thin client: transactions support

[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: Thin client: transactions support

[Ilya Kasnacheev]

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

[Nikolay Izhikov]

Ilya, 

> In development environment one can just run Java from /var/lib/ignite

Actually, I doesn't understand you.
Are you talking about development of some application that uses Ignite or 
contribution to Ignite code base?

If we are talking about some application that uses Ignite then we should 
decide, which scenario is primary.
(One more time, we are talking about PDS enabled caches):

1. Ignite server node started as separate java process.
2. Ignite server node embedded in application as a library.

I think, for PDS enabled cashes first case is primary.
In that case, user should install Ignite via some package(deb, rpm, docker, 
etc).
This package should done all required configuration.
Including directory permissions.

This should be done like other DBMS do.

If we are talking about embedded Ignite then we can ask the user to provide 
sufficient permission for default dir or change dir to some other.

So, I still think we should use /var/lig/ignite for PDS data.

How it sounds?

В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> Hello!
> 
> In development environment one can just run Java from /var/lib/ignite
> (makes total sense) and will immediately get almost correct behavior (well,
> data will be stored to /var/lib/ignite/ignite/work)
> 
> However, I still think that we should write to user.dir/ignite and not just
> user.dir since current directory is often crowded.
> 
> Fellows, anyone who is against using user.dir? Please share your concerns.
> 
> Regards,


signature.asc
Description: This is a digitally signed message part

Re: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[Dmitriy Pavlov]

Ilya, please cast your vote in the formal vote thread
https://lists.apache.org/thread.html/dab6624041507ddebe8b2d5fffdaff13bbe52d1fb481ac0d702cb4f1@%3Cdev.ignite.apache.org%3E


пн, 26 авг. 2019 г. в 12:12, Ilya Kasnacheev :

> Hello!
>
> -1 (binding) for Apache Ignite 2.7.6 RC1 due to
> https://issues.apache.org/jira/browse/IGNITE-12103 - let's figure out the
> good default for IGNITE_WORK_DIR to avoid changing it again in future
> releases.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 26 авг. 2019 г. в 11:42, Petr Ivanov :
>
> > I've made some changes that should help.
> >
> > Can you rerun the build, please?
> >
> >
> > > On 23 Aug 2019, at 18:12, Alexey Goncharuk  >
> > wrote:
> > >
> > > 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 :
> > >>
> > >>> 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-ignite-1-7-0-td7458.html
> > >>>
> > >>> Did you check release locally?
> > >>>
> > >>> пт, 23 авг. 2019 г. в 15:16, Nikolay Izhikov :
> > >>>
> >  Hello, Dmitriy.
> > 
> >  Seems, we have some issue here.
> >  I also run this suite and got informative error [1]. You can find it
> > in
> >  log:
> > 
> >  ```
> >  [15:07:05] : [Step 6/8] [Maven Watcher]
> >  [15:07:05]E: [Step 6/8] Failed to execute goal on project
> > >>> ignite-jta:
> >  Could not resolve dependencies for project
> >  org.apache.ignite:ignite-jta:jar:2.7.6: The following artifacts
> could
> > >>> not be
> >  resolved: org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018,
> >  org.jacorb:jacorb-idl:jar:2.2.3-jonas-patch-20071018: Could not find
> >  artifact org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 in
> central (
> >  https://repo.maven.apache.org/maven2)
> >  [15:07:05] : [Step 6/8] [Maven Watcher]
> >  
> >  [15:07:05] : [Step 6/8] [INFO] ignite-aop
> >  . SUCCESS [  2.511 s]
> >  [15:07:05] : [Step 6/8] [INFO] ignite-ssh
> >  . SUCCESS [  2.024 s]
> >  [15:07:05] : [Step 6/8] [INFO] ignite-jta
> >  . FAILURE [  0.502 s]
> >  [15:07:05] : [Step 6/8] [INFO] ignite-aws
> >  . SKIPPED
> >  ```
> > 
> >  [1]
> > 
> > >>>
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=4530006&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv
> > 
> >  В Пт, 23/08/2019 в 14:53 +0300, Dmitriy Pavlov пишет:
> > > My attempt was unsuccessful, please document or advice me how to
> use
> > >
> > 
> > >>>
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=4530004&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
> > >
> > >
> > >
> > > пт, 23 авг. 2019 г. в 14:50, Dmitriy Pavlov :
> > >
> > >> Antron,
> > >>
> > >> it is outside of process until discussed. If I missed something
> > >>> where
> >  we
> > >> discussed and documented, please let me know.
> > >>
> > >> Sorry, but one PMC member opinion about RC building process is
> not a
> >  part
> > >> of the RC building process. Feel free to discuss updates with the
> > >> community.
> > >>
> > >> Despite is it not yet part of RC building process, you can
> whatever
> > >>> you
> > >> want as part of testing. More testing, the better the quality of
> the
> > >> release. Each maintainer is encouraged to check module he/she is
> >  interested
> > >> in.
> > >>
> > >> Sincerely,
> > >> Dmitriy Pavlov
> > >>
> > >> пт, 23 авг. 2019 г. в 14:28, Anton Vinogradov :
> > >>
> > >>> Dmitriy,
> > >>>
> > >>> Since the same recommendations were provided at "[VOTE] Accept
> > >>> Apache
> > >>> Ignite 2.7.5-rc3" and ... were ignored,
> > >>> my -1 until this becomes a part of the release process.
> > >>>
> > >>> On Fri, Aug 23, 2019 at 1:58 PM Anton Vinogradov 
> >  wrote:
> > >>>
> >  Dmitriy,
> > >>>

Re: Replacing default work dir from tmp to current dir

[Anton Kalashnikov]

Hello, Igniters.

There are a lot of variants was already proposed lets vote to one of them. I 
made a list of possible paths which was mentioned earlier. I also included 
variants outside of home directory('user.dir') to this list but I want to notes 
that we had already discussed it and we decided to choose some path in home 
directory rather outside of that. Also If you have any other variants feel free 
to add it.

1) ~/.ignite/work
2) ~/ignite/work
3) ~/.config/ignite/work

4)/var/lib/ignite
5)/usr/local/ignite
6)/var/ignite
7)/var/lib/ignite
8)/opt/ignite/

+1 for '~/.ignite/work'

-- 
Best regards,
Anton Kalashnikov


26.08.2019, 12:39, "Nikolay Izhikov" :
> Ilya,
>
>>  In development environment one can just run Java from /var/lib/ignite
>
> Actually, I doesn't understand you.
> Are you talking about development of some application that uses Ignite or 
> contribution to Ignite code base?
>
> If we are talking about some application that uses Ignite then we should 
> decide, which scenario is primary.
> (One more time, we are talking about PDS enabled caches):
>
> 1. Ignite server node started as separate java process.
> 2. Ignite server node embedded in application as a library.
>
> I think, for PDS enabled cashes first case is primary.
> In that case, user should install Ignite via some package(deb, rpm, docker, 
> etc).
> This package should done all required configuration.
> Including directory permissions.
>
> This should be done like other DBMS do.
>
> If we are talking about embedded Ignite then we can ask the user to provide 
> sufficient permission for default dir or change dir to some other.
>
> So, I still think we should use /var/lig/ignite for PDS data.
>
> How it sounds?
>
> В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
>>  Hello!
>>
>>  In development environment one can just run Java from /var/lib/ignite
>>  (makes total sense) and will immediately get almost correct behavior (well,
>>  data will be stored to /var/lib/ignite/ignite/work)
>>
>>  However, I still think that we should write to user.dir/ignite and not just
>>  user.dir since current directory is often crowded.
>>
>>  Fellows, anyone who is against using user.dir? Please share your concerns.
>>
>>  Regards,

Re: Replacing default work dir from tmp to current dir

[Dmitriy Pavlov]

+1 for '~/.ignite/work'

пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :

> Hello, Igniters.
>
> There are a lot of variants was already proposed lets vote to one of them.
> I made a list of possible paths which was mentioned earlier. I also
> included variants outside of home directory('user.dir') to this list but I
> want to notes that we had already discussed it and we decided to choose
> some path in home directory rather outside of that. Also If you have any
> other variants feel free to add it.
>
> 1) ~/.ignite/work
> 2) ~/ignite/work
> 3) ~/.config/ignite/work
>
> 4)/var/lib/ignite
> 5)/usr/local/ignite
> 6)/var/ignite
> 7)/var/lib/ignite
> 8)/opt/ignite/
>
> +1 for '~/.ignite/work'
>
> --
> Best regards,
> Anton Kalashnikov
>
>
> 26.08.2019, 12:39, "Nikolay Izhikov" :
> > Ilya,
> >
> >>  In development environment one can just run Java from /var/lib/ignite
> >
> > Actually, I doesn't understand you.
> > Are you talking about development of some application that uses Ignite
> or contribution to Ignite code base?
> >
> > If we are talking about some application that uses Ignite then we should
> decide, which scenario is primary.
> > (One more time, we are talking about PDS enabled caches):
> >
> > 1. Ignite server node started as separate java process.
> > 2. Ignite server node embedded in application as a library.
> >
> > I think, for PDS enabled cashes first case is primary.
> > In that case, user should install Ignite via some package(deb, rpm,
> docker, etc).
> > This package should done all required configuration.
> > Including directory permissions.
> >
> > This should be done like other DBMS do.
> >
> > If we are talking about embedded Ignite then we can ask the user to
> provide sufficient permission for default dir or change dir to some other.
> >
> > So, I still think we should use /var/lig/ignite for PDS data.
> >
> > How it sounds?
> >
> > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> >>  Hello!
> >>
> >>  In development environment one can just run Java from /var/lib/ignite
> >>  (makes total sense) and will immediately get almost correct behavior
> (well,
> >>  data will be stored to /var/lib/ignite/ignite/work)
> >>
> >>  However, I still think that we should write to user.dir/ignite and not
> just
> >>  user.dir since current directory is often crowded.
> >>
> >>  Fellows, anyone who is against using user.dir? Please share your
> concerns.
> >>
> >>  Regards,
>
>

[RESULT] [Vote] Release Apache Ignite 2.7.6-rc1 [Cancelled]

[Dmitriy Pavlov]

The vote is canceled now.

Motivation:
I appreciate everyone's attention to the latest release candidate. I really
happy we were so active in voting.

Unfortunately, I really concerned about
https://issues.apache.org/jira/browse/IGNITE-12103 and I believe we should
revisit default '~/work' to show it is Ignite work (no just some work).

In addition, I saw how control.sh is used by Ignite committers and PMCs and
it seems it has a couple of usability issues. I'll start discussions about
these issues soon.

I use my ultimate right to cancel vote if there are major issues with RC.

Since I will be traveling with limited access to the internet, the next
vote may be started by another PMC member.

Re: Replacing default work dir from tmp to current dir

[Ilya Kasnacheev]

Hello!

> In development environment one can just run Java from /var/lib/ignite

What I actually meant was 'in deployment environment' or even 'in
production environment'. Sorry for the confusion.

I really dislike the idea of ~/.ignite/work. It is a good default for
in-memory runs, but storing gigabytes of sensitive data in a hidden
directory is a Bad Idea in my opinion.

I now side with user.dir.

Regards,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 13:28, Dmitriy Pavlov :

> +1 for '~/.ignite/work'
>
> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
>
> > Hello, Igniters.
> >
> > There are a lot of variants was already proposed lets vote to one of
> them.
> > I made a list of possible paths which was mentioned earlier. I also
> > included variants outside of home directory('user.dir') to this list but
> I
> > want to notes that we had already discussed it and we decided to choose
> > some path in home directory rather outside of that. Also If you have any
> > other variants feel free to add it.
> >
> > 1) ~/.ignite/work
> > 2) ~/ignite/work
> > 3) ~/.config/ignite/work
> >
> > 4)/var/lib/ignite
> > 5)/usr/local/ignite
> > 6)/var/ignite
> > 7)/var/lib/ignite
> > 8)/opt/ignite/
> >
> > +1 for '~/.ignite/work'
> >
> > --
> > Best regards,
> > Anton Kalashnikov
> >
> >
> > 26.08.2019, 12:39, "Nikolay Izhikov" :
> > > Ilya,
> > >
> > >>  In development environment one can just run Java from /var/lib/ignite
> > >
> > > Actually, I doesn't understand you.
> > > Are you talking about development of some application that uses Ignite
> > or contribution to Ignite code base?
> > >
> > > If we are talking about some application that uses Ignite then we
> should
> > decide, which scenario is primary.
> > > (One more time, we are talking about PDS enabled caches):
> > >
> > > 1. Ignite server node started as separate java process.
> > > 2. Ignite server node embedded in application as a library.
> > >
> > > I think, for PDS enabled cashes first case is primary.
> > > In that case, user should install Ignite via some package(deb, rpm,
> > docker, etc).
> > > This package should done all required configuration.
> > > Including directory permissions.
> > >
> > > This should be done like other DBMS do.
> > >
> > > If we are talking about embedded Ignite then we can ask the user to
> > provide sufficient permission for default dir or change dir to some
> other.
> > >
> > > So, I still think we should use /var/lig/ignite for PDS data.
> > >
> > > How it sounds?
> > >
> > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > >>  Hello!
> > >>
> > >>  In development environment one can just run Java from /var/lib/ignite
> > >>  (makes total sense) and will immediately get almost correct behavior
> > (well,
> > >>  data will be stored to /var/lib/ignite/ignite/work)
> > >>
> > >>  However, I still think that we should write to user.dir/ignite and
> not
> > just
> > >>  user.dir since current directory is often crowded.
> > >>
> > >>  Fellows, anyone who is against using user.dir? Please share your
> > concerns.
> > >>
> > >>  Regards,
> >
> >
>

Re: Replacing default work dir from tmp to current dir

[Nikolay Izhikov]

+1 for '/var/lib/ignite'

В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> +1 for '~/.ignite/work'
> 
> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
> 
> > Hello, Igniters.
> > 
> > There are a lot of variants was already proposed lets vote to one of them.
> > I made a list of possible paths which was mentioned earlier. I also
> > included variants outside of home directory('user.dir') to this list but I
> > want to notes that we had already discussed it and we decided to choose
> > some path in home directory rather outside of that. Also If you have any
> > other variants feel free to add it.
> > 
> > 1) ~/.ignite/work
> > 2) ~/ignite/work
> > 3) ~/.config/ignite/work
> > 
> > 4)/var/lib/ignite
> > 5)/usr/local/ignite
> > 6)/var/ignite
> > 7)/var/lib/ignite
> > 8)/opt/ignite/
> > 
> > +1 for '~/.ignite/work'
> > 
> > --
> > Best regards,
> > Anton Kalashnikov
> > 
> > 
> > 26.08.2019, 12:39, "Nikolay Izhikov" :
> > > Ilya,
> > > 
> > > >  In development environment one can just run Java from /var/lib/ignite
> > > 
> > > Actually, I doesn't understand you.
> > > Are you talking about development of some application that uses Ignite
> > 
> > or contribution to Ignite code base?
> > > 
> > > If we are talking about some application that uses Ignite then we should
> > 
> > decide, which scenario is primary.
> > > (One more time, we are talking about PDS enabled caches):
> > > 
> > > 1. Ignite server node started as separate java process.
> > > 2. Ignite server node embedded in application as a library.
> > > 
> > > I think, for PDS enabled cashes first case is primary.
> > > In that case, user should install Ignite via some package(deb, rpm,
> > 
> > docker, etc).
> > > This package should done all required configuration.
> > > Including directory permissions.
> > > 
> > > This should be done like other DBMS do.
> > > 
> > > If we are talking about embedded Ignite then we can ask the user to
> > 
> > provide sufficient permission for default dir or change dir to some other.
> > > 
> > > So, I still think we should use /var/lig/ignite for PDS data.
> > > 
> > > How it sounds?
> > > 
> > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > >  Hello!
> > > > 
> > > >  In development environment one can just run Java from /var/lib/ignite
> > > >  (makes total sense) and will immediately get almost correct behavior
> > 
> > (well,
> > > >  data will be stored to /var/lib/ignite/ignite/work)
> > > > 
> > > >  However, I still think that we should write to user.dir/ignite and not
> > 
> > just
> > > >  user.dir since current directory is often crowded.
> > > > 
> > > >  Fellows, anyone who is against using user.dir? Please share your
> > 
> > concerns.
> > > > 
> > > >  Regards,
> > 
> > 


signature.asc
Description: This is a digitally signed message part

Re: Replacing default work dir from tmp to current dir

[Petr Ivanov]

Does this parameters intended to be overridden (for tests purposes for example) 
or it will be permanently sticked to this new directory without ability to 
change?


> On 26 Aug 2019, at 13:58, Nikolay Izhikov  wrote:
> 
> +1 for '/var/lib/ignite'
> 
> В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
>> +1 for '~/.ignite/work'
>> 
>> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
>> 
>>> Hello, Igniters.
>>> 
>>> There are a lot of variants was already proposed lets vote to one of them.
>>> I made a list of possible paths which was mentioned earlier. I also
>>> included variants outside of home directory('user.dir') to this list but I
>>> want to notes that we had already discussed it and we decided to choose
>>> some path in home directory rather outside of that. Also If you have any
>>> other variants feel free to add it.
>>> 
>>> 1) ~/.ignite/work
>>> 2) ~/ignite/work
>>> 3) ~/.config/ignite/work
>>> 
>>> 4)/var/lib/ignite
>>> 5)/usr/local/ignite
>>> 6)/var/ignite
>>> 7)/var/lib/ignite
>>> 8)/opt/ignite/
>>> 
>>> +1 for '~/.ignite/work'
>>> 
>>> --
>>> Best regards,
>>> Anton Kalashnikov
>>> 
>>> 
>>> 26.08.2019, 12:39, "Nikolay Izhikov" :
 Ilya,
 
> In development environment one can just run Java from /var/lib/ignite
 
 Actually, I doesn't understand you.
 Are you talking about development of some application that uses Ignite
>>> 
>>> or contribution to Ignite code base?
 
 If we are talking about some application that uses Ignite then we should
>>> 
>>> decide, which scenario is primary.
 (One more time, we are talking about PDS enabled caches):
 
 1. Ignite server node started as separate java process.
 2. Ignite server node embedded in application as a library.
 
 I think, for PDS enabled cashes first case is primary.
 In that case, user should install Ignite via some package(deb, rpm,
>>> 
>>> docker, etc).
 This package should done all required configuration.
 Including directory permissions.
 
 This should be done like other DBMS do.
 
 If we are talking about embedded Ignite then we can ask the user to
>>> 
>>> provide sufficient permission for default dir or change dir to some other.
 
 So, I still think we should use /var/lig/ignite for PDS data.
 
 How it sounds?
 
 В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> Hello!
> 
> In development environment one can just run Java from /var/lib/ignite
> (makes total sense) and will immediately get almost correct behavior
>>> 
>>> (well,
> data will be stored to /var/lib/ignite/ignite/work)
> 
> However, I still think that we should write to user.dir/ignite and not
>>> 
>>> just
> user.dir since current directory is often crowded.
> 
> Fellows, anyone who is against using user.dir? Please share your
>>> 
>>> concerns.
> 
> Regards,
>>> 
>>> 

Re: Replacing default work dir from tmp to current dir

[Nikolay Izhikov]

Yes, of course.

В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:
> Does this parameters intended to be overridden (for tests purposes for 
> example) or it will be permanently sticked to this new directory without 
> ability to change?
> 
> 
> > On 26 Aug 2019, at 13:58, Nikolay Izhikov  wrote:
> > 
> > +1 for '/var/lib/ignite'
> > 
> > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > +1 for '~/.ignite/work'
> > > 
> > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
> > > 
> > > > Hello, Igniters.
> > > > 
> > > > There are a lot of variants was already proposed lets vote to one of 
> > > > them.
> > > > I made a list of possible paths which was mentioned earlier. I also
> > > > included variants outside of home directory('user.dir') to this list 
> > > > but I
> > > > want to notes that we had already discussed it and we decided to choose
> > > > some path in home directory rather outside of that. Also If you have any
> > > > other variants feel free to add it.
> > > > 
> > > > 1) ~/.ignite/work
> > > > 2) ~/ignite/work
> > > > 3) ~/.config/ignite/work
> > > > 
> > > > 4)/var/lib/ignite
> > > > 5)/usr/local/ignite
> > > > 6)/var/ignite
> > > > 7)/var/lib/ignite
> > > > 8)/opt/ignite/
> > > > 
> > > > +1 for '~/.ignite/work'
> > > > 
> > > > --
> > > > Best regards,
> > > > Anton Kalashnikov
> > > > 
> > > > 
> > > > 26.08.2019, 12:39, "Nikolay Izhikov" :
> > > > > Ilya,
> > > > > 
> > > > > > In development environment one can just run Java from 
> > > > > > /var/lib/ignite
> > > > > 
> > > > > Actually, I doesn't understand you.
> > > > > Are you talking about development of some application that uses Ignite
> > > > 
> > > > or contribution to Ignite code base?
> > > > > 
> > > > > If we are talking about some application that uses Ignite then we 
> > > > > should
> > > > 
> > > > decide, which scenario is primary.
> > > > > (One more time, we are talking about PDS enabled caches):
> > > > > 
> > > > > 1. Ignite server node started as separate java process.
> > > > > 2. Ignite server node embedded in application as a library.
> > > > > 
> > > > > I think, for PDS enabled cashes first case is primary.
> > > > > In that case, user should install Ignite via some package(deb, rpm,
> > > > 
> > > > docker, etc).
> > > > > This package should done all required configuration.
> > > > > Including directory permissions.
> > > > > 
> > > > > This should be done like other DBMS do.
> > > > > 
> > > > > If we are talking about embedded Ignite then we can ask the user to
> > > > 
> > > > provide sufficient permission for default dir or change dir to some 
> > > > other.
> > > > > 
> > > > > So, I still think we should use /var/lig/ignite for PDS data.
> > > > > 
> > > > > How it sounds?
> > > > > 
> > > > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > > > > Hello!
> > > > > > 
> > > > > > In development environment one can just run Java from 
> > > > > > /var/lib/ignite
> > > > > > (makes total sense) and will immediately get almost correct behavior
> > > > 
> > > > (well,
> > > > > > data will be stored to /var/lib/ignite/ignite/work)
> > > > > > 
> > > > > > However, I still think that we should write to user.dir/ignite and 
> > > > > > not
> > > > 
> > > > just
> > > > > > user.dir since current directory is often crowded.
> > > > > > 
> > > > > > Fellows, anyone who is against using user.dir? Please share your
> > > > 
> > > > concerns.
> > > > > > 
> > > > > > Regards,
> > > > 
> > > > 
> 
> 


signature.asc
Description: This is a digitally signed message part

Re: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[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 :
> > >
> > > > 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-ignite-1-7-0-td7458.html
> > > >
> > > > Did you check release locally?
> > > >
> > > > пт, 23 авг. 2019 г. в 15:16, Nikolay Izhikov :
> > > >
> > > > > Hello, Dmitriy.
> > > > >
> > > > > Seems, we have some issue here.
> > > > > I also run this suite and got informative error [1]. You can find
> it in
> > > > > log:
> > > > >
> > > > > ```
> > > > > [15:07:05] : [Step 6/8] [Maven Watcher]
> > > > > [15:07:05]E: [Step 6/8] Failed to execute goal on project
> > > >
> > > > ignite-jta:
> > > > > Could not resolve dependencies for project
> > > > > org.apache.ignite:ignite-jta:jar:2.7.6: The following artifacts
> could
> > > >
> > > > not be
> > > > > resolved: org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018,
> > > > > org.jacorb:jacorb-idl:jar:2.2.3-jonas-patch-20071018: Could not
> find
> > > > > artifact org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 in
> central (
> > > > > https://repo.maven.apache.org/maven2)
> > > > > [15:07:05] : [Step 6/8] [Maven Watcher]
> > > > > 
> > > > > [15:07:05] : [Step 6/8] [INFO] ignite-aop
> > > > > . SUCCESS [  2.511 s]
> > > > > [15:07:05] : [Step 6/8] [INFO] ignite-ssh
> > > > > . SUCCESS [  2.024 s]
> > > > > [15:07:05] : [Step 6/8] [INFO] ignite-jta
> > > > > . FAILURE [  0.502 s]
> > > > > [15:07:05] : [Step 6/8] [INFO] ignite-aws
> > > > > . SKIPPED
> > > > > ```
> > > > >
> > > > > [1]
> > > > >
> > > >
> > > >
> https://ci.ignite.apache.org/viewLog.html?buildId=4530006&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv
> > > > >
> > > > > В Пт, 23/08/2019 в 14:53 +0300, Dmitriy Pavlov пишет:
> > > > > > My attempt was unsuccessful, please document or advice me how to
> use
> > > > > >
> > > >
> > > >
> https://ci.ignite.apache.org/viewLog.html?buildId=4530004&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
> > > > > >
> > > > > >

Re: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[Dmitriy Pavlov]

Hi Petr,

Thank you. now build is passing
https://ci.ignite.apache.org/viewLog.html?buildId=4537955&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum

Sincerely,
Dmitriy Pavlov

пн, 26 авг. 2019 г. в 14:03, 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 :
>> > >
>> > > > 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-ignite-1-7-0-td7458.html
>> > > >
>> > > > Did you check release locally?
>> > > >
>> > > > пт, 23 авг. 2019 г. в 15:16, Nikolay Izhikov :
>> > > >
>> > > > > Hello, Dmitriy.
>> > > > >
>> > > > > Seems, we have some issue here.
>> > > > > I also run this suite and got informative error [1]. You can find
>> it in
>> > > > > log:
>> > > > >
>> > > > > ```
>> > > > > [15:07:05] : [Step 6/8] [Maven Watcher]
>> > > > > [15:07:05]E: [Step 6/8] Failed to execute goal on project
>> > > >
>> > > > ignite-jta:
>> > > > > Could not resolve dependencies for project
>> > > > > org.apache.ignite:ignite-jta:jar:2.7.6: The following artifacts
>> could
>> > > >
>> > > > not be
>> > > > > resolved: org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018,
>> > > > > org.jacorb:jacorb-idl:jar:2.2.3-jonas-patch-20071018: Could not
>> find
>> > > > > artifact org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 in
>> central (
>> > > > > https://repo.maven.apache.org/maven2)
>> > > > > [15:07:05] : [Step 6/8] [Maven Watcher]
>> > > > > 
>> > > > > [15:07:05] : [Step 6/8] [INFO] ignite-aop
>> > > > > . SUCCESS [  2.511 s]
>> > > > > [15:07:05] : [Step 6/8] [INFO] ignite-ssh
>> > > > > . SUCCESS [  2.024 s]
>> > > > > [15:07:05] : [Step 6/8] [INFO] ignite-jta
>> > > > > . FAILURE [  0.502 s]
>> > > > > [15:07:05] : [Step 6/8] [INFO] ignite-aws
>> > > > > . SKIPPED
>> > > > > ```
>> > > > >
>> > > > > [1]
>> > > > >
>> > > >
>> > > >
>> https://ci.ignite.apache.org/viewLog.html?buildId=4530006&buildTypeId=ApacheIgniteReleaseJava8_PrepareV

Re: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[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 :
> > > > 
> > > > > 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-ignite-1-7-0-td7458.html
> > > > > 
> > > > > Did you check release locally?
> > > > > 
> > > > > пт, 23 авг. 2019 г. в 15:16, Nikolay Izhikov :
> > > > > 
> > > > > > Hello, Dmitriy.
> > > > > > 
> > > > > > Seems, we have some issue here.
> > > > > > I also run this suite and got informative error [1]. You can find
> > 
> > it in
> > > > > > log:
> > > > > > 
> > > > > > ```
> > > > > > [15:07:05] : [Step 6/8] [Maven Watcher]
> > > > > > [15:07:05]E: [Step 6/8] Failed to execute goal on project
> > > > > 
> > > > > ignite-jta:
> > > > > > Could not resolve dependencies for project
> > > > > > org.apache.ignite:ignite-jta:jar:2.7.6: The following artifacts
> > 
> > could
> > > > > 
> > > > > not be
> > > > > > resolved: org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018,
> > > > > > org.jacorb:jacorb-idl:jar:2.2.3-jonas-patch-20071018: Could not
> > 
> > find
> > > > > > artifact org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 in
> > 
> > central (
> > > > > > https://repo.maven.apache.org/maven2)
> > > > > > [15:07:05] : [Step 6/8] [Maven Watcher]
> > > > > > 
> > > > > > [15:07:05] : [Step 6/8] [INFO] ignite-aop
> > > > > > . SUCCESS [  2.511 s]
> > > > > > [15:07:05] : [Step 6/8] [INFO] ignite-ssh
> > > > > > . SUCCESS [  2.024 s]
> > > > > > [15:07:05] : [Step 6/8] [INFO] ignite-jta
> > > > > > . FAILURE [  0.502 s]
> > > > > > [15:07:05] : [Step 6/8] [INFO] ignite-aws
> > > > > > ..

Re: Thin client: transactions support

[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 
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: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[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 :
> > > > >
> > > > > > 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-ignite-1-7-0-td7458.html
> > > > > >
> > > > > > Did you check release locally?
> > > > > >
> > > > > > пт, 23 авг. 2019 г. в 15:16, Nikolay Izhikov <
> nizhi...@apache.org>:
> > > > > >
> > > > > > > Hello, Dmitriy.
> > > > > > >
> > > > > > > Seems, we have some issue here.
> > > > > > > I also run this suite and got informative error [1]. You can
> find
> > >
> > > it in
> > > > > > > log:
> > > > > > >
> > > > > > > ```
> > > > > > > [15:07:05] : [Step 6/8] [Maven Watcher]
> > > > > > > [15:07:05]E: [Step 6/8] Failed to execute goal on project
> > > > > >
> > > > > > ignite-jta:
> > > > > > > Could not resolve dependencies for project
> > > > > > > org.apache.ignite:ignite-jta:jar:2.7.6: The following artifacts
> > >
> > > could
> > > > > >
> > > > > > not be
> > > > > > > resolved: org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018,
> > > > > > > org.jacorb:jacorb-idl:jar:2.2.3-jonas-patch-20071018: Could not
> > >
> > > find
> > > > > > > artifact org.jacorb:jacorb:jar:2.2.3-jonas-patch-20071018 in
> > >
> > > central (
> > > > > > > https://repo.maven.apache.org/maven2)
> > > > > > > [15:07:05] : [Step 6/8] [Maven Watcher]
> > > > > > > ...

Re: [DISCUSSION] Release Apache Ignite 2.7.6-rc1

[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 :
> > > > > > 
> > > > > > > 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-ignite-1-7-0-td7458.html
> > > > > > > 
> > > > > > > Did you check release locally?
> > > > > > > 
> > > > > > > пт, 23 авг. 2019 г. в 15:16, Nikolay Izhikov <
> > 
> > nizhi...@apache.org>:
> > > > > > > 
> > > > > > > > Hello, Dmitriy.
> > > > > > > > 
> > > > > > > > Seems, we have some issue here.
> > > > > > > > I also run this suite and got informative error [1]. You can
> > 
> > find
> > > > 
> > > > it in
> > > > > > > > log:
> > > > > > > > 
> > > > > > > > ```
> > > > > > > > [15:07:05] : [Step 6/8] [Maven Watcher]
> > > > > > > > [15:07:05]E: [Step 6/8] Failed to execute goal on project
> > > > > > > 
> > > > > > > ignite-jta:
> > > > > > > > Could not resolve dependencies for project
> > > > > > > > org.apache.ignite:ignite-jta:jar:2.7.6: Th

Re: Replacing default work dir from tmp to current dir

[Maxim Muzafarov]

Folks,

According to the Filesystem Hierarchy Standard [1] (Wikipedia is not
the ideal reference), the `/var/lib` directory is the `state
information. Persistent data modified by programs as they run, e.g.,
databases, packaging system metadata, etc.`

So, I'm +1 for `/var/lib/ignite` to place persisted Ignite files there.

[1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

On Mon, 26 Aug 2019 at 14:00, Nikolay Izhikov  wrote:
>
> Yes, of course.
>
> В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:
> > Does this parameters intended to be overridden (for tests purposes for 
> > example) or it will be permanently sticked to this new directory without 
> > ability to change?
> >
> >
> > > On 26 Aug 2019, at 13:58, Nikolay Izhikov  wrote:
> > >
> > > +1 for '/var/lib/ignite'
> > >
> > > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > > +1 for '~/.ignite/work'
> > > >
> > > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov :
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > There are a lot of variants was already proposed lets vote to one of 
> > > > > them.
> > > > > I made a list of possible paths which was mentioned earlier. I also
> > > > > included variants outside of home directory('user.dir') to this list 
> > > > > but I
> > > > > want to notes that we had already discussed it and we decided to 
> > > > > choose
> > > > > some path in home directory rather outside of that. Also If you have 
> > > > > any
> > > > > other variants feel free to add it.
> > > > >
> > > > > 1) ~/.ignite/work
> > > > > 2) ~/ignite/work
> > > > > 3) ~/.config/ignite/work
> > > > >
> > > > > 4)/var/lib/ignite
> > > > > 5)/usr/local/ignite
> > > > > 6)/var/ignite
> > > > > 7)/var/lib/ignite
> > > > > 8)/opt/ignite/
> > > > >
> > > > > +1 for '~/.ignite/work'
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Anton Kalashnikov
> > > > >
> > > > >
> > > > > 26.08.2019, 12:39, "Nikolay Izhikov" :
> > > > > > Ilya,
> > > > > >
> > > > > > > In development environment one can just run Java from 
> > > > > > > /var/lib/ignite
> > > > > >
> > > > > > Actually, I doesn't understand you.
> > > > > > Are you talking about development of some application that uses 
> > > > > > Ignite
> > > > >
> > > > > or contribution to Ignite code base?
> > > > > >
> > > > > > If we are talking about some application that uses Ignite then we 
> > > > > > should
> > > > >
> > > > > decide, which scenario is primary.
> > > > > > (One more time, we are talking about PDS enabled caches):
> > > > > >
> > > > > > 1. Ignite server node started as separate java process.
> > > > > > 2. Ignite server node embedded in application as a library.
> > > > > >
> > > > > > I think, for PDS enabled cashes first case is primary.
> > > > > > In that case, user should install Ignite via some package(deb, rpm,
> > > > >
> > > > > docker, etc).
> > > > > > This package should done all required configuration.
> > > > > > Including directory permissions.
> > > > > >
> > > > > > This should be done like other DBMS do.
> > > > > >
> > > > > > If we are talking about embedded Ignite then we can ask the user to
> > > > >
> > > > > provide sufficient permission for default dir or change dir to some 
> > > > > other.
> > > > > >
> > > > > > So, I still think we should use /var/lig/ignite for PDS data.
> > > > > >
> > > > > > How it sounds?
> > > > > >
> > > > > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > > > > > Hello!
> > > > > > >
> > > > > > > In development environment one can just run Java from 
> > > > > > > /var/lib/ignite
> > > > > > > (makes total sense) and will immediately get almost correct 
> > > > > > > behavior
> > > > >
> > > > > (well,
> > > > > > > data will be stored to /var/lib/ignite/ignite/work)
> > > > > > >
> > > > > > > However, I still think that we should write to user.dir/ignite 
> > > > > > > and not
> > > > >
> > > > > just
> > > > > > > user.dir since current directory is often crowded.
> > > > > > >
> > > > > > > Fellows, anyone who is against using user.dir? Please share your
> > > > >
> > > > > concerns.
> > > > > > >
> > > > > > > Regards,
> > > > >
> > > > >
> >
> >

Re: Replacing default work dir from tmp to current dir

[Dmitriy Pavlov]

Ok, folks, I'm not insisting on
~/ignite/work nor ~/.ignite/work

I wondering what about Windows systems. Linux is not only one platform
Ignite runs on.

пн, 26 авг. 2019 г. в 14:28, Maxim Muzafarov :

> Folks,
>
> According to the Filesystem Hierarchy Standard [1] (Wikipedia is not
> the ideal reference), the `/var/lib` directory is the `state
> information. Persistent data modified by programs as they run, e.g.,
> databases, packaging system metadata, etc.`
>
> So, I'm +1 for `/var/lib/ignite` to place persisted Ignite files there.
>
> [1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>
> On Mon, 26 Aug 2019 at 14:00, Nikolay Izhikov  wrote:
> >
> > Yes, of course.
> >
> > В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:
> > > Does this parameters intended to be overridden (for tests purposes for
> example) or it will be permanently sticked to this new directory without
> ability to change?
> > >
> > >
> > > > On 26 Aug 2019, at 13:58, Nikolay Izhikov 
> wrote:
> > > >
> > > > +1 for '/var/lib/ignite'
> > > >
> > > > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > > > +1 for '~/.ignite/work'
> > > > >
> > > > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov  >:
> > > > >
> > > > > > Hello, Igniters.
> > > > > >
> > > > > > There are a lot of variants was already proposed lets vote to
> one of them.
> > > > > > I made a list of possible paths which was mentioned earlier. I
> also
> > > > > > included variants outside of home directory('user.dir') to this
> list but I
> > > > > > want to notes that we had already discussed it and we decided to
> choose
> > > > > > some path in home directory rather outside of that. Also If you
> have any
> > > > > > other variants feel free to add it.
> > > > > >
> > > > > > 1) ~/.ignite/work
> > > > > > 2) ~/ignite/work
> > > > > > 3) ~/.config/ignite/work
> > > > > >
> > > > > > 4)/var/lib/ignite
> > > > > > 5)/usr/local/ignite
> > > > > > 6)/var/ignite
> > > > > > 7)/var/lib/ignite
> > > > > > 8)/opt/ignite/
> > > > > >
> > > > > > +1 for '~/.ignite/work'
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Anton Kalashnikov
> > > > > >
> > > > > >
> > > > > > 26.08.2019, 12:39, "Nikolay Izhikov" :
> > > > > > > Ilya,
> > > > > > >
> > > > > > > > In development environment one can just run Java from
> /var/lib/ignite
> > > > > > >
> > > > > > > Actually, I doesn't understand you.
> > > > > > > Are you talking about development of some application that
> uses Ignite
> > > > > >
> > > > > > or contribution to Ignite code base?
> > > > > > >
> > > > > > > If we are talking about some application that uses Ignite then
> we should
> > > > > >
> > > > > > decide, which scenario is primary.
> > > > > > > (One more time, we are talking about PDS enabled caches):
> > > > > > >
> > > > > > > 1. Ignite server node started as separate java process.
> > > > > > > 2. Ignite server node embedded in application as a library.
> > > > > > >
> > > > > > > I think, for PDS enabled cashes first case is primary.
> > > > > > > In that case, user should install Ignite via some package(deb,
> rpm,
> > > > > >
> > > > > > docker, etc).
> > > > > > > This package should done all required configuration.
> > > > > > > Including directory permissions.
> > > > > > >
> > > > > > > This should be done like other DBMS do.
> > > > > > >
> > > > > > > If we are talking about embedded Ignite then we can ask the
> user to
> > > > > >
> > > > > > provide sufficient permission for default dir or change dir to
> some other.
> > > > > > >
> > > > > > > So, I still think we should use /var/lig/ignite for PDS data.
> > > > > > >
> > > > > > > How it sounds?
> > > > > > >
> > > > > > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > In development environment one can just run Java from
> /var/lib/ignite
> > > > > > > > (makes total sense) and will immediately get almost correct
> behavior
> > > > > >
> > > > > > (well,
> > > > > > > > data will be stored to /var/lib/ignite/ignite/work)
> > > > > > > >
> > > > > > > > However, I still think that we should write to
> user.dir/ignite and not
> > > > > >
> > > > > > just
> > > > > > > > user.dir since current directory is often crowded.
> > > > > > > >
> > > > > > > > Fellows, anyone who is against using user.dir? Please share
> your
> > > > > >
> > > > > > concerns.
> > > > > > > >
> > > > > > > > Regards,
> > > > > >
> > > > > >
> > >
> > >
>

Control.sh usability & possible bugs

[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

[Anton Kalashnikov]

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: Replacing default work dir from tmp to current dir

[Ilya Kasnacheev]

Hello!

Using /var/lib/ignite guarantees that any persistent Ignite node in
development will immediately fail with a cryptic message upon start, since
/var/lib is not writable by non-privileged users.

If our point is to force user to specify workDirectory setting, then yes,
this makes total sense. However, this seems like a too large breaking
change for a maintenance release.

LTS is not targeted on software developers, rather on package writers who
usually make sure that /var/lib/ignite exists, with correct permissions,
before trying to write there. And, I would add, LTS becomes obsolete as
containerization progresses since dockerized images no longer care deeply
about FS hierarchy.

Regards,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 14:41, Dmitriy Pavlov :

> Ok, folks, I'm not insisting on
> ~/ignite/work nor ~/.ignite/work
>
> I wondering what about Windows systems. Linux is not only one platform
> Ignite runs on.
>
> пн, 26 авг. 2019 г. в 14:28, Maxim Muzafarov :
>
> > Folks,
> >
> > According to the Filesystem Hierarchy Standard [1] (Wikipedia is not
> > the ideal reference), the `/var/lib` directory is the `state
> > information. Persistent data modified by programs as they run, e.g.,
> > databases, packaging system metadata, etc.`
> >
> > So, I'm +1 for `/var/lib/ignite` to place persisted Ignite files there.
> >
> > [1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> >
> > On Mon, 26 Aug 2019 at 14:00, Nikolay Izhikov 
> wrote:
> > >
> > > Yes, of course.
> > >
> > > В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:
> > > > Does this parameters intended to be overridden (for tests purposes
> for
> > example) or it will be permanently sticked to this new directory without
> > ability to change?
> > > >
> > > >
> > > > > On 26 Aug 2019, at 13:58, Nikolay Izhikov 
> > wrote:
> > > > >
> > > > > +1 for '/var/lib/ignite'
> > > > >
> > > > > В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
> > > > > > +1 for '~/.ignite/work'
> > > > > >
> > > > > > пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov <
> kaa@yandex.ru
> > >:
> > > > > >
> > > > > > > Hello, Igniters.
> > > > > > >
> > > > > > > There are a lot of variants was already proposed lets vote to
> > one of them.
> > > > > > > I made a list of possible paths which was mentioned earlier. I
> > also
> > > > > > > included variants outside of home directory('user.dir') to this
> > list but I
> > > > > > > want to notes that we had already discussed it and we decided
> to
> > choose
> > > > > > > some path in home directory rather outside of that. Also If you
> > have any
> > > > > > > other variants feel free to add it.
> > > > > > >
> > > > > > > 1) ~/.ignite/work
> > > > > > > 2) ~/ignite/work
> > > > > > > 3) ~/.config/ignite/work
> > > > > > >
> > > > > > > 4)/var/lib/ignite
> > > > > > > 5)/usr/local/ignite
> > > > > > > 6)/var/ignite
> > > > > > > 7)/var/lib/ignite
> > > > > > > 8)/opt/ignite/
> > > > > > >
> > > > > > > +1 for '~/.ignite/work'
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Anton Kalashnikov
> > > > > > >
> > > > > > >
> > > > > > > 26.08.2019, 12:39, "Nikolay Izhikov" :
> > > > > > > > Ilya,
> > > > > > > >
> > > > > > > > > In development environment one can just run Java from
> > /var/lib/ignite
> > > > > > > >
> > > > > > > > Actually, I doesn't understand you.
> > > > > > > > Are you talking about development of some application that
> > uses Ignite
> > > > > > >
> > > > > > > or contribution to Ignite code base?
> > > > > > > >
> > > > > > > > If we are talking about some application that uses Ignite
> then
> > we should
> > > > > > >
> > > > > > > decide, which scenario is primary.
> > > > > > > > (One more time, we are talking about PDS enabled caches):
> > > > > > > >
> > > > > > > > 1. Ignite server node started as separate java process.
> > > > > > > > 2. Ignite server node embedded in application as a library.
> > > > > > > >
> > > > > > > > I think, for PDS enabled cashes first case is primary.
> > > > > > > > In that case, user should install Ignite via some
> package(deb,
> > rpm,
> > > > > > >
> > > > > > > docker, etc).
> > > > > > > > This package should done all required configuration.
> > > > > > > > Including directory permissions.
> > > > > > > >
> > > > > > > > This should be done like other DBMS do.
> > > > > > > >
> > > > > > > > If we are talking about embedded Ignite then we can ask the
> > user to
> > > > > > >
> > > > > > > provide sufficient permission for default dir or change dir to
> > some other.
> > > > > > > >
> > > > > > > > So, I still think we should use /var/lig/ignite for PDS data.
> > > > > > > >
> > > > > > > > How it sounds?
> > > > > > > >
> > > > > > > > В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > In development environment one can just run Java from
> > /var/lib/ignite
> > > > > > > > > (makes total sense) and will immediately get almost correct
> > behavior
> >

Re: Replacing default work dir from tmp to current dir

[Nikolay Izhikov]

Hello, Ilya.

We can't have discussion if you only make statements, but don't answer the 
questions :)
I repeat my own statements and questions to you.

*How do you think, what is primary usage scenario for Ignite with PDS enabled 
cache?*

If we are talking about some application that uses Ignite then we should 
decide, which scenario is primary.
(One more time, we are talking about PDS enabled caches):

1. Ignite server node started as separate java process.
2. Ignite server node embedded in application as a library.

I think, for PDS enabled cashes first case is primary.
In that case, user should install Ignite via some package(deb, rpm, docker, 
etc).
This package should done all required configuration.
Including directory permissions.

This should be done like other DBMS do.

If we are talking about embedded Ignite then we can ask the user to provide 
sufficient permission for default dir or change dir to some other.

So, I still think we should use /var/lig/ignite for PDS data.

How it sounds?




В Пн, 26/08/2019 в 15:24 +0300, Ilya Kasnacheev пишет:
> Hello!
> 
> Using /var/lib/ignite guarantees that any persistent Ignite node in
> development will immediately fail with a cryptic message upon start, since
> /var/lib is not writable by non-privileged users.
> 
> If our point is to force user to specify workDirectory setting, then yes,
> this makes total sense. However, this seems like a too large breaking
> change for a maintenance release.
> 
> LTS is not targeted on software developers, rather on package writers who
> usually make sure that /var/lib/ignite exists, with correct permissions,
> before trying to write there. And, I would add, LTS becomes obsolete as
> containerization progresses since dockerized images no longer care deeply
> about FS hierarchy.
> 
> Regards,


signature.asc
Description: This is a digitally signed message part

Re: Replacing default work dir from tmp to current dir

[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,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 15:27, Nikolay Izhikov :

> Hello, Ilya.
>
> We can't have discussion if you only make statements, but don't answer the
> questions :)
> I repeat my own statements and questions to you.
>
> *How do you think, what is primary usage scenario for Ignite with PDS
> enabled cache?*
>
> If we are talking about some application that uses Ignite then we should
> decide, which scenario is primary.
> (One more time, we are talking about PDS enabled caches):
>
> 1. Ignite server node started as separate java process.
> 2. Ignite server node embedded in application as a library.
>
> I think, for PDS enabled cashes first case is primary.
> In that case, user should install Ignite via some package(deb, rpm,
> docker, etc).
> This package should done all required configuration.
> Including directory permissions.
>
> This should be done like other DBMS do.
>
> If we are talking about embedded Ignite then we can ask the user to
> provide sufficient permission for default dir or change dir to some other.
>
> So, I still think we should use /var/lig/ignite for PDS data.
>
> How it sounds?
>
>
>
>
> В Пн, 26/08/2019 в 15:24 +0300, Ilya Kasnacheev пишет:
> > Hello!
> >
> > Using /var/lib/ignite guarantees that any persistent Ignite node in
> > development will immediately fail with a cryptic message upon start,
> since
> > /var/lib is not writable by non-privileged users.
> >
> > If our point is to force user to specify workDirectory setting, then yes,
> > this makes total sense. However, this seems like a too large breaking
> > change for a maintenance release.
> >
> > LTS is not targeted on software developers, rather on package writers who
> > usually make sure that /var/lib/ignite exists, with correct permissions,
> > before trying to write there. And, I would add, LTS becomes obsolete as
> > containerization progresses since dockerized images no longer care deeply
> > about FS hierarchy.
> >
> > Regards,
>

Re: Do I have to use --illegal-access=permit for Java thin client and JDBC with JDK 9/10/11.

[Alex Plehanov]

Denis,

I've tried Oracle JDK 11 and OpenJDK 12 with Ignite 2.7.5, looks like:
"--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED"
Is enough for running java thin client.
Also, adding:
"--add-opens=java.base/java.nio=ALL-UNNAMED"
Eliminates all warnings about illegal access (with
"--illegal-access=permit" warnings are still shown)

About "--illegal-access=permit" flag, AFAIK this is the default value for
currently released java versions (11, 12). But with option
"--add-opens=java.base/java.nio=ALL-UNNAMED" thin client also works even if
"--illegal-access=deny" is set.

 пт, 23 авг. 2019 г. в 19:44, Denis Magda :

> Hmm, looks like we need to provide some VM options for the thin clients as
> well.
>
> Alex, would you mind checking and sharing a full subset of such options for
> the thin clients? I'll update the docs.
>
> -
> Denis
>
>
> On Fri, Aug 23, 2019 at 9:23 AM Alex Plehanov 
> wrote:
>
> > Denis,
> >
> > Thin client uses BinaryHeapOutputStream, which uses Unsafe. I've got some
> > warnings when I run thin client with --illegal-access=debug flag, for
> > example:
> >
> > WARNING: Illegal reflective access by
> > org.apache.ignite.internal.util.GridUnsafe$2
> > (file:/D:/Work/Projects/ignite/modules/core/target/classes/) to field
> > java.nio.Buffer.address
> > at org.apache.ignite.internal.util.GridUnsafe$2.run(GridUnsafe.java:1536)
> > at org.apache.ignite.internal.util.GridUnsafe$2.run(GridUnsafe.java:1531)
> > at
> >
> >
> java.base/java.security.AccessController.doPrivileged(AccessController.java:310)
> > at
> >
> >
> org.apache.ignite.internal.util.GridUnsafe.bufferAddressOffset(GridUnsafe.java:1531)
> > at
> org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:106)
> > at
> >
> >
> org.apache.ignite.internal.binary.streams.BinaryHeapOutputStream.writeIntFast(BinaryHeapOutputStream.java:122)
> > at
> >
> >
> org.apache.ignite.internal.binary.streams.BinaryAbstractOutputStream.writeInt(BinaryAbstractOutputStream.java:123)
> >
> >
> > чт, 22 авг. 2019 г. в 23:43, Denis Magda :
> >
> > > Ok, I updated the docs saying that
> > >
> > > "4. Add the following VM options to your Java applications. That's not
> > > needed if you use Java thin clients or Ignite JDBC."
> > >
> > >
> >
> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Thu, Aug 22, 2019 at 9:30 AM Denis Mekhanikov <
> dmekhani...@gmail.com>
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > I didn’t find any usages of JDK internals in the implementation of
> the
> > > > thin clients.
> > > > It would be nice to verify in tests that thin clients can work
> without
> > > > these flags.
> > > >
> > > > Do our Java 9/10/11 tests include thin client testing? If so, do
> these
> > > > tests include these flags?
> > > >
> > > > Denis
> > > > On 15 Aug 2019, 11:09 +0300, Denis Magda , wrote:
> > > > > Denis,
> > > > >
> > > > > Does it mean we don't need to pass any flags from this list [1] at
> > all
> > > > for
> > > > > the JDBC and thin clients?
> > > > >
> > > > > [1]
> > > > >
> > > >
> > >
> >
> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Wed, Aug 14, 2019 at 5:56 PM Denis Mekhanikov <
> > > dmekhani...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi!
> > > > > >
> > > > > > There are two JDK internal things that are used by Ignite: Unsafe
> > and
> > > > > > sun.nio.ch package.
> > > > > > None of these things are used by thin clients. So, it’s fine to
> use
> > > > thin
> > > > > > clients without additional flags.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > > On 13 Aug 2019, at 23:01, Shane Duan 
> > wrote:
> > > > > > >
> > > > > > > Hi Igniter,
> > > > > > >
> > > > > > > I understand that --illegal-access=permit is required for JDK
> > > > 9/10/11 on
> > > > > > > Ignite server. But do I have to include this JVM parameter for
> > > Ignite
> > > > > > Java
> > > > > > > thin client and JDBC client? I tried some simple test without
> it
> > > and
> > > > it
> > > > > > > seems working fine...
> > > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Shane
> > > > > >
> > > > > >
> > > >
> > >
> >
>

Re: Do I have to use --illegal-access=permit for Java thin client and JDBC with JDK 9/10/11.

[Dmitriy Pavlov]

Hi Alex, Would it be reasonable to migrate exports to --add-opens?

Thin clients don't use Unsafe, so --illegal-access=deny has no effect.

--illegal-acess=pertmit is also well known that it is a default value. I
guess it was added to compensate future Java defaults changes from permit
to deny. We can save one more release if Ignite will work on a future
release of Java, where `permit` is not  default.

Sincerely,
Dmitriy Pavlov

пн, 26 авг. 2019 г. в 15:51, Alex Plehanov :

> Denis,
>
> I've tried Oracle JDK 11 and OpenJDK 12 with Ignite 2.7.5, looks like:
> "--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED"
> Is enough for running java thin client.
> Also, adding:
> "--add-opens=java.base/java.nio=ALL-UNNAMED"
> Eliminates all warnings about illegal access (with
> "--illegal-access=permit" warnings are still shown)
>
> About "--illegal-access=permit" flag, AFAIK this is the default value for
> currently released java versions (11, 12). But with option
> "--add-opens=java.base/java.nio=ALL-UNNAMED" thin client also works even if
> "--illegal-access=deny" is set.
>
>  пт, 23 авг. 2019 г. в 19:44, Denis Magda :
>
> > Hmm, looks like we need to provide some VM options for the thin clients
> as
> > well.
> >
> > Alex, would you mind checking and sharing a full subset of such options
> for
> > the thin clients? I'll update the docs.
> >
> > -
> > Denis
> >
> >
> > On Fri, Aug 23, 2019 at 9:23 AM Alex Plehanov 
> > wrote:
> >
> > > Denis,
> > >
> > > Thin client uses BinaryHeapOutputStream, which uses Unsafe. I've got
> some
> > > warnings when I run thin client with --illegal-access=debug flag, for
> > > example:
> > >
> > > WARNING: Illegal reflective access by
> > > org.apache.ignite.internal.util.GridUnsafe$2
> > > (file:/D:/Work/Projects/ignite/modules/core/target/classes/) to field
> > > java.nio.Buffer.address
> > > at
> org.apache.ignite.internal.util.GridUnsafe$2.run(GridUnsafe.java:1536)
> > > at
> org.apache.ignite.internal.util.GridUnsafe$2.run(GridUnsafe.java:1531)
> > > at
> > >
> > >
> >
> java.base/java.security.AccessController.doPrivileged(AccessController.java:310)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.util.GridUnsafe.bufferAddressOffset(GridUnsafe.java:1531)
> > > at
> > org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:106)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.binary.streams.BinaryHeapOutputStream.writeIntFast(BinaryHeapOutputStream.java:122)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.binary.streams.BinaryAbstractOutputStream.writeInt(BinaryAbstractOutputStream.java:123)
> > >
> > >
> > > чт, 22 авг. 2019 г. в 23:43, Denis Magda :
> > >
> > > > Ok, I updated the docs saying that
> > > >
> > > > "4. Add the following VM options to your Java applications. That's
> not
> > > > needed if you use Java thin clients or Ignite JDBC."
> > > >
> > > >
> > >
> >
> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Thu, Aug 22, 2019 at 9:30 AM Denis Mekhanikov <
> > dmekhani...@gmail.com>
> > > > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > I didn’t find any usages of JDK internals in the implementation of
> > the
> > > > > thin clients.
> > > > > It would be nice to verify in tests that thin clients can work
> > without
> > > > > these flags.
> > > > >
> > > > > Do our Java 9/10/11 tests include thin client testing? If so, do
> > these
> > > > > tests include these flags?
> > > > >
> > > > > Denis
> > > > > On 15 Aug 2019, 11:09 +0300, Denis Magda ,
> wrote:
> > > > > > Denis,
> > > > > >
> > > > > > Does it mean we don't need to pass any flags from this list [1]
> at
> > > all
> > > > > for
> > > > > > the JDBC and thin clients?
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11
> > > > > >
> > > > > > -
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 14, 2019 at 5:56 PM Denis Mekhanikov <
> > > > dmekhani...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > There are two JDK internal things that are used by Ignite:
> Unsafe
> > > and
> > > > > > > sun.nio.ch package.
> > > > > > > None of these things are used by thin clients. So, it’s fine to
> > use
> > > > > thin
> > > > > > > clients without additional flags.
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > > On 13 Aug 2019, at 23:01, Shane Duan 
> > > wrote:
> > > > > > > >
> > > > > > > > Hi Igniter,
> > > > > > > >
> > > > > > > > I understand that --illegal-access=permit is required for JDK
> > > > > 9/10/11 on
> > > > > > > > Ignite server. But do I have to include this JVM parameter
> for
> > > > Ignite
> > > > > > > Java
> > > > > > > > thin client and JDBC client? I tried some simple test without
> > it
> > > > and
> > > > > it
> > > > > > > > seems working fine...
> > > > > > > >
> > > > > > > >

Re: Replacing default work dir from tmp to current dir

[Petr Ivanov]

In Windows there is %USER%/Application Data folder (or just %USER%) that is 
analog of ~/. in Linux.
MacOS has home directory as well, so that should not be a problem.


> On 26 Aug 2019, at 14:41, Dmitriy Pavlov  wrote:
> 
> Ok, folks, I'm not insisting on
> ~/ignite/work nor ~/.ignite/work
> 
> I wondering what about Windows systems. Linux is not only one platform
> Ignite runs on.
> 
> пн, 26 авг. 2019 г. в 14:28, Maxim Muzafarov :
> 
>> Folks,
>> 
>> According to the Filesystem Hierarchy Standard [1] (Wikipedia is not
>> the ideal reference), the `/var/lib` directory is the `state
>> information. Persistent data modified by programs as they run, e.g.,
>> databases, packaging system metadata, etc.`
>> 
>> So, I'm +1 for `/var/lib/ignite` to place persisted Ignite files there.
>> 
>> [1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>> 
>> On Mon, 26 Aug 2019 at 14:00, Nikolay Izhikov  wrote:
>>> 
>>> Yes, of course.
>>> 
>>> В Пн, 26/08/2019 в 13:58 +0300, Petr Ivanov пишет:
 Does this parameters intended to be overridden (for tests purposes for
>> example) or it will be permanently sticked to this new directory without
>> ability to change?
 
 
> On 26 Aug 2019, at 13:58, Nikolay Izhikov 
>> wrote:
> 
> +1 for '/var/lib/ignite'
> 
> В Пн, 26/08/2019 в 13:28 +0300, Dmitriy Pavlov пишет:
>> +1 for '~/.ignite/work'
>> 
>> пн, 26 авг. 2019 г. в 13:27, Anton Kalashnikov >> :
>> 
>>> Hello, Igniters.
>>> 
>>> There are a lot of variants was already proposed lets vote to
>> one of them.
>>> I made a list of possible paths which was mentioned earlier. I
>> also
>>> included variants outside of home directory('user.dir') to this
>> list but I
>>> want to notes that we had already discussed it and we decided to
>> choose
>>> some path in home directory rather outside of that. Also If you
>> have any
>>> other variants feel free to add it.
>>> 
>>> 1) ~/.ignite/work
>>> 2) ~/ignite/work
>>> 3) ~/.config/ignite/work
>>> 
>>> 4)/var/lib/ignite
>>> 5)/usr/local/ignite
>>> 6)/var/ignite
>>> 7)/var/lib/ignite
>>> 8)/opt/ignite/
>>> 
>>> +1 for '~/.ignite/work'
>>> 
>>> --
>>> Best regards,
>>> Anton Kalashnikov
>>> 
>>> 
>>> 26.08.2019, 12:39, "Nikolay Izhikov" :
 Ilya,
 
> In development environment one can just run Java from
>> /var/lib/ignite
 
 Actually, I doesn't understand you.
 Are you talking about development of some application that
>> uses Ignite
>>> 
>>> or contribution to Ignite code base?
 
 If we are talking about some application that uses Ignite then
>> we should
>>> 
>>> decide, which scenario is primary.
 (One more time, we are talking about PDS enabled caches):
 
 1. Ignite server node started as separate java process.
 2. Ignite server node embedded in application as a library.
 
 I think, for PDS enabled cashes first case is primary.
 In that case, user should install Ignite via some package(deb,
>> rpm,
>>> 
>>> docker, etc).
 This package should done all required configuration.
 Including directory permissions.
 
 This should be done like other DBMS do.
 
 If we are talking about embedded Ignite then we can ask the
>> user to
>>> 
>>> provide sufficient permission for default dir or change dir to
>> some other.
 
 So, I still think we should use /var/lig/ignite for PDS data.
 
 How it sounds?
 
 В Пн, 26/08/2019 в 12:23 +0300, Ilya Kasnacheev пишет:
> Hello!
> 
> In development environment one can just run Java from
>> /var/lib/ignite
> (makes total sense) and will immediately get almost correct
>> behavior
>>> 
>>> (well,
> data will be stored to /var/lib/ignite/ignite/work)
> 
> However, I still think that we should write to
>> user.dir/ignite and not
>>> 
>>> just
> user.dir since current directory is often crowded.
> 
> Fellows, anyone who is against using user.dir? Please share
>> your
>>> 
>>> concerns.
> 
> Regards,
>>> 
>>> 
 
 
>> 

Re: Replacing default work dir from tmp to current dir

[Nikolay Izhikov]

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,


signature.asc
Description: This is a digitally signed message part

The ASF Slack

[Anton Vinogradov]

Igniters,
I'd like to propose you to register at the ASF Slack [1] (committers seems
to be already registered) and join the Ignite channel [2].
This should simplify communication between the contributors.

P.s. I'm not saying we have to replace devlist with the Slack, but Slack is
a more suitable place for short or private communications.

[1] https://the-asf.slack.com
[2] https://the-asf.slack.com/messages/C7E04VCPK

Re: The ASF Slack

[Nikolay Izhikov]

Anton, 

Can we create channels for ticket, IEP discussions in ASF slack?


В Пн, 26/08/2019 в 16:09 +0300, Anton Vinogradov пишет:
> Igniters,
> I'd like to propose you to register at the ASF Slack [1] (committers seems
> to be already registered) and join the Ignite channel [2].
> This should simplify communication between the contributors.
> 
> P.s. I'm not saying we have to replace devlist with the Slack, but Slack is
> a more suitable place for short or private communications.
> 
> [1] https://the-asf.slack.com
> [2] https://the-asf.slack.com/messages/C7E04VCPK


signature.asc
Description: This is a digitally signed message part

Re: The ASF Slack

[Anton Vinogradov]

Nikolay,

Let's try ;)

On Mon, Aug 26, 2019 at 4:15 PM Nikolay Izhikov  wrote:

> Anton,
>
> Can we create channels for ticket, IEP discussions in ASF slack?
>
>
> В Пн, 26/08/2019 в 16:09 +0300, Anton Vinogradov пишет:
> > Igniters,
> > I'd like to propose you to register at the ASF Slack [1] (committers
> seems
> > to be already registered) and join the Ignite channel [2].
> > This should simplify communication between the contributors.
> >
> > P.s. I'm not saying we have to replace devlist with the Slack, but Slack
> is
> > a more suitable place for short or private communications.
> >
> > [1] https://the-asf.slack.com
> > [2] https://the-asf.slack.com/messages/C7E04VCPK
>

Re: Do I have to use --illegal-access=permit for Java thin client and JDBC with JDK 9/10/11.

[Alex Plehanov]

Dmitry,

As I said before, thin client uses BinaryHeapOutputStream, which uses
Unsafe, so "--illegal-access=deny" has an effect.
With "--illegal-access=deny" thin client will not start unless you specify
"--add-opens=java.base/java.nio=ALL-UNNAMED"

пн, 26 авг. 2019 г. в 15:57, Dmitriy Pavlov :

> Hi Alex, Would it be reasonable to migrate exports to --add-opens?
>
> Thin clients don't use Unsafe, so --illegal-access=deny has no effect.
>
> --illegal-acess=pertmit is also well known that it is a default value. I
> guess it was added to compensate future Java defaults changes from permit
> to deny. We can save one more release if Ignite will work on a future
> release of Java, where `permit` is not  default.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 26 авг. 2019 г. в 15:51, Alex Plehanov :
>
> > Denis,
> >
> > I've tried Oracle JDK 11 and OpenJDK 12 with Ignite 2.7.5, looks like:
> > "--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED"
> > Is enough for running java thin client.
> > Also, adding:
> > "--add-opens=java.base/java.nio=ALL-UNNAMED"
> > Eliminates all warnings about illegal access (with
> > "--illegal-access=permit" warnings are still shown)
> >
> > About "--illegal-access=permit" flag, AFAIK this is the default value for
> > currently released java versions (11, 12). But with option
> > "--add-opens=java.base/java.nio=ALL-UNNAMED" thin client also works even
> if
> > "--illegal-access=deny" is set.
> >
> >  пт, 23 авг. 2019 г. в 19:44, Denis Magda :
> >
> > > Hmm, looks like we need to provide some VM options for the thin clients
> > as
> > > well.
> > >
> > > Alex, would you mind checking and sharing a full subset of such options
> > for
> > > the thin clients? I'll update the docs.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Fri, Aug 23, 2019 at 9:23 AM Alex Plehanov  >
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > Thin client uses BinaryHeapOutputStream, which uses Unsafe. I've got
> > some
> > > > warnings when I run thin client with --illegal-access=debug flag, for
> > > > example:
> > > >
> > > > WARNING: Illegal reflective access by
> > > > org.apache.ignite.internal.util.GridUnsafe$2
> > > > (file:/D:/Work/Projects/ignite/modules/core/target/classes/) to field
> > > > java.nio.Buffer.address
> > > > at
> > org.apache.ignite.internal.util.GridUnsafe$2.run(GridUnsafe.java:1536)
> > > > at
> > org.apache.ignite.internal.util.GridUnsafe$2.run(GridUnsafe.java:1531)
> > > > at
> > > >
> > > >
> > >
> >
> java.base/java.security.AccessController.doPrivileged(AccessController.java:310)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.util.GridUnsafe.bufferAddressOffset(GridUnsafe.java:1531)
> > > > at
> > >
> org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:106)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.binary.streams.BinaryHeapOutputStream.writeIntFast(BinaryHeapOutputStream.java:122)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.binary.streams.BinaryAbstractOutputStream.writeInt(BinaryAbstractOutputStream.java:123)
> > > >
> > > >
> > > > чт, 22 авг. 2019 г. в 23:43, Denis Magda :
> > > >
> > > > > Ok, I updated the docs saying that
> > > > >
> > > > > "4. Add the following VM options to your Java applications. That's
> > not
> > > > > needed if you use Java thin clients or Ignite JDBC."
> > > > >
> > > > >
> > > >
> > >
> >
> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Thu, Aug 22, 2019 at 9:30 AM Denis Mekhanikov <
> > > dmekhani...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > I didn’t find any usages of JDK internals in the implementation
> of
> > > the
> > > > > > thin clients.
> > > > > > It would be nice to verify in tests that thin clients can work
> > > without
> > > > > > these flags.
> > > > > >
> > > > > > Do our Java 9/10/11 tests include thin client testing? If so, do
> > > these
> > > > > > tests include these flags?
> > > > > >
> > > > > > Denis
> > > > > > On 15 Aug 2019, 11:09 +0300, Denis Magda ,
> > wrote:
> > > > > > > Denis,
> > > > > > >
> > > > > > > Does it mean we don't need to pass any flags from this list [1]
> > at
> > > > all
> > > > > > for
> > > > > > > the JDBC and thin clients?
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11
> > > > > > >
> > > > > > > -
> > > > > > > Denis
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Aug 14, 2019 at 5:56 PM Denis Mekhanikov <
> > > > > dmekhani...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi!
> > > > > > > >
> > > > > > > > There are two JDK internal things that are used by Ignite:
> > Unsafe
> > > > and
> > > > > > > > sun.nio.ch package.
> > > > > > > > None of these things are used by thin clients. So, it’s fine
> to
> > > use
> > > > >

Re: The ASF Slack

[Dmitriy Pavlov]

Hi,

If we use the example of Apache Beam, usually these channels relate to a
module or language, e.g. beam-python,  beam-ml, etc.

I also support the idea of ASF slack usage. Moreover, we can ask Infra to
install automatic translation of messages to English. It may help
non-native speakers to communicate.

Let's just remember the motto:
If it didn't happen on the list - it didn't happen.

Sincerely,
Dmitriy Pavlov

пн, 26 авг. 2019 г. в 16:22, Anton Vinogradov :

> Nikolay,
>
> Let's try ;)
>
> On Mon, Aug 26, 2019 at 4:15 PM Nikolay Izhikov 
> wrote:
>
> > Anton,
> >
> > Can we create channels for ticket, IEP discussions in ASF slack?
> >
> >
> > В Пн, 26/08/2019 в 16:09 +0300, Anton Vinogradov пишет:
> > > Igniters,
> > > I'd like to propose you to register at the ASF Slack [1] (committers
> > seems
> > > to be already registered) and join the Ignite channel [2].
> > > This should simplify communication between the contributors.
> > >
> > > P.s. I'm not saying we have to replace devlist with the Slack, but
> Slack
> > is
> > > a more suitable place for short or private communications.
> > >
> > > [1] https://the-asf.slack.com
> > > [2] https://the-asf.slack.com/messages/C7E04VCPK
> >
>

Re: The ASF Slack

[Alexey Zinoviev]

I think that channels for separate IEP-s is too much.
But the slack is not indexing and not accessible for all people in the
Internet. Maybe it's wrong idea to discuss something there instead of
dev-list?

пн, 26 авг. 2019 г. в 16:27, Dmitriy Pavlov :

> Hi,
>
> If we use the example of Apache Beam, usually these channels relate to a
> module or language, e.g. beam-python,  beam-ml, etc.
>
> I also support the idea of ASF slack usage. Moreover, we can ask Infra to
> install automatic translation of messages to English. It may help
> non-native speakers to communicate.
>
> Let's just remember the motto:
> If it didn't happen on the list - it didn't happen.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 26 авг. 2019 г. в 16:22, Anton Vinogradov :
>
> > Nikolay,
> >
> > Let's try ;)
> >
> > On Mon, Aug 26, 2019 at 4:15 PM Nikolay Izhikov 
> > wrote:
> >
> > > Anton,
> > >
> > > Can we create channels for ticket, IEP discussions in ASF slack?
> > >
> > >
> > > В Пн, 26/08/2019 в 16:09 +0300, Anton Vinogradov пишет:
> > > > Igniters,
> > > > I'd like to propose you to register at the ASF Slack [1] (committers
> > > seems
> > > > to be already registered) and join the Ignite channel [2].
> > > > This should simplify communication between the contributors.
> > > >
> > > > P.s. I'm not saying we have to replace devlist with the Slack, but
> > Slack
> > > is
> > > > a more suitable place for short or private communications.
> > > >
> > > > [1] https://the-asf.slack.com
> > > > [2] https://the-asf.slack.com/messages/C7E04VCPK
> > >
> >
>

Re: Replacing default work dir from tmp to current dir

[Pavel Tupitsyn]

+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  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,
>

Re: The ASF Slack

[Dmitriy Pavlov]

I agree with Alexey, since Dev list it better place in most cases. Apache
does not prohibit peer 2 peer communication, and ASF slack can be used as a
messenger.

The main thing here is that we (all community) clearly understand that ASF
slack is the replacement to Skype/Rocket Chat/Calls, it is not a
replacement for the list.

Each private agreement should be published as intent in the list. Only
after some time and there are no objections - it is valid agreement.

пн, 26 авг. 2019 г. в 16:56, Alexey Zinoviev :

> I think that channels for separate IEP-s is too much.
> But the slack is not indexing and not accessible for all people in the
> Internet. Maybe it's wrong idea to discuss something there instead of
> dev-list?
>
> пн, 26 авг. 2019 г. в 16:27, Dmitriy Pavlov :
>
> > Hi,
> >
> > If we use the example of Apache Beam, usually these channels relate to a
> > module or language, e.g. beam-python,  beam-ml, etc.
> >
> > I also support the idea of ASF slack usage. Moreover, we can ask Infra to
> > install automatic translation of messages to English. It may help
> > non-native speakers to communicate.
> >
> > Let's just remember the motto:
> > If it didn't happen on the list - it didn't happen.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 26 авг. 2019 г. в 16:22, Anton Vinogradov :
> >
> > > Nikolay,
> > >
> > > Let's try ;)
> > >
> > > On Mon, Aug 26, 2019 at 4:15 PM Nikolay Izhikov 
> > > wrote:
> > >
> > > > Anton,
> > > >
> > > > Can we create channels for ticket, IEP discussions in ASF slack?
> > > >
> > > >
> > > > В Пн, 26/08/2019 в 16:09 +0300, Anton Vinogradov пишет:
> > > > > Igniters,
> > > > > I'd like to propose you to register at the ASF Slack [1]
> (committers
> > > > seems
> > > > > to be already registered) and join the Ignite channel [2].
> > > > > This should simplify communication between the contributors.
> > > > >
> > > > > P.s. I'm not saying we have to replace devlist with the Slack, but
> > > Slack
> > > > is
> > > > > a more suitable place for short or private communications.
> > > > >
> > > > > [1] https://the-asf.slack.com
> > > > > [2] https://the-asf.slack.com/messages/C7E04VCPK
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-12104) Check deployment from cache before to load it from local or version storage

[Vladislav Pyatkov (Jira)]

Vladislav Pyatkov created IGNITE-12104:
--

 Summary: Check deployment from cache before to load it from local 
or version storage
 Key: IGNITE-12104
 URL: https://issues.apache.org/jira/browse/IGNITE-12104
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladislav Pyatkov
 Fix For: 2.8


{noformat}
"pub-#3217917%DPL_GRID%DplGridNodeName%" #3223897 prio=5 os_prio=0 
tid=0x7f47a414f800 nid=0x1dca46 runnable [0x7eaca31b]
java.lang.Thread.State: RUNNABLE
at java.lang.String.concat(String.java:2034)
at java.net.URLClassLoader$1.run(URLClassLoader.java:364)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
- locked <0x7f4c8dd6c888> (a java.lang.Object)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4c8db4f530> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba0138340> (a 
com.sbt.core.envelope.container.loader.NamedClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x7f4ba012a800> (a 
com.sbt.core.envelope.container.loader.ImplClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:462)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:983)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}



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

Re: The ASF Slack

[Andrey Gura]

> But the slack is not indexing and not accessible for all people in the
Internet

+1

On Mon, Aug 26, 2019 at 4:56 PM Alexey Zinoviev  wrote:
>
> I think that channels for separate IEP-s is too much.
> But the slack is not indexing and not accessible for all people in the
> Internet. Maybe it's wrong idea to discuss something there instead of
> dev-list?
>
> пн, 26 авг. 2019 г. в 16:27, Dmitriy Pavlov :
>
> > Hi,
> >
> > If we use the example of Apache Beam, usually these channels relate to a
> > module or language, e.g. beam-python,  beam-ml, etc.
> >
> > I also support the idea of ASF slack usage. Moreover, we can ask Infra to
> > install automatic translation of messages to English. It may help
> > non-native speakers to communicate.
> >
> > Let's just remember the motto:
> > If it didn't happen on the list - it didn't happen.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 26 авг. 2019 г. в 16:22, Anton Vinogradov :
> >
> > > Nikolay,
> > >
> > > Let's try ;)
> > >
> > > On Mon, Aug 26, 2019 at 4:15 PM Nikolay Izhikov 
> > > wrote:
> > >
> > > > Anton,
> > > >
> > > > Can we create channels for ticket, IEP discussions in ASF slack?
> > > >
> > > >
> > > > В Пн, 26/08/2019 в 16:09 +0300, Anton Vinogradov пишет:
> > > > > Igniters,
> > > > > I'd like to propose you to register at the ASF Slack [1] (committers
> > > > seems
> > > > > to be already registered) and join the Ignite channel [2].
> > > > > This should simplify communication between the contributors.
> > > > >
> > > > > P.s. I'm not saying we have to replace devlist with the Slack, but
> > > Slack
> > > > is
> > > > > a more suitable place for short or private communications.
> > > > >
> > > > > [1] https://the-asf.slack.com
> > > > > [2] https://the-asf.slack.com/messages/C7E04VCPK
> > > >
> > >
> >

[IEP-35] Metrics management in Ignite

[Andrey Gura]

Hi, Igniters!

I'm working on some metrics related aspects and it seems that we have
missed some points regarding the metrics management. There are at
least two major problems from my point of view.

Problem definition.
---

1. There is no unified approach to adding metrics during development.

It would be grate to have one common place where developer should add
new metrics or can find answer for question "What kind of metrics do
we have for smth?". I talk only about Ignite internal metrics, not
user's metrics.

Now the logic is spread throughout the code base and there is now any
way to find proper place where particular metric could be added to the
registry. Moreover, we can create registry in one place and add some
set of metrics to the registry in another place and we have many
examples of it.

Of course, metrics API allows it and it is meaningful drawback from my
point view. MetricRegistry is mutable and could be modified at any
place of the code and any time of program execution. It  allows
developer follow the simplest way which is usually wrong. Also
GridMetricManager.registry() method has two responsibilities: it
creates and lookups registries. When I see registry() method call in
the code I can't assume what exactly intention had developer (is it
first creation of registry or modification of existing registry).

2. There is no unified approach to enabling/disabling metrics.

Here I mean both problems: runtime enabling/disabling and code design
that should allow do it in proper way. There is JIRA issue [1] about
it.

Now some metrics can be enabled/disabled in static configuration and
at runtime (cache metrics for example) and other don't have such
functionality. It should be unified. Any metrics set (eq.
MetricRegistry in current implementation) should have one unified
approach for enabling/disabling. Also we should provide infrastructure
for it as part of metrics framework.


Proposed solution.
---

1. Introduce new interface, e.g. MetriсSource that is responsible for
metrics life cycle for one metrics source (e.g. cache metrics, system
metrics, etc.) Each component with metrics should register own
implementation of this interface in metrics manager
(GridMetricManager).

Interface declares the following methods:

- String name() - returns sources name that will be available in
special MBean responsible for access for metrics manager.

- MetricRegistry enable() - returns MetricRegistry instance with
allready registered metrics. Metric registry has the same name as name
returned by MetricSource.name() method. This method can be invoked on
node start (if metrics are statically enabled) or as result of metric
enabling via MBean. As result all instance of MetricSource will have
all metric instances initialized and MetricRegistry must be added to
the registries map by GridMetricManager.

- void disable() - Should be invoked after removing corresponding
MetricRegistry from GridMetricManager.registries. The responsibility
is destroying of all metric instances (just assign null). This method
can be invoked during stopping component (e.g. cache stop, index
removing) or as result of metric disabling via MBean.

- boolean enabled() - Actual state for current implemntation.

NOTE 1: Adding/removing metric registries in GridMetricManager should
be performed with copy-on-write semantic in order to avoid possible
data races in related threads (e.g. exporters). It also allows avoid
data copy during exporting (just use link to the registries). Also we
can avoid using ConcurrentHashMap in such case. But of course
additional copies will be created per each registries map
modification. But we assume that it isn't frequent operation.

NOTE 2: MetricSource interface specific implementation is also
responsible for keeping direct references to metric instances and also
for functionality related with metric values calculation (including
checking whether metrics are enabled or not).

NOTE 3: GridMetricManager is responsible for
registration/deregistration of MBeans corresponding to each metrics
source. GridMetricManager is responsible for proper actions sequence
(e.g. we should first create metric registry and after it add it to
registries collection).

At this point we have:

- Way to find out all metrics in the system just navigating throughout
all implementations of MetricSource interface.
- Unified approach to metric creation.
- Unified approach to metric enabling/disabling at runtime.

2. Introduce MetricRegistryBuilder that returns immutable instance of
MetricRegistry. It will force developer to write code related with
metric creation at exactly one place. It also allows to avoid
MetricRegistry modification at runtime. Also we should remove
GridMetricRegistry.registry() method and introduce two new methods:
register(MetricRegistry) and unregister(String registryName). Each
method should assert that no old value for register() case or registry
was deleted for unregiste

Making Ignite Collaboration 100% Open and Transparent

[Denis Magda]

Folks, let me share more details on why Anton started the conversation
about Ignite Slack:
http://apache-ignite-developers.2346864.n4.nabble.com/The-ASF-Slack-td43233.html

Recently, a group of GridGain and Sberbank committers of Ignite has met to
discuss how to make our community more transparent and open. Anton and I
took part in that meeting. The primary problems we see in regards to
transparency and openness are as follows:

   - A lot of discussions on the dev list abrupts suddenly and it's unclear
   whether a discussion is abandoned or something else is going on in the
   background with a task/bug/improvement. In many cases, we tend to fall back
   to faster communication ways like instant messaging, calls, or face-to-face
   meetings that are not visible to the rest of the community. Emails (dev
   list) are the right communication channel but not for all of the stages.
   - Change reviews seem to be in a chaotic state. Sometimes it takes many
   rounds for a committer to urge another committer to do a review. In many
   cases, the other committer might be simply overwhelmed with regular tasks
   imposed by an employer. It will be good to come up with some public
   tracking approach that will help us all to see who and when will be able to
   review certain changes and make them to Ignite.

To address the problems we want to propose the following:

   - Keep using dev list the way you do today. No changes need to be done
   here.
   - Introduce Ignite Slack for instant messaging across all the community
   members who are obviously employed by different companies. Ignite PMC will
   be managing channels for various topics. Go to Slack when email (dev list)
   conversation is no longer effective, the way we do daily, no need to
   complicate our lives just because we work on an open-source project
   together.
   - Two or more committers need to talk verbally? Go ahead and schedule a
   meeting with Google Hangouts or another tool. Send an invite to the dev
   list for those who'd like to join and listen or share opinion. Want to talk
   in your native language? Go ahead and put a disclaimer that a conversation
   will be in Chinese, Russia, French, whatever. Simple and open.
   - Don't know how soon you'll be able to review some changes and, thus,
   ignoring other committers requests? GridGain and Sberbank are ready to
   propose a solution here. Both vendors use an approach to cooperate between
   GridGain and Sberbank committers. Now we'd like to make it fully open and
   adjust for community needs if required.

Thoughts, suggestions? I think we'll schedule a community meeting to finish
the conversation or discuss any cornerstone points. But start with your
questions first.

-
Denis

[jira] [Created] (IGNITE-12105) [ML] Implement projection vector.

[Ravil Galeyev (Jira)]

Ravil Galeyev created IGNITE-12105:
--

 Summary: [ML] Implement projection vector.
 Key: IGNITE-12105
 URL: https://issues.apache.org/jira/browse/IGNITE-12105
 Project: Ignite
  Issue Type: Task
  Components: ml
Reporter: Ravil Galeyev
Assignee: Ravil Galeyev


According to the discussion in 
[PR|[https://github.com/apache/ignite/pull/6567]] it's nice to have a  vector 
projecting by some filter.

 

Such kind of preprocessor should be implemented.



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

Re: The ASF Slack

[Denis Magda]

Anton,

Thanks for starting the conversation. I think that we need to explain to
our community how and why we came to this proposal. I've started another
discussion with details, sorry for not doing it earlier:
http://apache-ignite-developers.2346864.n4.nabble.com/Making-Ignite-Collaboration-100-Open-and-Transparent-td43244.html

--
Denis



On Mon, Aug 26, 2019 at 7:43 AM Andrey Gura  wrote:

> > But the slack is not indexing and not accessible for all people in the
> Internet
>
> +1
>
> On Mon, Aug 26, 2019 at 4:56 PM Alexey Zinoviev 
> wrote:
> >
> > I think that channels for separate IEP-s is too much.
> > But the slack is not indexing and not accessible for all people in the
> > Internet. Maybe it's wrong idea to discuss something there instead of
> > dev-list?
> >
> > пн, 26 авг. 2019 г. в 16:27, Dmitriy Pavlov :
> >
> > > Hi,
> > >
> > > If we use the example of Apache Beam, usually these channels relate to
> a
> > > module or language, e.g. beam-python,  beam-ml, etc.
> > >
> > > I also support the idea of ASF slack usage. Moreover, we can ask Infra
> to
> > > install automatic translation of messages to English. It may help
> > > non-native speakers to communicate.
> > >
> > > Let's just remember the motto:
> > > If it didn't happen on the list - it didn't happen.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 26 авг. 2019 г. в 16:22, Anton Vinogradov :
> > >
> > > > Nikolay,
> > > >
> > > > Let's try ;)
> > > >
> > > > On Mon, Aug 26, 2019 at 4:15 PM Nikolay Izhikov  >
> > > > wrote:
> > > >
> > > > > Anton,
> > > > >
> > > > > Can we create channels for ticket, IEP discussions in ASF slack?
> > > > >
> > > > >
> > > > > В Пн, 26/08/2019 в 16:09 +0300, Anton Vinogradov пишет:
> > > > > > Igniters,
> > > > > > I'd like to propose you to register at the ASF Slack [1]
> (committers
> > > > > seems
> > > > > > to be already registered) and join the Ignite channel [2].
> > > > > > This should simplify communication between the contributors.
> > > > > >
> > > > > > P.s. I'm not saying we have to replace devlist with the Slack,
> but
> > > > Slack
> > > > > is
> > > > > > a more suitable place for short or private communications.
> > > > > >
> > > > > > [1] https://the-asf.slack.com
> > > > > > [2] https://the-asf.slack.com/messages/C7E04VCPK
> > > > >
> > > >
> > >
>

Re: Making Ignite Collaboration 100% Open and Transparent

[Amit Chavan]

Hi Denis,

I really like the initiative for transparency and collaboration. Are there
any plans to help get new contributors up to speed with the project where
they can contribute effectively? Sometimes it can be intimidating to start
on a large project without some help or advice. Maybe assigning a mentor or
an existing committer can be useful or some slack channel people can ping
on. I am starting new on the project and have picked out newbie ticket from
the Jira board. As I make myself familiar with the code base maybe its good
to have some direction on which area should I focus more on etc.

Thanks,
Amit

On Mon, Aug 26, 2019 at 11:54 AM Denis Magda  wrote:

> Folks, let me share more details on why Anton started the conversation
> about Ignite Slack:
>
> http://apache-ignite-developers.2346864.n4.nabble.com/The-ASF-Slack-td43233.html
>
> Recently, a group of GridGain and Sberbank committers of Ignite has met to
> discuss how to make our community more transparent and open. Anton and I
> took part in that meeting. The primary problems we see in regards to
> transparency and openness are as follows:
>
>- A lot of discussions on the dev list abrupts suddenly and it's unclear
>whether a discussion is abandoned or something else is going on in the
>background with a task/bug/improvement. In many cases, we tend to fall
> back
>to faster communication ways like instant messaging, calls, or
> face-to-face
>meetings that are not visible to the rest of the community. Emails (dev
>list) are the right communication channel but not for all of the stages.
>- Change reviews seem to be in a chaotic state. Sometimes it takes many
>rounds for a committer to urge another committer to do a review. In many
>cases, the other committer might be simply overwhelmed with regular
> tasks
>imposed by an employer. It will be good to come up with some public
>tracking approach that will help us all to see who and when will be
> able to
>review certain changes and make them to Ignite.
>
> To address the problems we want to propose the following:
>
>- Keep using dev list the way you do today. No changes need to be done
>here.
>- Introduce Ignite Slack for instant messaging across all the community
>members who are obviously employed by different companies. Ignite PMC
> will
>be managing channels for various topics. Go to Slack when email (dev
> list)
>conversation is no longer effective, the way we do daily, no need to
>complicate our lives just because we work on an open-source project
>together.
>- Two or more committers need to talk verbally? Go ahead and schedule a
>meeting with Google Hangouts or another tool. Send an invite to the dev
>list for those who'd like to join and listen or share opinion. Want to
> talk
>in your native language? Go ahead and put a disclaimer that a
> conversation
>will be in Chinese, Russia, French, whatever. Simple and open.
>- Don't know how soon you'll be able to review some changes and, thus,
>ignoring other committers requests? GridGain and Sberbank are ready to
>propose a solution here. Both vendors use an approach to cooperate
> between
>GridGain and Sberbank committers. Now we'd like to make it fully open
> and
>adjust for community needs if required.
>
> Thoughts, suggestions? I think we'll schedule a community meeting to finish
> the conversation or discuss any cornerstone points. But start with your
> questions first.
>
> -
> Denis
>

Re: Replacing default work dir from tmp to current dir

[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  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 
> 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,
> >
>

[jira] [Created] (IGNITE-12106) Rework ignite binary metadata exception for ease of troubleshooting

[Denis Magda (Jira)]

Denis Magda created IGNITE-12106:


 Summary: Rework ignite binary metadata exception for ease of 
troubleshooting
 Key: IGNITE-12106
 URL: https://issues.apache.org/jira/browse/IGNITE-12106
 Project: Ignite
  Issue Type: Bug
  Components: cache, persistence
Affects Versions: 2.7.5, 2.7.6
Reporter: Denis Magda
 Fix For: 2.7.6


An exception of this kind happens regularly and its message doesn't suggest why 
it took place and how to fix the issue:

{noformat}
Cannot find metadata for object with compact footer: 2097659979
{noformat}

See this thread for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/Metastore-disappears-in-Docker-on-restarts-td43107.html

As a solution, let's rework this exception to ensure that the way like that 
"Ignite work directory might be cleared on restarts. Ensure that IGNITE_HOME 
doesn't point to a temp folder or any other folder that is destroyed/erased on 
restarts. Presently, IGNITE_HOME points to..."



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

Re: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Denis Magda]

Dmitry,

As long as the vote has been canceled and we're going to do several
improvements before starting a new one, I'd like to ask your permission to
include this ticket in 2.7.6 scope:
https://issues.apache.org/jira/browse/IGNITE-12106

It suggests the changes in log messages to simplify "binary metadata not
found"-class issues troubleshooting with the community involvement.
Presently, users stumble upon the issue frequently and can't come around it
w/o reaching us out. More details are here:
http://apache-ignite-developers.2346864.n4.nabble.com/Metastore-disappears-in-Docker-on-restarts-td43107.html

-
Denis


On Tue, Aug 20, 2019 at 8:00 AM Artem Budnikov 
wrote:

> Hi Dmitry,
>
> The release notes reviewed. Please see my comment in the pull request.
>
> -Artem
>
> On 19.08.2019 14:20, Dmitriy Pavlov wrote:
> > Hi Andrey,
> >
> > could you please take a look at
> > https://issues.apache.org/jira/browse/IGNITE-12061 ?
> >
> > Are you comfortable with merging it to release (in rush mode)?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вс, 18 авг. 2019 г. в 18:12, Dmitriy Pavlov :
> >
> >> Hi Igniters,
> >>
> >> please review release notes for Ignite 2.7.6 (-rc0), tickets:
> >> https://issues.apache.org/jira/issues/?jql=labels%20%3D%202.7.6-rc0 :
> >>
> >> Text version:
> >> https://github.com/apache/ignite/pull/6788/files
> >>
> >> And corresponding HTML version (will be available at SVN once vote
> passes):
> >>
> >> - Ignite work directory is set to current user's home directory by
> >> default, native persistence files aren't stored in Temp anymore
> >> [#IGNITE-12057]  >
> >> - Fixed the bug when SELECT with an equality predicate on the part
> of
> >> a primary compound key returned a single row result while multiple
> matching
> >> rows existed in the table [#IGNITE-12068]
> >> 
> >> - Fixed data corruption in the rare case when page replacement can
> >> reload an outdated page during checkpoint [#IGNITE-12081]
> >> 
> >> - Fixed tree corruption caused by incorrect row size calculation for
> >> shared cache groups [#IGNITE-12060]
> >> 
> >> - Java heap footprint reduced by optimizing
> >> GridDhtPartitionsFullMessage maps in exchange history
> [#IGNITE-11767]
> >> 
> >> - .NET: Fix for native persistence, now it works with custom
> affinity
> >> function [#IGNITE-10451]
> >> 
> >>
> >>
> >> For remained tickets
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.7.6%20and%20(labels%20!%3D%202.7.6-rc0%20or%20labels%20is%20EMPTY%20)
> >>
> >> please add desired release note as a comment (since I still not asked
> >> Infra about a separate field).
> >>
> >> Sincerely,
> >> Dmitriy Pavlov
> >>
> >> вс, 18 авг. 2019 г. в 12:59, Dmitriy Pavlov :
> >>
> >>> Ok, Ivan, thank you for sharing this bit of info. I always prefer to
> >>> avoid any rush. It may be reasonable to wait for 2.8 or maybe we'll
> decide
> >>> to do 2.7.7. As the release is a trigger for activity in the
> community, it
> >>> is always better to prepare releases.
> >>>
> >>> BTW, minor correction: ticket mentioned here as IGNITE-12507
> >>> (Persistence files are stored to temp dir) has
> >>> actually is https://issues.apache.org/jira/browse/IGNITE-12057 Anyway,
> >>> thanks to Anton K. & Dmitriy G., is already in the release branch.
> >>>
> >>> вс, 18 авг. 2019 г. в 06:27, Ivan Pavlukhina :
> >>>
>  Zhenya, Dmitriy,
> 
> >>> hi Dmitriy, Ivan Pavlukhin suggest to exclude IGNITE-12061 from
>  2.7.6, i
> >>> have no clue - why,
>  The reason here is a lack of time to ensure that everything is fine
>  there. The patch is valuable but not so trivial. Honestly, I find it
> wrong
>  to merge a changes I am not sure with (yet). Especially in a hurry.
> 
>  Sent from my iPhone
> 
> > On 17 Aug 2019, at 13:13, Zhenya Stanilovsky
>   wrote:
> > I hope there is no data loss here, but index tree corruption can be
>  easily obtained.
> > Impact: someone believe that inline_size has been changed due to
> index
>  recreation but that`s not so.
> >> Hi Evgeniy,
> >>
> >> I can't review this change. We need approve of a committer, who is
>  SQL
> >> expert,  here.
> >>
> >> What would be an impact on users if we don' include it into 2.7.6?
> >>
> >> Is it a critical/data loss issue? If not, I agree it can wait for
> 2.8
> >> release.
> >>
> >> Sincerely,
> >> Dmitriy Pavlov
> >>
> >> сб, 17 авг. 2019 г. в 12:43, Zhenya Stanilovsky  >:
> >>
> >>> hi Dmitriy, Ivan Pavlukhin suggest to exc

[jira] [Created] (IGNITE-12107) Docs: request setting IGNITE_HOME to permanent location in Docker

[Denis Magda (Jira)]

Denis Magda created IGNITE-12107:


 Summary: Docs: request setting IGNITE_HOME to permanent location 
in Docker
 Key: IGNITE-12107
 URL: https://issues.apache.org/jira/browse/IGNITE-12107
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Reporter: Denis Magda
 Fix For: 2.7.6


Update Ignite Docker and Kubernetes documentation stating that IGNITE_HOME, as 
well as WAL and persistent store directories, must point to the volumes that 
are not erased or destroyed on restarts. Please refer to this thread for more 
details:
http://apache-ignite-developers.2346864.n4.nabble.com/Metastore-disappears-in-Docker-on-restarts-td43107.html



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

Re: Metastore disappears in Docker on restarts

[Denis Magda]

Ivan, thanks for sharing your thoughts.

Created a ticket for the error message improvement
https://issues.apache.org/jira/browse/IGNITE-12106

and doc changes:
https://issues.apache.org/jira/browse/IGNITE-12107

Will try to make it to Ignite 2.7.6.


-
Denis


On Fri, Aug 23, 2019 at 3:05 PM Павлухин Иван  wrote:

> Denis,
>
> Actually binary metadata is not stored in a metastore (however there
> were a discussion about moving it). User scenario is valid. A
> meaningful exception and documentation are good.
>
> And also I can think about revisiting a needed configuration for
> persistence in containerized environments. It might be perfectly sane
> that user does not want to configure IGNITE_HOME and work directory
> pointing to a persistent volume. I think that there should a single
> option to point all persistent stuff an appropriate directory (other
> options to redirect WAL could be also provided). With a such option a
> new user will have less chances to misconfigure.
>
> 2019-08-19 22:18 GMT+11:00, Denis Magda :
> > Dmitry G. and Igniters,
> >
> > Seems there is another issue with the metastore that is related to a
> Docker
> > environment:
> >
> https://stackoverflow.com/questions/57529702/ignite-persisting-a-set-cannot-find-metadata-for-object-with-compact-footer/57537838#57537838
> >
> > In short, this exception is generated on a restart (more details are on
> > SO):
> >
> > Cannot find metadata for object with compact footer: 2097659979
> >
> >
> > I see two ways to troubleshoot this configuration and usability issue:
> >
> >1. To provide a self-explanatory exception so that the users can fix
> the
> >configuration error easily, like "... This exception can happen if
> >IGNITE_WORK dir points out to a folder that can be or remounted on
> > restarts"
> >2. Create a special documentation section explaining how to set
> >IGNITE_WORK dir for virtualized environments.
> >
> > Does this sound right? Any better, probably automatic solution?
> > -
> > Denis
> >
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Dmitriy Pavlov]

Absolutely, error messages are the most important guidance for users, I see
no reason to reject.

пн, 26 авг. 2019 г. в 23:26, Denis Magda :

> Dmitry,
>
> As long as the vote has been canceled and we're going to do several
> improvements before starting a new one, I'd like to ask your permission to
> include this ticket in 2.7.6 scope:
> https://issues.apache.org/jira/browse/IGNITE-12106
>
> It suggests the changes in log messages to simplify "binary metadata not
> found"-class issues troubleshooting with the community involvement.
> Presently, users stumble upon the issue frequently and can't come around it
> w/o reaching us out. More details are here:
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Metastore-disappears-in-Docker-on-restarts-td43107.html
>
> -
> Denis
>
>
> On Tue, Aug 20, 2019 at 8:00 AM Artem Budnikov <
> a.budnikov.ign...@gmail.com>
> wrote:
>
> > Hi Dmitry,
> >
> > The release notes reviewed. Please see my comment in the pull request.
> >
> > -Artem
> >
> > On 19.08.2019 14:20, Dmitriy Pavlov wrote:
> > > Hi Andrey,
> > >
> > > could you please take a look at
> > > https://issues.apache.org/jira/browse/IGNITE-12061 ?
> > >
> > > Are you comfortable with merging it to release (in rush mode)?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > вс, 18 авг. 2019 г. в 18:12, Dmitriy Pavlov :
> > >
> > >> Hi Igniters,
> > >>
> > >> please review release notes for Ignite 2.7.6 (-rc0), tickets:
> > >> https://issues.apache.org/jira/issues/?jql=labels%20%3D%202.7.6-rc0 :
> > >>
> > >> Text version:
> > >> https://github.com/apache/ignite/pull/6788/files
> > >>
> > >> And corresponding HTML version (will be available at SVN once vote
> > passes):
> > >>
> > >> - Ignite work directory is set to current user's home directory by
> > >> default, native persistence files aren't stored in Temp anymore
> > >> [#IGNITE-12057] <
> https://issues.apache.org/jira/browse/IGNITE-12057
> > >
> > >> - Fixed the bug when SELECT with an equality predicate on the part
> > of
> > >> a primary compound key returned a single row result while multiple
> > matching
> > >> rows existed in the table [#IGNITE-12068]
> > >> 
> > >> - Fixed data corruption in the rare case when page replacement can
> > >> reload an outdated page during checkpoint [#IGNITE-12081]
> > >> 
> > >> - Fixed tree corruption caused by incorrect row size calculation
> for
> > >> shared cache groups [#IGNITE-12060]
> > >> 
> > >> - Java heap footprint reduced by optimizing
> > >> GridDhtPartitionsFullMessage maps in exchange history
> > [#IGNITE-11767]
> > >> 
> > >> - .NET: Fix for native persistence, now it works with custom
> > affinity
> > >> function [#IGNITE-10451]
> > >> 
> > >>
> > >>
> > >> For remained tickets
> > >>
> > >>
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.7.6%20and%20(labels%20!%3D%202.7.6-rc0%20or%20labels%20is%20EMPTY%20)
> > >>
> > >> please add desired release note as a comment (since I still not asked
> > >> Infra about a separate field).
> > >>
> > >> Sincerely,
> > >> Dmitriy Pavlov
> > >>
> > >> вс, 18 авг. 2019 г. в 12:59, Dmitriy Pavlov :
> > >>
> > >>> Ok, Ivan, thank you for sharing this bit of info. I always prefer to
> > >>> avoid any rush. It may be reasonable to wait for 2.8 or maybe we'll
> > decide
> > >>> to do 2.7.7. As the release is a trigger for activity in the
> > community, it
> > >>> is always better to prepare releases.
> > >>>
> > >>> BTW, minor correction: ticket mentioned here as IGNITE-12507
> > >>> (Persistence files are stored to temp dir) has
> > >>> actually is https://issues.apache.org/jira/browse/IGNITE-12057
> Anyway,
> > >>> thanks to Anton K. & Dmitriy G., is already in the release branch.
> > >>>
> > >>> вс, 18 авг. 2019 г. в 06:27, Ivan Pavlukhina :
> > >>>
> >  Zhenya, Dmitriy,
> > 
> > >>> hi Dmitriy, Ivan Pavlukhin suggest to exclude IGNITE-12061 from
> >  2.7.6, i
> > >>> have no clue - why,
> >  The reason here is a lack of time to ensure that everything is fine
> >  there. The patch is valuable but not so trivial. Honestly, I find it
> > wrong
> >  to merge a changes I am not sure with (yet). Especially in a hurry.
> > 
> >  Sent from my iPhone
> > 
> > > On 17 Aug 2019, at 13:13, Zhenya Stanilovsky
> >   wrote:
> > > I hope there is no data loss here, but index tree corruption can be
> >  easily obtained.
> > > Impact: someone believe that inline_size has been changed due to
> > index
> >  recreation but that`s not so.
> > >> Hi Evgeniy,
> > >>
> > >> I can't review this change. We need approve of a