Re: [DISCUSSION] New Ignite settings for IGNITE-12438 and IGNITE-13013

[Raymond Wilson]

Thanks Ivan and Denis for clarifying things.

I think we are in good shape :)

Thanks,
Raymond


On Tue, Jun 30, 2020 at 10:29 AM Denis Magda  wrote:

> Hi Raymond,
>
> You will not come across any internode-communication issues with your
> deployment configuration as long as the servers and clients are running
> withing the K8 environment.
>
> The issue, discussed here, takes place if one of the following happens:
>
>- The clients are deployed in K8 while the servers are running on
>virtual machines (or vice versa).
>- A serverless function attempts to use a thick client that by the
>current design creates a ServerSocket connection:
>https://issues.apache.org/jira/browse/IGNITE-13013
>
> As for the continuous queries, I have the following use case that can
> easily fail. Let's say your 10 servers are running on virtual machines
> while a thick client is managed by K8. The client registers a CQ in the
> cluster and all 10 servers at some point in time will need to send an
> update notification to the client. To do that, they have to open a
> connection with the client, and here the things can fall apart.
>
> -
> Denis
>
>
> On Fri, Jun 26, 2020 at 11:54 PM Raymond Wilson <
> raymond_wil...@trimble.com>
> wrote:
>
> > I have just caught up with this discussion and wanted to outline a set of
> > use
> > cases we have that rely on server nodes communicating with client nodes.
> >
> > Firstly, I'd like to confirm my mental model of server & client nodes
> > within
> > a grid (ignoring thin clients for now):
> >
> > A grid contains a set of nodes somewhat arbitrarily labelled 'server' and
> > 'client' where the distinction of a 'server' node is that it is
> responsible
> > for containing data (in-memory only, or also with persistence). Apart
> from
> > that distinction, all nodes are essentially peers in the grid and may use
> > the messaging fabric, compute layer and other grid features on an equal
> > footing.
> >
> > In our solution we leverage these capabilities to build and orchestrate
> > complex analytics queries that utilise compute functions that are
> initiated
> > in three distinct ways: client -> client, client -> server and server ->
> > client, and where all three styles of initiation are using within a
> single
> > analytics request made to the grid it self. I can go into more detail
> about
> > the exact sequencing of these activities if you like, but it may be
> > sufficient to know they are used to reason about the problem statement
> and
> > proposals outlined here.
> >
> > Our infrastructure is deployed to Kubernetes using EKS on AWS, and all
> > three
> > relationships between client and server nodes noted above function well
> > (caveat: we do see odd things though such as long pauses on critical
> worker
> > threads, and occasional empty topology warnings when locating client
> nodes
> > to send requests to). We also use continuous queries in three contexts
> (all
> > within server nodes).
> >
> > If this thread is suggesting changing the functional relationship between
> > server and client nodes then this may have impacts on our architecture
> and
> > implementation that we will need to consider.
> >
> > This thread has highlighted issues with K8s deployments and also CQ
> issues.
> > The suggestion is that Server to Client just doesn't work on K8s, which
> > does
> > not agree with our experience of it working. I'd also like to understand
> > better the bounds of the issue with CQ: When does it not work and what
> are
> > the symptoms we would see if there was an issue with the way we are using
> > it, or the K8s infrastructure we deploy to?
> >
> > Thanks,
> > Raymond.
> >
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >
>


-- 

Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand
+64-21-2013317 Mobile
raymond_wil...@trimble.com

[DISCUSSION] Tracing: IGNITE-13060

[Alexander Lapin]

Hello Igniters,

I'd like to discuss with you and then donate changes related to IGNITE-13060

In very brief it's an initial tracing implementation that allows to thrace
Communication, Exchange, Discovery and Transactions. Spi concept is used
with OpenCensus as one of implementations. For more details about tracing
engine, tracing configuration, etc please see IEP-48
.

Best regards,
Alexander

[jira] [Created] (IGNITE-13197) Add ImportOrder rule to checkstyle

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-13197:


 Summary: Add ImportOrder rule to checkstyle
 Key: IGNITE-13197
 URL: https://issues.apache.org/jira/browse/IGNITE-13197
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov


We should add automatic check for check for the import order as specified by 
the coding guidelines

 

https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-PackageImporting



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Partitioned mode issue

[Toni Mateu Sanchez]

I have this scenario:

1 Cluster with 2 server nodes and 1 cache configured with partitioned mode.
Also 1 client node for consuming the data.

With this settings, if I try to recover all the data with the client node I
lose
some information, for example if I have A, B, C and D data I recover only A
and B.

But if I have the same scenario with just 1 server node, I recover all data.

Why? Some miss settings? I need backups for partitined mode?

Thanks in advance.



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

IEP-50 Thin Client Continuous Queries

[Pavel Tupitsyn]

Igniters,

Let's discuss Thin Client Continuous Queries,
I've prepared an IEP [1] and a PoC [2].

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-50%3A+Thin+Client+Continuous+Queries

[2] https://github.com/apache/ignite/pull/7966

Re: [DISCUSSION] Ignite integration testing framework.

[Anton Vinogradov]

Folks,
First, I've created PR [1] with ducktests improvements

PR contains the following changes
- Pme-free switch proof-benchmark (2.7.6 vs master)
- Ability to check (compare with) previous releases (eg. 2.7.6 & 2.8)
- Global refactoring
-- benchmarks javacode simplification
-- services python and java classes code deduplication
-- fail-fast checks for java and python (eg. application should explicitly
write it finished with success)
-- simple results extraction from tests and benchmarks
-- javacode now configurable from tests/benchmarks
-- proper SIGTERM handling at javacode (eg. it may finish last operation
and log results)
-- docker volume now marked as delegated to increase execution speed for
mac & win users
-- Ignite cluster now start in parallel (start speed-up)
-- Ignite can be configured at test/benchmark
- full and module assembly scripts added

Second, I'd like to propose to accept ducktests [2] (ducktape integration)
as a target "PoC check & real topology benchmarking tool".

Ducktape pros
- Developed for distributed system by distributed system developers.
- Developed since 2014, stable.
- Proven usability by usage at Kafka.
- Dozens of dozens tests and benchmarks at Kafka as a great example pack.
- Built-in Docker support for rapid development and checks.
- Great for CI automation.

As an additional motivation, at least 3 teams
- IEP-45 team (to check crash-recovery speed-up (discovery and Zabbix
speed-up))
- Ignite SE Plugins team (to check plugin's features does not slow-down or
broke AI features)
- Ignite SE QA team (to append already developed smoke/load/failover tests
to AI codebase)
now, wait for ducktest merge to start checking cases they working on in AI
way.

Thoughts?

[1] https://github.com/apache/ignite/pull/7967
[2] https://github.com/apache/ignite/tree/ignite-ducktape

On Tue, Jun 16, 2020 at 12:22 PM Nikolay Izhikov 
wrote:

> Hello, Maxim.
>
> Thank you for so detailed explanation.
>
> Can we put the content of this discussion somewhere on the wiki?
> So It doesn’t get lost.
>
> I divide the answer in several parts. From the requirements to the
> implementation.
> So, if we agreed on the requirements we can proceed with the discussion of
> the implementation.
>
> 1. Requirements:
>
> The main goal I want to achieve is *reproducibility* of the tests.
> I’m sick and tired with the zillions of flaky, rarely failed, and almost
> never failed tests in Ignite codebase.
> We should start with the simplest scenarios that will be as reliable as
> steel :)
>
> I want to know for sure:
>   - Is this PR makes rebalance quicker or not?
>   - Is this PR makes PME quicker or not?
>
> So, your description of the complex test scenario looks as a next step to
> me.
>
> Anyway, It’s cool we already have one.
>
> The second goal is to have a strict test lifecycle as we have in JUnit and
> similar frameworks.
>
> > It covers production-like deployment and running a scenarios over a
> single database instance.
>
> Do you mean «single cluster» or «single host»?
>
> 2. Existing tests:
>
> > A Combinator suite allows to run set of operations concurrently over
> given database instance.
> > A Consumption suite allows to run a set production-like actions over
> given set of Ignite/GridGain versions and compare test metrics across
> versions
> > A Yardstick suite
> > A Stress suite that simulates hardware environment degradation
> > An Ultimate, DR and Compatibility suites that performs functional
> regression testing
> > Regression
>
> Great news that we already have so many choices for testing!
> Mature test base is a big +1 for Tiden.
>
> 3. Comparison:
>
> > Criteria: Test configuration
> > Ducktape: single JSON string for all tests
> > Tiden: any number of YaML config files, command line option for
> fine-grained test configuration, ability to select/modify tests behavior
> based on Ignite version.
>
> 1. Many YAML files can be hard to maintain.
> 2. In ducktape, you can set parameters via «—parameters» option. Please,
> take a look at the doc [1]
>
> > Criteria: Cluster control
> > Tiden: additionally can address cluster as a whole and execute remote
> commands in parallel.
>
> It seems we implement this ability in the PoC, already.
>
> > Criteria: Test assertions
> > Tiden: simple asserts, also few customized assertion helpers.
> > Ducktape: simple asserts.
>
> Can you, please, be more specific.
> What helpers do you have in mind?
> Ducktape has an asserts that waits for logfile messages or some process
> finish.
>
> > Criteria: Test reporting
> > Ducktape: limited to its own text/HTML format
>
> Ducktape have
> 1. Text reporter
> 2. Customizable HTML reporter
> 3. JSON reporter.
>
> We can show JSON with the any template or tool.
>
> > Criteria: Provisioning and deployment
> > Ducktape: can provision subset of hosts from cluster for test needs.
> However, that means, that test can’t be scaled without test code changes.
> Does not do any deploy, relies on external means, e.g. pre-packaged in
> d

[CODESTYLE] Import order

[Nikolay Izhikov]

Hello, Igniters.

For now, we don’t have checkstyle rule to force import order codestyle [1]
Therefore there is many violations of this rule in current codebase.

Moreover, during review, I saw many not related changes regarding import 
reorder.

I’ve prepared a PR to fix this [2]

It contains:

a. New checkstyle rule to check import order.
b. Fix of import order violations.

To match Ignite code style import orders you may want to setup Intellij IDEA 
equal to screenshot [3]

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-PackageImporting
[2] https://github.com/apache/ignite/pull/7978
[3] https://yadi.sk/i/kyXSE5rDc3ePOA

Re: [CODESTYLE] Import order

[Pavel Tupitsyn]

Hello Nikolay,

Can we put those IDEA settings to git, so everyone has them automatically?
I know Rider has this feature for C# code (team-shared settings), surely
IDEA has it too?


On Tue, Jun 30, 2020 at 5:39 PM Nikolay Izhikov  wrote:

> Hello, Igniters.
>
> For now, we don’t have checkstyle rule to force import order codestyle [1]
> Therefore there is many violations of this rule in current codebase.
>
> Moreover, during review, I saw many not related changes regarding import
> reorder.
>
> I’ve prepared a PR to fix this [2]
>
> It contains:
>
> a. New checkstyle rule to check import order.
> b. Fix of import order violations.
>
> To match Ignite code style import orders you may want to setup Intellij
> IDEA equal to screenshot [3]
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-PackageImporting
> [2] https://github.com/apache/ignite/pull/7978
> [3] https://yadi.sk/i/kyXSE5rDc3ePOA

Re: [DISCUSSION] Ignite.C++ and CMake

[Ivan Daschinsky]

Ok, CMake now is the only option to build C++ on non-windows platforms.
Autotools is removed from master.

Many thanks to Igor Sapego, Zhenya Stanilovsky, Nickolay Izhikov and Ilya
Kasnacheev for review, testing and suggestions.

вт, 23 июн. 2020 г. в 18:42, Ivan Daschinsky :

> I suppose, that removal of autotools from source code is a question of a
> week. There is no need to support it.
>
> вт, 23 июн. 2020 г., 18:38 Ilya Kasnacheev :
>
>> Hello!
>>
>> Once you do that, I think it would make sense to remove autotools
>> invocation from artifact build process. In the future we may choose to
>> remove autotools support entirely.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> вт, 23 июн. 2020 г. в 18:00, Petr Ivanov :
>>
>> > That host was down for some time and got up only recently.
>> > Installed cmake there also.
>> >
>> >
>> >
>> > > On 23 Jun 2020, at 17:39, Ivan Daschinsky 
>> wrote:
>> > >
>> > > Petr, I see, that cmake is missing on aitc10_05 but it is in pool and
>> > > trying to run build.
>> > >
>> > > [1] --
>> > >
>> >
>> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCPPCMakeLinux/5412025
>> > >
>> > > вт, 23 июн. 2020 г. в 17:33, Ivan Daschinsky :
>> > >
>> >  For the sake of discretion, I'd purpose to remove old suites from
>> Run
>> > >> All and archive or pause them for some time before removal.
>> > >> Agree, I was talking about removal from RunAll chain, complete
>> removal
>> > is
>> > >> not necessary.
>> > >> But after private discussion with Igor Sapego, me and he decided to
>> wait
>> > >> for a week before exclusion of these suites from RunAll.
>> > >>
>> > >> вт, 23 июн. 2020 г. в 17:21, Petr Ivanov :
>> > >>
>> > >>> For the sake of discretion, I'd purpose to remove old suites from
>> Run
>> > All
>> > >>> and archive or pause them for some time before removal.
>> > >>>
>> > >>>
>> >  On 23 Jun 2020, at 13:26, Nikolay Izhikov 
>> > wrote:
>> > 
>> > > So, folks, is it ok to remove old suites from build chain
>> > 
>> >  +1 from me.
>> > 
>> > 
>> > > 23 июня 2020 г., в 13:15, Ivan Daschinsky 
>> > >>> написал(а):
>> > >
>> > > Well, new suites added to RunAll and all seems to be ok.
>> > >
>> > > I think it is time to remove old suites.
>> > > WDYT?
>> > >
>> > > Also, I created patch with removal of autotools, but old suites
>> > should
>> > >>> be
>> > > removed first.
>> > >
>> > > So, folks, is it ok to remove old suites from build chain?
>> > >
>> > > вт, 23 июн. 2020 г. в 10:36, Ivan Daschinsky > >:
>> > >
>> > >> Ok, I changed agents requirements to builds and add them to
>> runAll
>> > >>
>> > >> пн, 22 июн. 2020 г. в 22:39, Petr Ivanov :
>> > >>
>> > >>> Cmake is installed on all agents (except 10 which is currently
>> down
>> > >>> and
>> > >>> will be updated later).
>> > >>>
>> > >>>
>> >  On 22 Jun 2020, at 21:03, Ivan Daschinsky > >
>> > >>> wrote:
>> > 
>> >  Well, patch is merged. Thank a lot to Igor Sapego for review.
>> > 
>> >  Peter, well, cmake now can be installed on all agent.
>> > 
>> >  I think it's time to add cmake suites to runAll and exclude old
>> > >>> suites
>> > >>> from
>> >  it.
>> > 
>> >  Patch with removing autotools I Will submit in few days.
>> > 
>> >  пн, 22 июн. 2020 г., 20:25 Ivan Daschinsky <
>> ivanda...@gmail.com>:
>> > 
>> > > Hi folks!
>> > >
>> > > Good news -- I successfully created 2 CMake suites [1] [2] and
>> > they
>> > >>> works
>> > > as a charm.
>> > > Many thanks to Ilya Kasnacheev for giving me permissions and
>> to
>> > >>> Peter
>> > > Ivanov for installing cmake and giving a whole agent for
>> testing.
>> > >
>> > > [1] --
>> > >
>> > >>>
>> > >>>
>> >
>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCPPCMakeLinuxClang&branch_IgniteTests24Java8=pull%2F7854%2Fhead&tab=buildTypeStatusDiv
>> > > [2] --
>> > >
>> > >>>
>> > >>>
>> >
>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCPPCMakeLinux&branch_IgniteTests24Java8=pull%2F7854%2Fhead&tab=buildTypeStatusDiv
>> > >
>> > > пн, 22 июн. 2020 г. в 12:03, Ilya Kasnacheev <
>> > >>> ilya.kasnach...@gmail.com>:
>> > >
>> > >> Hello!
>> > >>
>> > >> I think you should contact Peter Ivanov if you want anything
>> to
>> > be
>> > >> installed on agents.
>> > >>
>> > >> Regards,
>> > >> --
>> > >> Ilya Kasnacheev
>> > >>
>> > >>
>> > >> пн, 22 июн. 2020 г. в 12:00, Ivan Daschinsky <
>> > ivanda...@gmail.com
>> >  :
>> > >>
>> > >>> Actually, I'm going to create 2 new suites based on existing
>> > >>> ones:
>> > >>> 

Re: [CODESTYLE] Import order

[Nikolay Izhikov]

Hello, Pavel.

> Can we put those IDEA settings to git

Yes we can.
Ignite_codeStyle.xml updated to follow correct import order.

> 30 июня 2020 г., в 18:11, Pavel Tupitsyn  написал(а):
> 
> Hello Nikolay,
> 
> Can we put those IDEA settings to git, so everyone has them automatically?
> I know Rider has this feature for C# code (team-shared settings), surely
> IDEA has it too?
> 
> 
> On Tue, Jun 30, 2020 at 5:39 PM Nikolay Izhikov  wrote:
> 
>> Hello, Igniters.
>> 
>> For now, we don’t have checkstyle rule to force import order codestyle [1]
>> Therefore there is many violations of this rule in current codebase.
>> 
>> Moreover, during review, I saw many not related changes regarding import
>> reorder.
>> 
>> I’ve prepared a PR to fix this [2]
>> 
>> It contains:
>> 
>> a. New checkstyle rule to check import order.
>> b. Fix of import order violations.
>> 
>> To match Ignite code style import orders you may want to setup Intellij
>> IDEA equal to screenshot [3]
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-PackageImporting
>> [2] https://github.com/apache/ignite/pull/7978
>> [3] https://yadi.sk/i/kyXSE5rDc3ePOA

Re: [DISCUSSION] Ignite.C++ and CMake

[Pavel Tupitsyn]

This is awesome, thanks everyone!

I've tried following the instructions, and the following two steps seem to
be misleading:
* mkdir cmake-build-[release|debug]
* cd ./cmake-build-[release|debug]

When I run cmake in the newly created cmake-build-debug dir, I get:
CMake Error: The source directory
"/home/pavel/w/ignite/modules/platforms/cpp/cmake-build-release" does not
appear to contain CMakeLists.txt.

If I skip those 2 steps, I can build Ignite C++ and run tests with ctest on
Ubuntu 20.04.


Another observation: building the project produces untracked git files.
Should we update gitignore accordingly?


Thanks,
Pavel


On Tue, Jun 30, 2020 at 9:33 PM Ivan Daschinsky  wrote:

> Ok, CMake now is the only option to build C++ on non-windows platforms.
> Autotools is removed from master.
>
> Many thanks to Igor Sapego, Zhenya Stanilovsky, Nickolay Izhikov and Ilya
> Kasnacheev for review, testing and suggestions.
>
> вт, 23 июн. 2020 г. в 18:42, Ivan Daschinsky :
>
> > I suppose, that removal of autotools from source code is a question of a
> > week. There is no need to support it.
> >
> > вт, 23 июн. 2020 г., 18:38 Ilya Kasnacheev :
> >
> >> Hello!
> >>
> >> Once you do that, I think it would make sense to remove autotools
> >> invocation from artifact build process. In the future we may choose to
> >> remove autotools support entirely.
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> вт, 23 июн. 2020 г. в 18:00, Petr Ivanov :
> >>
> >> > That host was down for some time and got up only recently.
> >> > Installed cmake there also.
> >> >
> >> >
> >> >
> >> > > On 23 Jun 2020, at 17:39, Ivan Daschinsky 
> >> wrote:
> >> > >
> >> > > Petr, I see, that cmake is missing on aitc10_05 but it is in pool
> and
> >> > > trying to run build.
> >> > >
> >> > > [1] --
> >> > >
> >> >
> >>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCPPCMakeLinux/5412025
> >> > >
> >> > > вт, 23 июн. 2020 г. в 17:33, Ivan Daschinsky :
> >> > >
> >> >  For the sake of discretion, I'd purpose to remove old suites from
> >> Run
> >> > >> All and archive or pause them for some time before removal.
> >> > >> Agree, I was talking about removal from RunAll chain, complete
> >> removal
> >> > is
> >> > >> not necessary.
> >> > >> But after private discussion with Igor Sapego, me and he decided to
> >> wait
> >> > >> for a week before exclusion of these suites from RunAll.
> >> > >>
> >> > >> вт, 23 июн. 2020 г. в 17:21, Petr Ivanov :
> >> > >>
> >> > >>> For the sake of discretion, I'd purpose to remove old suites from
> >> Run
> >> > All
> >> > >>> and archive or pause them for some time before removal.
> >> > >>>
> >> > >>>
> >> >  On 23 Jun 2020, at 13:26, Nikolay Izhikov 
> >> > wrote:
> >> > 
> >> > > So, folks, is it ok to remove old suites from build chain
> >> > 
> >> >  +1 from me.
> >> > 
> >> > 
> >> > > 23 июня 2020 г., в 13:15, Ivan Daschinsky 
> >> > >>> написал(а):
> >> > >
> >> > > Well, new suites added to RunAll and all seems to be ok.
> >> > >
> >> > > I think it is time to remove old suites.
> >> > > WDYT?
> >> > >
> >> > > Also, I created patch with removal of autotools, but old suites
> >> > should
> >> > >>> be
> >> > > removed first.
> >> > >
> >> > > So, folks, is it ok to remove old suites from build chain?
> >> > >
> >> > > вт, 23 июн. 2020 г. в 10:36, Ivan Daschinsky <
> ivanda...@gmail.com
> >> >:
> >> > >
> >> > >> Ok, I changed agents requirements to builds and add them to
> >> runAll
> >> > >>
> >> > >> пн, 22 июн. 2020 г. в 22:39, Petr Ivanov  >:
> >> > >>
> >> > >>> Cmake is installed on all agents (except 10 which is currently
> >> down
> >> > >>> and
> >> > >>> will be updated later).
> >> > >>>
> >> > >>>
> >> >  On 22 Jun 2020, at 21:03, Ivan Daschinsky <
> ivanda...@gmail.com
> >> >
> >> > >>> wrote:
> >> > 
> >> >  Well, patch is merged. Thank a lot to Igor Sapego for review.
> >> > 
> >> >  Peter, well, cmake now can be installed on all agent.
> >> > 
> >> >  I think it's time to add cmake suites to runAll and exclude
> old
> >> > >>> suites
> >> > >>> from
> >> >  it.
> >> > 
> >> >  Patch with removing autotools I Will submit in few days.
> >> > 
> >> >  пн, 22 июн. 2020 г., 20:25 Ivan Daschinsky <
> >> ivanda...@gmail.com>:
> >> > 
> >> > > Hi folks!
> >> > >
> >> > > Good news -- I successfully created 2 CMake suites [1] [2]
> and
> >> > they
> >> > >>> works
> >> > > as a charm.
> >> > > Many thanks to Ilya Kasnacheev for giving me permissions and
> >> to
> >> > >>> Peter
> >> > > Ivanov for installing cmake and giving a whole agent for
> >> testing.
> >> > >
> >> > > [1] --
> >> > >
> >> > >>>
> >> > >>>
> >> >
> >>
> https://ci.ignite.apache.org/vie

Re: Partitioned mode issue

[Denis Magda]

Hi Toni,

With partitioned caches, a node keeps a subset of your data. You need to
have at least one backup copy configured. Refer to this resource that
explains the partitioning with clarity:
https://www.gridgain.com/docs/latest/developers-guide/data-modeling/data-partitioning

-
Denis


On Tue, Jun 30, 2020 at 3:17 AM Toni Mateu Sanchez <
antonio.ma...@globalia-corp.com> wrote:

> I have this scenario:
>
> 1 Cluster with 2 server nodes and 1 cache configured with partitioned mode.
> Also 1 client node for consuming the data.
>
> With this settings, if I try to recover all the data with the client node I
> lose
> some information, for example if I have A, B, C and D data I recover only A
> and B.
>
> But if I have the same scenario with just 1 server node, I recover all
> data.
>
> Why? Some miss settings? I need backups for partitined mode?
>
> Thanks in advance.
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Re: Website link update

[18624049226]

Hi community,

The current site of the Chinese version of the document is 
https://liyuj.gitee.io , this site will stop maintenance in the future.


The new site is located at https://www.ignite-service.cn/doc/java, is 
there anyone in the community can help with the change in 
https://ignite.apache.org/docs-and-apis.html?


在 2019/3/4 下午7:33, Dmitriy Pavlov 写道:

Hi Denis,

Could you please chime in? I had not practiced website updates yet.

Sincerely,
Dmitriy Pavlov

сб, 2 мар. 2019 г. в 04:34, 李玉珏 <18624049...@163.com>:


Hi,

As for Ignite's chinese document, it was previously located on a cloud
note-taking page with the address of:

https://www.zybuluo.com/liyuj/note/230739

Because of the limited functionality and user experience, it has been
migrated to the following address:

https://liyuj.gitee.io

The new site has a much better look and experience than it used to be.


Can someone help me modify the link on ignite. apache. org?
Thank you very much.

Re: [DISCUSSION] Ignite.C++ and CMake

[Ivan Daschinsky]

Pavel, pay attention to two dots at the end. All build files should stay at
current dir, and cmake-build-release is supposed to be a build root. And
this directory is added to gitignore. Actually, build directory can be
everywhere, but you should pass path to dir, that contains root
CMakeLists.txt. Usually it is parent directory of cmake-build-release, so
double dot is used. It is so common pattern of usage and I simply cannot
understand why it is misleading.

ср, 1 июл. 2020 г., 0:48 Pavel Tupitsyn :

> This is awesome, thanks everyone!
>
> I've tried following the instructions, and the following two steps seem to
> be misleading:
> * mkdir cmake-build-[release|debug]
> * cd ./cmake-build-[release|debug]
>
> When I run cmake in the newly created cmake-build-debug dir, I get:
> CMake Error: The source directory
> "/home/pavel/w/ignite/modules/platforms/cpp/cmake-build-release" does not
> appear to contain CMakeLists.txt.
>
> If I skip those 2 steps, I can build Ignite C++ and run tests with ctest on
> Ubuntu 20.04.
>
>
> Another observation: building the project produces untracked git files.
> Should we update gitignore accordingly?
>
>
> Thanks,
> Pavel
>
>
> On Tue, Jun 30, 2020 at 9:33 PM Ivan Daschinsky 
> wrote:
>
> > Ok, CMake now is the only option to build C++ on non-windows platforms.
> > Autotools is removed from master.
> >
> > Many thanks to Igor Sapego, Zhenya Stanilovsky, Nickolay Izhikov and Ilya
> > Kasnacheev for review, testing and suggestions.
> >
> > вт, 23 июн. 2020 г. в 18:42, Ivan Daschinsky :
> >
> > > I suppose, that removal of autotools from source code is a question of
> a
> > > week. There is no need to support it.
> > >
> > > вт, 23 июн. 2020 г., 18:38 Ilya Kasnacheev  >:
> > >
> > >> Hello!
> > >>
> > >> Once you do that, I think it would make sense to remove autotools
> > >> invocation from artifact build process. In the future we may choose to
> > >> remove autotools support entirely.
> > >>
> > >> Regards,
> > >> --
> > >> Ilya Kasnacheev
> > >>
> > >>
> > >> вт, 23 июн. 2020 г. в 18:00, Petr Ivanov :
> > >>
> > >> > That host was down for some time and got up only recently.
> > >> > Installed cmake there also.
> > >> >
> > >> >
> > >> >
> > >> > > On 23 Jun 2020, at 17:39, Ivan Daschinsky 
> > >> wrote:
> > >> > >
> > >> > > Petr, I see, that cmake is missing on aitc10_05 but it is in pool
> > and
> > >> > > trying to run build.
> > >> > >
> > >> > > [1] --
> > >> > >
> > >> >
> > >>
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCPPCMakeLinux/5412025
> > >> > >
> > >> > > вт, 23 июн. 2020 г. в 17:33, Ivan Daschinsky  >:
> > >> > >
> > >> >  For the sake of discretion, I'd purpose to remove old suites
> from
> > >> Run
> > >> > >> All and archive or pause them for some time before removal.
> > >> > >> Agree, I was talking about removal from RunAll chain, complete
> > >> removal
> > >> > is
> > >> > >> not necessary.
> > >> > >> But after private discussion with Igor Sapego, me and he decided
> to
> > >> wait
> > >> > >> for a week before exclusion of these suites from RunAll.
> > >> > >>
> > >> > >> вт, 23 июн. 2020 г. в 17:21, Petr Ivanov :
> > >> > >>
> > >> > >>> For the sake of discretion, I'd purpose to remove old suites
> from
> > >> Run
> > >> > All
> > >> > >>> and archive or pause them for some time before removal.
> > >> > >>>
> > >> > >>>
> > >> >  On 23 Jun 2020, at 13:26, Nikolay Izhikov  >
> > >> > wrote:
> > >> > 
> > >> > > So, folks, is it ok to remove old suites from build chain
> > >> > 
> > >> >  +1 from me.
> > >> > 
> > >> > 
> > >> > > 23 июня 2020 г., в 13:15, Ivan Daschinsky <
> ivanda...@gmail.com>
> > >> > >>> написал(а):
> > >> > >
> > >> > > Well, new suites added to RunAll and all seems to be ok.
> > >> > >
> > >> > > I think it is time to remove old suites.
> > >> > > WDYT?
> > >> > >
> > >> > > Also, I created patch with removal of autotools, but old
> suites
> > >> > should
> > >> > >>> be
> > >> > > removed first.
> > >> > >
> > >> > > So, folks, is it ok to remove old suites from build chain?
> > >> > >
> > >> > > вт, 23 июн. 2020 г. в 10:36, Ivan Daschinsky <
> > ivanda...@gmail.com
> > >> >:
> > >> > >
> > >> > >> Ok, I changed agents requirements to builds and add them to
> > >> runAll
> > >> > >>
> > >> > >> пн, 22 июн. 2020 г. в 22:39, Petr Ivanov <
> mr.wei...@gmail.com
> > >:
> > >> > >>
> > >> > >>> Cmake is installed on all agents (except 10 which is
> currently
> > >> down
> > >> > >>> and
> > >> > >>> will be updated later).
> > >> > >>>
> > >> > >>>
> > >> >  On 22 Jun 2020, at 21:03, Ivan Daschinsky <
> > ivanda...@gmail.com
> > >> >
> > >> > >>> wrote:
> > >> > 
> > >> >  Well, patch is merged. Thank a lot to Igor Sapego for
> review.
> > >> > 
> > >> >  Peter, well, cmake now can be installed on all agent.
> > >> > 
> > >> > 

Re: Website link update

[Denis Magda]

Hi,

I've updated the documentation URL. Thanks a lot for maintaining the
Chinese version throughout the years. Hope local application developers
appreciate your efforts!

-
Denis


On Tue, Jun 30, 2020 at 5:03 PM 18624049226 <18624049...@163.com> wrote:

> Hi community,
>
> The current site of the Chinese version of the document is
> https://liyuj.gitee.io , this site will stop maintenance in the future.
>
> The new site is located at https://www.ignite-service.cn/doc/java, is
> there anyone in the community can help with the change in
> https://ignite.apache.org/docs-and-apis.html?
>
> 在 2019/3/4 下午7:33, Dmitriy Pavlov 写道:
> > Hi Denis,
> >
> > Could you please chime in? I had not practiced website updates yet.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > сб, 2 мар. 2019 г. в 04:34, 李玉珏 <18624049...@163.com>:
> >
> >> Hi,
> >>
> >> As for Ignite's chinese document, it was previously located on a cloud
> >> note-taking page with the address of:
> >>
> >> https://www.zybuluo.com/liyuj/note/230739
> >>
> >> Because of the limited functionality and user experience, it has been
> >> migrated to the following address:
> >>
> >> https://liyuj.gitee.io
> >>
> >> The new site has a much better look and experience than it used to be.
> >>
> >>
> >> Can someone help me modify the link on ignite. apache. org?
> >> Thank you very much.
>
>

Ignite thin client in Rust

[Valentin Kulichenko]

Igniters,

I've been learning the Rust language lately and though that creating a thin
client in Rust would be a great exercise.

I went ahead and create a prototype which currently supports only put and
get operations with primitives and strings:
https://github.com/vkulichenko/ignite-rust-client

Feedback and participation are welcome!

Do we have any Rust enthusiasts in our community?

-Val

Re: [DISCUSSION] Ignite.C++ and CMake

[Ivan Daschinsky]

Let me explain with details.

CMake is unusual from other build systems, that it can separate build root
and source root. Moreover, it is strongly discouraged to mix them.
Benefits:
1. You can have many build with different options using same source.
2. You can build project with different toolchain using same source.
3. You can build project for different platforms using same source
(cross-compilation, docker, etc.)

Common patter is:
1. Create build root.
2. Change current dir to build root.
3. Invoke cmake in build root, pointing to source root.

Usually build root is subdirectory, of source root. So, as it mentioned in
DEVNOTES.txt, usual steps are:
1. mdkir  (usually named cmake-build-[-]
2. cd 
3. cmake [-DOPTION1=VALUE1 -DOPTION2=VALUE2 ... ] .. (NB! This double dots
are important, they points to source root)

This is so common, that you can hardly find any tutorial about CMake in
google without thes double dots. This is basic of CMake.

So if you think that we should explain for C++ developers basics of the
most common build system (CMake is really very popular and nowadays usually
must for new projects),
we can add this to DEVNOTES.txt. But I think that is not necessary at all.
For example, we don't explain basics of maven, though it is not obvious at
all as it seems to us, Ignite developers.

ср, 1 июл. 2020 г. в 06:18, Ivan Daschinsky :

> Pavel, pay attention to two dots at the end. All build files should stay
> at current dir, and cmake-build-release is supposed to be a build root. And
> this directory is added to gitignore. Actually, build directory can be
> everywhere, but you should pass path to dir, that contains root
> CMakeLists.txt. Usually it is parent directory of cmake-build-release, so
> double dot is used. It is so common pattern of usage and I simply cannot
> understand why it is misleading.
>
> ср, 1 июл. 2020 г., 0:48 Pavel Tupitsyn :
>
>> This is awesome, thanks everyone!
>>
>> I've tried following the instructions, and the following two steps seem to
>> be misleading:
>> * mkdir cmake-build-[release|debug]
>> * cd ./cmake-build-[release|debug]
>>
>> When I run cmake in the newly created cmake-build-debug dir, I get:
>> CMake Error: The source directory
>> "/home/pavel/w/ignite/modules/platforms/cpp/cmake-build-release" does not
>> appear to contain CMakeLists.txt.
>>
>> If I skip those 2 steps, I can build Ignite C++ and run tests with ctest
>> on
>> Ubuntu 20.04.
>>
>>
>> Another observation: building the project produces untracked git files.
>> Should we update gitignore accordingly?
>>
>>
>> Thanks,
>> Pavel
>>
>>
>> On Tue, Jun 30, 2020 at 9:33 PM Ivan Daschinsky 
>> wrote:
>>
>> > Ok, CMake now is the only option to build C++ on non-windows platforms.
>> > Autotools is removed from master.
>> >
>> > Many thanks to Igor Sapego, Zhenya Stanilovsky, Nickolay Izhikov and
>> Ilya
>> > Kasnacheev for review, testing and suggestions.
>> >
>> > вт, 23 июн. 2020 г. в 18:42, Ivan Daschinsky :
>> >
>> > > I suppose, that removal of autotools from source code is a question
>> of a
>> > > week. There is no need to support it.
>> > >
>> > > вт, 23 июн. 2020 г., 18:38 Ilya Kasnacheev > >:
>> > >
>> > >> Hello!
>> > >>
>> > >> Once you do that, I think it would make sense to remove autotools
>> > >> invocation from artifact build process. In the future we may choose
>> to
>> > >> remove autotools support entirely.
>> > >>
>> > >> Regards,
>> > >> --
>> > >> Ilya Kasnacheev
>> > >>
>> > >>
>> > >> вт, 23 июн. 2020 г. в 18:00, Petr Ivanov :
>> > >>
>> > >> > That host was down for some time and got up only recently.
>> > >> > Installed cmake there also.
>> > >> >
>> > >> >
>> > >> >
>> > >> > > On 23 Jun 2020, at 17:39, Ivan Daschinsky 
>> > >> wrote:
>> > >> > >
>> > >> > > Petr, I see, that cmake is missing on aitc10_05 but it is in pool
>> > and
>> > >> > > trying to run build.
>> > >> > >
>> > >> > > [1] --
>> > >> > >
>> > >> >
>> > >>
>> >
>> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCPPCMakeLinux/5412025
>> > >> > >
>> > >> > > вт, 23 июн. 2020 г. в 17:33, Ivan Daschinsky <
>> ivanda...@gmail.com>:
>> > >> > >
>> > >> >  For the sake of discretion, I'd purpose to remove old suites
>> from
>> > >> Run
>> > >> > >> All and archive or pause them for some time before removal.
>> > >> > >> Agree, I was talking about removal from RunAll chain, complete
>> > >> removal
>> > >> > is
>> > >> > >> not necessary.
>> > >> > >> But after private discussion with Igor Sapego, me and he
>> decided to
>> > >> wait
>> > >> > >> for a week before exclusion of these suites from RunAll.
>> > >> > >>
>> > >> > >> вт, 23 июн. 2020 г. в 17:21, Petr Ivanov :
>> > >> > >>
>> > >> > >>> For the sake of discretion, I'd purpose to remove old suites
>> from
>> > >> Run
>> > >> > All
>> > >> > >>> and archive or pause them for some time before removal.
>> > >> > >>>
>> > >> > >>>
>> > >> >  On 23 Jun 2020, at 13:26, Nikolay Izhikov <
>> nizhi...@apache.org>
>> > >> > wrote