Re: MVCC configuration

[Dmitriy Setrakyan]

On Mon, Sep 18, 2017 at 2:39 AM, Semyon Boikov  wrote:

>
> 1. MVCC will definitely bring some performance overhead, so I think it
> should not be enabled by default, I'm going to add special flag on cache
> configuration: CacheConfiguration.isMvccEnabled.
>

Is it possible for several caches in the same cache group to have different
MVCC configuration?


> 2. In current mvcc architecture there should be some node in cluster
> assigning versions for tx updates and queries (mvcc coordinator). Mvcc
> coordinator is crucial component and it should perform as fast as possible.
> It seems we need introduce special 'dedicated mvcc coordinator' node role:
> it should not be possible to start cache on such node and it should not
> process user's compute jobs. At the same time it should be possible that
> any regular server node can become mvcc coordinator: this can be useful
> during development (no extra setup for mvcc will be needed), or support
> scenario when all dedicated coordinator nodes fail. So we need a way to
> make node a 'dedicated mvcc coordinator', we can add special flag on ignite
> configuration: IgniteConfiguration.isMvccCoordinator.
>

I agree that we need coordinator nodes, but I do not understand why can't
we reuse some cache nodes for it? Why do we need to ask user to start up
yet another type of node?

Re: MVCC configuration

[Dmitriy Setrakyan]

On Mon, Sep 18, 2017 at 4:57 AM, Vladimir Ozerov 
wrote:

> Alex,
>
> With putAll() on ATOMIC cache all bets are off, for sure.
>

Are we all in agreement that MVCC should only be enabled for transactional
caches then?

Re: Issues if -Djava.net.preferIPv4Stack=true is not set

[Dmitriy Setrakyan]

Any comments here? Do we really require IPv4 for some reason?

On Mon, Sep 18, 2017 at 9:51 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Guys,
>
> I noticed there are many issues on user forum that occur
> of -Djava.net.preferIPv4Stack=true system property is not set.
>
> Can someone explain the nature of these issues? What exactly in Ignite
> requires this system property do be set? And can this be fixed/automated
> somehow?
>
> If fix is not possible, we need to clearly document this and print out a
> warning on startup.
>
> -Val
>

[GitHub] ignite pull request #2692: Ignite gg 12788

[sk0x50]

GitHub user sk0x50 opened a pull request:

https://github.com/apache/ignite/pull/2692

Ignite gg 12788



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sk0x50/ignite ignite-gg-12788

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2692.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2692


commit d939944f84aa415099a945b720dd4cd65132f6af
Author: Alexey Kuznetsov 
Date:   2017-03-21T03:05:33Z

IGNITE-1.8.4 Manual merge with master.

commit 71c62f70df2b79f706b6cca157bccfbcea0ae5ef
Author: Alexey Kuznetsov 
Date:   2017-03-21T03:20:39Z

IGNITE-4830 Implemented better SQL errors handling.
(cherry picked from commit fbb9940)

commit 93faee3579389c5754e3b91bcd39cc88dcf39125
Author: Alexey Kuznetsov 
Date:   2017-03-21T04:07:15Z

Web Console: Update classnames.properties.

commit 45812566694d016c07b47fa589bbba612c26f824
Author: Alexey Kuznetsov 
Date:   2017-03-21T04:23:18Z

Web Console: minor fix.
(cherry picked from commit 92bce6e)

commit f4232e9557fca89065f4ee424afab940265e2d1b
Author: oleg-ostanin 
Date:   2017-03-21T12:32:33Z

IGNITE-4822 Fixed change jvm options for benchmarks

commit ab3b2926213291a45305c21e7efe066855c1342f
Author: Igor Sapego 
Date:   2017-03-21T14:47:09Z

IGNITE-4200: Added copying of the C++ binaries.

commit e0c012d977b6db13dfdf2fb8347677998287c1e4
Author: Igor Sapego 
Date:   2017-03-21T14:50:06Z

IGNITE-4200: Added copying of the C++ binaries.

commit 6e2bc4bfb0b200e59c9fc3cf4fcbd408d52acb9c
Author: Igor Sapego 
Date:   2017-03-21T14:51:40Z

IGNITE-4200: Added copying of the C++ binaries.

commit 8273e6703944ea50b229a512398ac741eb713073
Author: Anton Vinogradov 
Date:   2017-03-21T15:04:01Z

IGNITE-4779 Missed discovery data snapshot during exchange processing 
(Backport from 2.0)

commit 6775f646df127f5cdbabf7a154b65856f38afa1e
Author: Dmitriy Shabalin 
Date:   2017-03-22T03:37:05Z

IGNITE-4686 Added ability to group registered users in admin panel.

(cherry picked from commit 827befb)

commit 7d94963251cc66823883d760668c2e2b31574bf1
Author: Andrey Novikov 
Date:   2017-03-22T11:20:32Z

IGNITE-4659 Fixed error page.

(cherry picked from commit 50de012)

commit eb837c7853ffc68e5a3f690e985407e603e3f955
Author: Andrey Novikov 
Date:   2017-03-22T11:21:03Z

IGNITE-4854 Fixed project structure button on summary page under firefox.

(cherry picked from commit 117e18e)

commit 8d9ade2cc2d71f12a427e3effa3846a928b0681e
Author: dkarachentsev 
Date:   2017-03-22T11:57:24Z

Merge branch 'ignite-1.7.9-p1' into ignite-1.7.10

commit 3aa2a68c02879ec57c46091cd2f22a9ac4b129ad
Author: dkarachentsev 
Date:   2017-03-22T12:22:50Z

Merge branch 'ignite-1.7.9-p1' into ignite-1.8.5

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java

commit ec7b9d848274b229b69dc7b8a20902654f719c44
Author: Andrey Novikov 
Date:   2017-03-23T02:32:38Z

IGNITE-4855 Fixed error on switching between notebooks.

(cherry picked from commit 6a148e2)

commit 36f7621b6eaa710d3b1eba7fddd0dfe92e11133e
Author: Andrey Novikov 
Date:   2017-03-23T03:57:03Z

IGNITE-4830 Fixed error ui.

(cherry picked from commit 48e78a9)

commit 1f3b2fcd003c1f084874d5c421953da0a7cd02cb
Author: Valentin Kulichenko 
Date:   2017-03-28T01:12:17Z

IGNITE-4802 - Separate thread pool for managed services

commit 39edcc7890ce497771f532a83a57ecae318d8c88
Author: Andrey V. Mashenkov 
Date:   2017-03-28T15:56:17Z

IGNITE-4815: Fixed confusing javadoc. This closes #1613.

commit e47bf27b5582cd695a7d3de3c39d54b3df4c59cc
Author: Valentin Kulichenko 
Date:   2017-03-28T23:51:44Z

IGNITE-4762 - transactionsAllowed flag for JDBC driver

commit 336672432486830c31cb4b6f8bb1b401c276f3e5
Author: Alexey Kuznetsov 
Date:   2017-03-29T03:53:25Z

IGNITE-4659 Fixed typo.
(cherry picked from commit 6f1e970)

commit 1ddce5517815fc85136e2ead9973c8cf74054f9f
Author: Alexey Kuznetsov 
Date:   2017-03-29T04:11:33Z

Merge branch 'web-console-production' of 
https://github.com/gridgain/apache-ignite into ignite-1.8.5

commit b689624e2984ec3cf42ca5b01966937e236abcdc

Re: Ignite PDS WAL analysis with human readable records

[Dmitriy Setrakyan]

Dmitriy, can you please describe your idea in the ticket?

Here is the link for easier access:
https://issues.apache.org/jira/browse/IGNITE-6421

D.

On Mon, Sep 18, 2017 at 7:02 AM, Dmitry Pavlov 
wrote:

> Dmitriy,
>
> Thank you for your feedback I've created IGNITE-6421 for this change.
>
> Is it common practice to use property file in Ignite utils? I'd like to
> support parse and display data entries and its fields, but it is required
> to configure several folders: 'binary_meta' and 'marshaller' folders.
>
> My idea is to provide .conf file to configure reader once.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 18 сент. 2017 г. в 16:10, Dmitriy Setrakyan :
>
> > Thanks!
> >
> > After looking at the ticket, the way to launch this utility seems
> complex.
> > Does this utility have a shell script? If not, we should add one with
> > proper command line options, like we do for other scripts.
> >
> > D.
> >
> > On Mon, Sep 18, 2017 at 4:05 AM, Eduard Shangareev <
> > eduard.shangar...@gmail.com> wrote:
> >
> > > Example of output (will add to wiki):
> > >
> > > [W] InitNewPageRecord [newPageId=0001001c0067,
> super=PageDeltaRecord
> > > [grpId=2141373875, pageId=0001001c0067, super=WALRecord [size=41,
> > > chainSize=0, pos=FileWALPointer [idx=1, fileOffset=25406, len=41,
> > > forceFlush=false], type=INIT_NEW_PAGE_RECORD]]]
> > > [W] InitNewPageRecord [newPageId=0001001c0068,
> super=PageDeltaRecord
> > > [grpId=2141373875, pageId=0001001c0068, super=WALRecord [size=41,
> > > chainSize=0, pos=FileWALPointer [idx=1, fileOffset=25447, len=41,
> > > forceFlush=false], type=INIT_NEW_PAGE_RECORD]]]
> > > [W] PagesListAddPageRecord [dataPageId=0001001c002a,
> > > super=PageDeltaRecord [grpId=2141373875, pageId=0001001c0068,
> > > super=WALRecord [size=37, chainSize=0, pos=FileWALPointer [idx=1,
> > > fileOffset=25488, len=37, forceFlush=false],
> type=PAGES_LIST_ADD_PAGE]]]
> > > [W] PageSnapshot [fullPageId = FullPageId [pageId=0001001c002a,
> > > effectivePageId=001c002a, grpId=2141373875], page = [
> > > Header [
> > > type=1 (DataPageIO),
> > > ver=1,
> > > crc=0,
> > > pageId=281595235794986(offset=0, flags=1, partId=28, index=42)
> > > ],
> > > DataPageIO [
> > > 0001001c002a [4049, 4002, 3955, 3908, 3861, 3814, 3767, 3720, 3673,
> > > 3626][][free=3552, actualFree=-544
> > > ]],
> > > super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> > > fileOffset=25525, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> > > [W] InsertRecord [idx=12, io=CacheIdAwareDataLeafIO[ver=1],
> > > rightId=, super=PageDeltaRecord [grpId=2141373875,
> > > pageId=0001001c0004, super=WALRecord [size=59, chainSize=0,
> > > pos=FileWALPointer [idx=1, fileOffset=29650, len=59, forceFlush=false],
> > > type=BTREE_PAGE_INSERT]]]
> > > [W] DataRecord [writeEntries=[DataEntry [cacheId=-1368047377,
> op=CREATE,
> > > writeVer=GridCacheVersion [topVer=116892426, order=1505412445450,
> > > nodeOrder=2], partId=28, partCnt=69]], super=WALRecord [size=100,
> > > chainSize=0, pos=FileWALPointer [idx=1, fileOffset=29709, len=100,
> > > forceFlush=false], type=DATA_RECORD]]
> > > [W] PageSnapshot [fullPageId = FullPageId [pageId=0001000a,
> > > effectivePageId=000a, grpId=2141373875], page = [
> > > Header [
> > > type=20 (PagePartitionCountersIO),
> > > ver=1,
> > > crc=0,
> > > pageId=281474976710666(offset=0, flags=1, partId=0, index=10)
> > > ],
> > > PagePartitionCounters [
> > > count=1,
> > > lastFlag=true,
> > > nextCountersPageId=,
> > > size={
> > > -1368047377=313
> > > }
> > > ]],
> > > super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> > > fileOffset=29809, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> > > [W] PageSnapshot [fullPageId = FullPageId [pageId=000100020010,
> > > effectivePageId=00020010, grpId=2141373875], page = [
> > > Header [
> > > type=20 (PagePartitionCountersIO),
> > > ver=1,
> > > crc=0,
> > > pageId=281483566645264(offset=0, flags=1, partId=2, index=16)
> > > ],
> > > PagePartitionCounters [
> > > count=1,
> > > lastFlag=true,
> > > nextCountersPageId=,
> > > size={
> > > -1368047377=313
> > > }
> > > ]],
> > > super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> > > fileOffset=33934, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> > > [W] PageSnapshot [fullPageId = FullPageId [pageId=00010005000d,
> > > effectivePageId=0005000d, grpId=2141373875], page = [
> > > Header [
> > > type=20 (PagePartitionCountersIO),
> > > ver=1,
> > > crc=0,
> > > pageId=281496451547149(offset=0, flags=1, partId=5, index=13)
> > > ],
> > > PagePartitionCounters [
> > > count=1,
> > > lastFlag=true,
> > > nextCountersPageId=,
> > > size={
> > > -1368047377=313
> > > }
> > > ]],
> > > super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> > > 

[GitHub] ignite pull request #2688: IGNITE-6403 SchemaOperationManager fix

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2688


---

[GitHub] ignite pull request #2691: IGNITE-6403

[devozerov]

Github user devozerov closed the pull request at:

https://github.com/apache/ignite/pull/2691


---

[GitHub] ignite pull request #2691: IGNITE-6403

[devozerov]

GitHub user devozerov opened a pull request:

https://github.com/apache/ignite/pull/2691

IGNITE-6403



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6403-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2691.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2691


commit 9520f465c534cbd95d72ec0a3ae45b914efd047d
Author: devozerov 
Date:   2017-09-18T19:07:53Z

Attempt to fix.




---

[GitHub] ignite pull request #2684: IGNITE-6391 JDBC thin driver: remove unused JdbcT...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2684


---

[GitHub] ignite pull request #2690: IGNITE 6428: IgniteOOME in PDS Indexing test:

[dspavlov]

GitHub user dspavlov opened a pull request:

https://github.com/apache/ignite/pull/2690

IGNITE 6428: IgniteOOME in PDS Indexing test:

Experimental branch with Increase memory policy size

Don't merge, only for testing

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6428-max-size

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2690.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2690


commit ba849f566552ac31eb3f14e49eed6b15d9790895
Author: dpavlov 
Date:   2017-09-18T18:37:15Z

IGNITE-6428: IgniteOOME in PDS Indexing test: Increase memory policy size




---

[GitHub] ignite pull request #2689: IGNITE-6099: Fully implemented SQLGetInfo in ODBC...

[isapego]

GitHub user isapego opened a pull request:

https://github.com/apache/ignite/pull/2689

IGNITE-6099: Fully implemented SQLGetInfo in ODBC driver.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6099

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2689.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2689


commit d47cbcb77b287f700b337f97c9a27fe6f370f6c0
Author: Igor Sapego 
Date:   2017-08-17T17:08:46Z

IGNITE-6099: Minor refactoring

commit dbaa5307f017096499a67f4d73072f907ef8946c
Author: Igor Sapego 
Date:   2017-08-21T13:12:58Z

IGNITE-6099: Refactoring

commit 17bf12120a020c26d72d5e97ba5a19fd7299a270
Author: Igor Sapego 
Date:   2017-08-22T14:44:44Z

IGNITE-6099: More info supported

commit 3748d51aa49d3979e6a494109375946a378b34a6
Author: Igor Sapego 
Date:   2017-09-15T13:35:07Z

IGNITE-6099: Added support for more info attributes.

commit 68996edf4dae62adab6d55849169864c476a944f
Author: Igor Sapego 
Date:   2017-09-15T15:41:57Z

IGNITE-6099: Further progress.

commit c74c8db5eee0dfa83872f9500dd026d76ae9610b
Author: Igor Sapego 
Date:   2017-09-18T16:16:50Z

IGNITE-6099: Further progress.

commit bbbee5bd6fd8c606919d4a6c692329509ad17d92
Author: Igor Sapego 
Date:   2017-09-18T18:31:02Z

IGNITE-6099: Complete




---

[GitHub] ignite pull request #2688: IGNITE-6403 SchemaOperationManager fix

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

https://github.com/apache/ignite/pull/2688

IGNITE-6403 SchemaOperationManager fix

…tiated operation.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6403

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2688.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2688


commit 6a95a845056e7d509ad3fcf78738f1d59f7cc892
Author: Alexander Paschenko 
Date:   2017-09-18T18:04:57Z

IGNITE-6403 SchemaOperationManager always waits for node that has initiated 
operation.




---

[jira] [Created] (IGNITE-6430) CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime test fails periodically.

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-6430:
---

 Summary: 
CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime test fails 
periodically.
 Key: IGNITE-6430
 URL: https://issues.apache.org/jira/browse/IGNITE-6430
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Gura
 Fix For: 2.3


{{CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime}} test fails 
periodically.

{noformat}
[2017-09-18 15:18:20,073][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError: Expected less 5000, Actual:-100969
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.TestCase.assertTrue(TestCase.java:192)
at 
org.apache.ignite.internal.processors.cache.CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime(CacheGroupsMetricsRebalanceTest.java:261)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}

After fix test should be unmuted on TC.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6429) GridCachePreloadingEvictionsSelfTest.testEvictions test fails periodically

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-6429:
---

 Summary: GridCachePreloadingEvictionsSelfTest.testEvictions test 
fails periodically 
 Key: IGNITE-6429
 URL: https://issues.apache.org/jira/browse/IGNITE-6429
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Gura
 Fix For: 2.3


{{GridCachePreloadingEvictionsSelfTest.testEvictions}} test fails periodically.

{noformat}
[2017-09-18 15:35:03,054][ERROR][main][root] Test failed.
java.lang.AssertionError: Sizes do not match [s1=5136, s2=5159]
at 
org.apache.ignite.internal.processors.cache.GridCachePreloadingEvictionsSelfTest.checkCachesConsistency(GridCachePreloadingEvictionsSelfTest.java:243)
at 
org.apache.ignite.internal.processors.cache.GridCachePreloadingEvictionsSelfTest.testEvictions(GridCachePreloadingEvictionsSelfTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}

After fix test should be unmuted on TC.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Fwd: Fetched result set too large

[Denis Magda]

Vladimir,

Seems the usage hints of the flag below have to go to the performance & 
troubleshooting doc:
https://apacheignite-sql.readme.io/docs/performance-and-debugging

Could you properly add it there?

—
Denis

> Begin forwarded message:
> 
> From: Вячеслав Коптилин 
> Subject: Re: Fetched result set too large
> Date: September 18, 2017 at 7:50:32 AM PDT
> To: u...@ignite.apache.org
> Cc: wanxing...@163.com
> Reply-To: u...@ignite.apache.org
> 
> Hi Lucky,
> 
> It seems that I was wrong.
> You need to increase the value of 
> IgniteSystemProperty#IGNITE_SQL_MERGE_TABLE_MAX_SIZE [1]
> The default value is 10 000.
> 
> [1] 
> https://ignite.apache.org/releases/2.1.0/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_SQL_MERGE_TABLE_MAX_SIZE
>  
> 
> 
> Thanks.
> 
> 2017-09-12 9:50 GMT+03:00 Lucky  >:
> Hi
> I use jdbc to fetch result from cache.
>  Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
>  Connection conn = DriverManager.getConnection("jdbc:ignite:thin://IP");
>  ResultSet rs = conn.createStatement().executeQuery(sql);
> 
>   And the sql is like this:
> select v.id ,v.name ,v.seq from (selet a.id 
>  as id,b.name  as name,c.seq as seq from a 
> inner join b on a.id = b.id  left outer join c on 
> a.id =c.id ) v left outer join (select did from d 
> where cid in(Ids) group by did having count(did)>=3000) w on v.id 
>  = d.did where d.did is null 
> 
>   when 'select did from d where cid in(Ids) group by did having 
> count(did)>=3000' return few records ,this sql is work,but if it return 
> 20,000 records(actually it's often return 10 million records),it got this 
> wrong message:Fetched result set war too large.
> 
>   And the whole sql is expected 30,000 records.
>
>   Any suggestion? Thanks.
>   Lucky.
>  
> 
> 
>  
> 

[jira] [Created] (IGNITE-6428) Timed out test IgnitePdsAtomicCacheRebalancingTest.testTopologyChangesWithConstantLoad

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-6428:
--

 Summary: Timed out test 
IgnitePdsAtomicCacheRebalancingTest.testTopologyChangesWithConstantLoad
 Key: IGNITE-6428
 URL: https://issues.apache.org/jira/browse/IGNITE-6428
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Dmitriy Pavlov
Assignee: Alexey Goncharuk


IgnitePdsAtomicCacheRebalancingTest.testTopologyChangesWithConstantLoad
https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=7598445566789774358=testDetails_Ignite20Tests=%3Cdefault%3E
Test was early fixed under following issues
https://issues.apache.org/jira/browse/IGNITE-5514
https://issues.apache.org/jira/browse/IGNITE-5692
 
But now it is still failed with:
{noformat}
[2017-09-18 
00:19:02,892][ERROR][sys-stripe-22-#10154%persistence.IgnitePdsAtomicCacheRebalancingTest4%][GridCacheIoManager]
 Failed processing message [senderId=df3bec22-ebfb-4222-86d9-ab6117b1, 
msg=GridDhtAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=166, 
val=8358, hasValBytes=true], 
val=o.a.i.i.processors.cache.persistence.IgnitePdsCacheRebalancingAbstractTest$TestValue
 [idHash=595564816, hash=-2080068327, v1=866013082, v2=381254132], 
prevVal=null, super=GridDhtAtomicAbstractUpdateRequest [onRes=false, 
nearNodeId=52c634c0-6675-44eb-bf52-d2d0f010, nearFutId=588085, 
flags=hasRes]]]
class org.apache.ignite.internal.mem.IgniteOutOfMemoryException: Failed to find 
a page for eviction [segmentCapacity=2545, loaded=458, maxDirtyPages=640, 
dirtyPages=458, cpPages=0, pinnedInSegment=0, failedToPrepare=459]
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.tryToFindSequentially(PageMemoryImpl.java:1893)
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.evictPage(PageMemoryImpl.java:1817)
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.access$600(PageMemoryImpl.java:1550)
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:414)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore$1.allocatePageNoReuse(GridCacheOffheapManager.java:925)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.allocatePage(DataStructure.java:105)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.addStripe(PagesList.java:416)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.getPageForPut(PagesList.java:518)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.put(PagesList.java:618)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.FreeListImpl$RemoveRowHandler.run(FreeListImpl.java:297)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.FreeListImpl$RemoveRowHandler.run(FreeListImpl.java:264)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:277)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:223)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.FreeListImpl.removeDataRowByLink(FreeListImpl.java:526)
at 
org.apache.ignite.internal.processors.cache.persistence.RowStore.removeRow(RowStore.java:69)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1371)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1209)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1263)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:343)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1693)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3220)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:304)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:299)
at 

Issues if -Djava.net.preferIPv4Stack=true is not set

[Valentin Kulichenko]

Guys,

I noticed there are many issues on user forum that occur
of -Djava.net.preferIPv4Stack=true system property is not set.

Can someone explain the nature of these issues? What exactly in Ignite
requires this system property do be set? And can this be fixed/automated
somehow?

If fix is not possible, we need to clearly document this and print out a
warning on startup.

-Val

Re: Unintuitive error message when invalid marshaller files found

[Valentin Kulichenko]

I agree, error message should be more informative. Mike, feel free to
create a Jira ticket for this.

-Val

On Mon, Sep 18, 2017 at 12:25 AM, Michael Griggs 
wrote:

> Sure
>
> SEVERE: Exception during start processors, node will be stopped and
> close connections
> class org.apache.ignite.IgniteCheckedException: Failed to start
> processor: GridProcessorAdapter []
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(
> IgniteKernal.java:1813)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:946)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(
> IgnitionEx.java:1904)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(
> IgnitionEx.java:1646)
> at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1074)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(
> IgnitionEx.java:992)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:878)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:777)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:647)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:616)
> at org.apache.ignite.Ignition.start(Ignition.java:347)
> at com.gridgain.proserv.ServerNode.run(ServerNode.java:26)
> at com.gridgain.proserv.ServerNode.main(ServerNode.java:21)
> Caused by: class org.apache.ignite.IgniteCheckedException: Reading
> marshaller mapping from file 248380598.classname failed; last symbol
> of file name is expected to be numeric.
> at
> org.apache.ignite.internal.MarshallerMappingFileStore.getPlatformId(
> MarshallerMappingFileStore.java:186)
> at
> org.apache.ignite.internal.MarshallerMappingFileStore.restoreMappings(
> MarshallerMappingFileStore.java:153)
> at
> org.apache.ignite.internal.MarshallerContextImpl.
> onMarshallerProcessorStarted(MarshallerContextImpl.java:524)
> at
> org.apache.ignite.internal.processors.marshaller.
> GridMarshallerMappingProcessor.start(GridMarshallerMappingProcessor
> .java:114)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(
> IgniteKernal.java:1810)
> ... 12 more
> Caused by: java.lang.NumberFormatException: For input string: "e"
> at
> java.lang.NumberFormatException.forInputString(
> NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Byte.parseByte(Byte.java:149)
> at java.lang.Byte.parseByte(Byte.java:175)
> at
> org.apache.ignite.internal.MarshallerMappingFileStore.getPlatformId(
> MarshallerMappingFileStore.java:183)
> ... 16 more
>
> Sep 18, 2017 8:22:35 AM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Got exception while starting (will rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start
> processor: GridProcessorAdapter []
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(
> IgniteKernal.java:1813)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:946)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(
> IgnitionEx.java:1904)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(
> IgnitionEx.java:1646)
> at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1074)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(
> IgnitionEx.java:992)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:878)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:777)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:647)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:616)
> at org.apache.ignite.Ignition.start(Ignition.java:347)
> at com.gridgain.proserv.ServerNode.run(ServerNode.java:26)
> at com.gridgain.proserv.ServerNode.main(ServerNode.java:21)
> Caused by: class org.apache.ignite.IgniteCheckedException: Reading
> marshaller mapping from file 248380598.classname failed; last symbol
> of file name is expected to be numeric.
> at
> org.apache.ignite.internal.MarshallerMappingFileStore.getPlatformId(
> MarshallerMappingFileStore.java:186)
> at
> org.apache.ignite.internal.MarshallerMappingFileStore.restoreMappings(
> MarshallerMappingFileStore.java:153)
> at
> org.apache.ignite.internal.MarshallerContextImpl.
> onMarshallerProcessorStarted(MarshallerContextImpl.java:524)
> at
> org.apache.ignite.internal.processors.marshaller.
> GridMarshallerMappingProcessor.start(GridMarshallerMappingProcessor
> .java:114)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(
> IgniteKernal.java:1810)
> ... 12 more
> Caused by: java.lang.NumberFormatException: For input string: "e"
> at
> java.lang.NumberFormatException.forInputString(
> NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at 

[GitHub] ignite pull request #2687: IGNITE-6209 .NET: Build NuGet packages for Apache...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

https://github.com/apache/ignite/pull/2687

IGNITE-6209 .NET: Build NuGet packages for Apache-Ignite release on CI



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ptupitsyn/ignite ignite-6209

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2687.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2687


commit 29818fc3b4807570dd30995ee88f9eac39ae21ed
Author: Pavel Tupitsyn 
Date:   2017-09-14T15:49:14Z

IGNITE-6209 .NET: Build NuGet packages for Apache-Ignite release on CI

commit 2e439a2d97fe106c6cca9b04fd96cd36dffc0940
Author: Pavel Tupitsyn 
Date:   2017-09-14T15:54:08Z

skipDotNet switch added

commit ae164e88221f10f18f7be6800f5eda0a764d2a64
Author: Pavel Tupitsyn 
Date:   2017-09-14T16:24:18Z

File copy script in progress

commit f642255051ca5cabb1aeb0c89f150c1a31017b09
Author: Pavel Tupitsyn 
Date:   2017-09-14T16:29:43Z

wip

commit 5f8d5c4fb1f9acfc437f48f0f06e514d506b8914
Author: Pavel Tupitsyn 
Date:   2017-09-14T16:31:55Z

packaging works!

commit 68a6caf92167be7cf1b4d7e5de8a84c1f8f41f6e
Author: Pavel Tupitsyn 
Date:   2017-09-18T14:50:25Z

Merge branch 'master' into ignite-6209

commit a14c97ae78442b3a0e360f6894235efc36b3065c
Author: Pavel Tupitsyn 
Date:   2017-09-18T15:55:48Z

Add asmDirs to build script

commit b68e6d7d191a639d9e9891de9f17402eb509f5ed
Author: Pavel Tupitsyn 
Date:   2017-09-18T16:02:09Z

remove extra script




---

[GitHub] ignite pull request #2686: IGNITE-6427: IgniteOOME in Cache5 test: Increase ...

[dspavlov]

GitHub user dspavlov opened a pull request:

https://github.com/apache/ignite/pull/2686

IGNITE-6427: IgniteOOME in Cache5 test: Increase memory policy size



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6427

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2686.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2686


commit 241a4dfd67a734f86a431d2071c6a3c1a36119a2
Author: dpavlov 
Date:   2017-09-18T15:47:26Z

IGNITE-6427: IgniteOOME in Cache5 test: Increase memory policy size




---

[jira] [Created] (IGNITE-6427) Ignite Cache 5 suite has timed out with CacheLateAffinityAssignmentTest.testRandomOperations()

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-6427:
--

 Summary: Ignite Cache 5 suite has timed out with 
CacheLateAffinityAssignmentTest.testRandomOperations()
 Key: IGNITE-6427
 URL: https://issues.apache.org/jira/browse/IGNITE-6427
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


Ignite Cache 5 build has timed out with 
CacheLateAffinityAssignmentTest.testRandomOperations():
 
https://ci.ignite.apache.org/viewLog.html?buildId=834721=buildResultsDiv=Ignite20Tests_IgniteCache5
 
{noformat}
 [Step 4/5] [2017-09-17 22:41:23,619][INFO 
][sys-#49767%client-9%][GridDhtPartitionsExchangeFuture] Finish exchange future 
[startVer=AffinityTopologyVersion [topVer=31, minorTopVer=0], 
resVer=AffinityTopologyVersion [topVer=31, minorTopVer=0], err=null]
[01:41:23]W: [org.apache.ignite:ignite-core] [2017-09-17 
22:41:23,624][ERROR][sys-#49655%server-8%][GridDhtPartitionsExchangeFuture] 
Failed to notify listener: 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5@56f46b92
[01:41:23]W: [org.apache.ignite:ignite-core] class 
org.apache.ignite.internal.mem.IgniteOutOfMemoryException: Not enough memory 
allocated (consider increasing memory policy size or enabling evictions) 
[policyName=default, size=104.9 MB]
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.allocatePage(PageMemoryNoStoreImpl.java:292)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:806)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.createCacheDataStore0(IgniteCacheOffheapManagerImpl.java:903)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.createCacheDataStore(IgniteCacheOffheapManagerImpl.java:885)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:205)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.createPartition(GridDhtPartitionTopologyImpl.java:724)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.createPartitions(GridDhtPartitionTopologyImpl.java:423)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions0(GridDhtPartitionTopologyImpl.java:366)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:535)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:2776)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$1400(GridDhtPartitionsExchangeFuture.java:116)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:2524)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:2512)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:352)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveFullMessage(GridDhtPartitionsExchangeFuture.java:2512)
[01:41:23]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1433)
[01:41:23]W: [org.apache.ignite:ignite-core]at 

Re: ContinuousQueryWithTransformer implementation questions - 2

[Николай Ижиков]

So, resuming:

1) My solution reduces network communication.
As far as I know, a lot of people want to have this feature at Ignite 2.x.
It's impossible to gain perfect API right now, it will take months to gain
it.
My solution ready right now!, let's merge it and refactor whole Continuous
Query API at 3.0.

2) Current API is bad, and, yes, my changes make it a little bit
complicated.
But, complication minimized as possible and profit much bigger that
complication.

2017-09-18 17:39 GMT+03:00 Николай Ижиков :

> Vladimir,
>
> Here is a short summary what is wrong with continuous query
>
>
> OK.
> I agree - this is problems of current API.
>
> How we can fix it by not merging ContinuousQueryWIthTransformer?
> How we can quickly design, discuss and implement new API?
> Because at the moment there is no any ticket to start working at.
> Moreover we can't throw ContinuousQuery away until 3.0 version.
>
> > What is worse, this interface is inconsistent with JCache event
> listeners, which distinguish between create, update and delete events.
>
> Can't agree with you.
>
> 1. As far as I know jcache doesn't have any Transformer conception.
> 2. We can distinguish create, update and delete events in transformer and
> we can push that knowledge to listener.
>
>
>> What I see in your PR is that we add one more confusing concept - in
>> addition to wrongly named "local listener" now we will also have
>> "TransformedEventListener".
>>
>
> I think usage of jcache API in some Ignite-specific classes is one more
> issue of existing ContinuousQuery.
> I think we must use Ignite only API for Ignite only features and use some
> wrappers to provide external API support.
>
> For these reasons I would still prefer to think of better continuous
>> queries design first instead of making current API even more complicated.
>>
>
> I think the main reason for some feature is to provide value to the user.
> Transformers adds value to a product because usage of transformer can lead
> to significant performance win.
>
>
>> Vladimir.
>>
>> On Mon, Sep 18, 2017 at 4:04 PM, Николай Ижиков 
>> wrote:
>>
>> > Igniters,
>> >
>> > I discussed API of ContinuousQuery and ContinuousQueryWithTransformer
>> with
>> > Anton Vinogradov one more time.
>> >
>> > Since users who use regular ContinuousQuery already knows pros. and
>> cons of
>> > using initialQuery and to not to complicate API more and more until 3.0
>> we
>> > agreed that best choice is to stay with existing initialQuery that
>> return
>> > Cache.Entry for ContinuousQueryWithTransformer.
>> >
>> > Notice that initialQuery is not required and can be null.
>> >
>> > Thoughts?
>> >
>> > 2017-09-15 1:45 GMT+03:00 Denis Magda :
>> >
>> > > Vladimir,
>> > >
>> > > If the API is so bad then it might take much more time to make up and
>> > roll
>> > > out the new. Plus, there should be a community member who is ready to
>> > take
>> > > it over. My suggestion would be to accept this contribution and
>> initiate
>> > an
>> > > activity towards the new API if you like.
>> > >
>> > > Personally, I considered this API as one of the most vivid we have
>> basing
>> > > on my practical usage experience. I was aware of initial query’s
>> pitfalls
>> > > but isn’t it something we can put on paper?
>> > >
>> > > —
>> > > Denis
>> > >
>> > > > On Sep 12, 2017, at 6:04 AM, Vladimir Ozerov 
>> > > wrote:
>> > > >
>> > > > My opinion is that our query API is big piece of ... you know,
>> > especially
>> > > > ContinuousQuery. A lot of concepts and features are mixed in a
>> single
>> > > > entity, what makes it hard to understand and use. Let's finally
>> > deprecate
>> > > > ContinuousQuery and design nice and consistent API. E.g.:
>> > > >
>> > > > interface IgniteCache {
>> > > >UUID addListener(CacheEntryListener listener)
>> > > >void removeListener(UUID listenerId);
>> > > > }
>> > > >
>> > > > This method set's a listener on all nodes which will process event
>> > > locally,
>> > > > no network communication. Now if you want semantics similar to
>> existing
>> > > > continuous queries, you use special entry listener type:
>> > > >
>> > > > class ContinuousQueryCacheEntryListener implements
>> CacheEntryListener
>> > {
>> > > >ContinuousQueryRemoteFilter rmtFilter;
>> > > >ContinuousQueryRemoteTransformer rmtTransformer;
>> > > >ContinuousQueryLocalCallback locCb;
>> > > > }
>> > > >
>> > > > Last, "initial query" concept should be dropped from "continuous
>> query"
>> > > > feature completely. It doesn't guarantee any kind of atomicity or
>> > > > visibility wrt to cache events, so it adds no value. The same
>> behavior
>> > > > could be achieved as follows:
>> > > >
>> > > > cache.addListener(...)
>> > > > QueryCursor cursor = cache.query(initialQuery);
>> > > >
>> > > > Vladimir.
>> > > >
>> > > >
>> > > > On Tue, Sep 12, 2017 at 3:35 PM, Yakov Zhdanov > >
>> 

[RESULT] [VOTE] Apache Ignite 2.2.0 Release (RC2)

[Anton Vinogradov]

Igniters,

Apache Ignite 2.2.0 release (RC2) has been accepted.

4 "+1" binding votes received:

- Vladimir Ozerov
- Alexey Kuznetsov
- Andrey Novikov
- Pavel Tupitsyn

Vote thread:

http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Apache-Ignite-2-2-0-RC2-td22261.html

Ignite 2.2.0 will be released soon.

Yabba Dabba Doo!

[jira] [Created] (IGNITE-6426) Add support for variable length numbers in raw readers/writers.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-6426:
-

 Summary: Add support for variable length numbers in raw 
readers/writers.
 Key: IGNITE-6426
 URL: https://issues.apache.org/jira/browse/IGNITE-6426
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
 Fix For: 2.3


This is useful for implementing custom efficient compression.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2365: Ignite 5813 1.7

[AMashenkov]

Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/2365


---

[GitHub] ignite pull request #2676: Ignite-gg-12717

[AMashenkov]

Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/2676


---

[GitHub] ignite pull request #2685: Ignite 6355

[glukos]

GitHub user glukos opened a pull request:

https://github.com/apache/ignite/pull/2685

Ignite 6355



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6355

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2685.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2685


commit 0ca879173e9c7b58f313bddc85b0684faf8b6307
Author: Ivan Rakov 
Date:   2017-09-12T15:40:15Z

IGNITE-6355 Calculating cache size during cache stop sporadically fails 
with ClusterGroupEmptyCheckedException

commit 942652cb12c045ec6ccfaf59db23238c4cb305ae
Author: Ivan Rakov 
Date:   2017-09-18T14:36:03Z

IGNITE-6355 Calculating cache size during cache stop sporadically fails 
with ClusterGroupEmptyCheckedException




---

[jira] [Created] (IGNITE-6425) Races during transaction finalization

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-6425:
-

 Summary: Races during transaction finalization
 Key: IGNITE-6425
 URL: https://issues.apache.org/jira/browse/IGNITE-6425
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Static code analysis for Java

[Jörn Franke]

Why do not use all of the tools (well at least several). They are easy to be 
integrateable. In this way one would be less exposed to promote one commercial 
vendor over the other. 
This would also help in finding the right quality criteria instead of analyzing 
what is offered by only one solution.

From the open source projects that I contribute to I made the experience that 
they have different strengths and weaknesses. For example one may not support 
scala at all, where another is very good in Java not so good in Scala.

> On 14. Sep 2017, at 17:26, Malcolm Taylor  wrote:
> 
> Yakov,
> 
> You might also wish to consider lgtm.com, which is already analysing Ignite
> builds ( https://lgtm.com/projects/g/apache/ignite/ ).
> It has found a number of issues, some of which have been fixed through
> https://issues.apache.org/jira/browse/IGNITE-5805
> lgtm also supports the option of GitHub integration as discussed in
> https://lgtm.com/docs/lgtm/using-lgtm-analysis-continuous-integration
> 
> Regards,
> 
> Malcolm
> 
>> On 14 September 2017 at 16:02, Yakov Zhdanov  wrote:
>> 
>> Guys,
>> 
>> I remember we tried some static code analysis tools for Java (a bit awkward
>> not having one yet), but we did not setup regular checks.
>> 
>> I want to return to this. As result I would like to have code analysis tool
>> running on TC on daily basis and also established process to review and fix
>> code based on tool report same as we do with failed tests.
>> 
>> So, I consider several options:
>> 
>> 1. Findbugs - simple, free, runs locally, seems to have report parser in TC
>> and maven plugin
>> 2. https://www.sonarqube.org/ - free, runs locally and user uploads info
>> to
>> Sonarqube server for analysis, has very basic TC plugin that uploads bundle
>> to server and links build results on TC to results at Sonarqube site.
>> 3. https://scan.coverity.com/projects/apache-ignite - Coverity seems to be
>> very powerful, free for opensource, runs locally and then user  uploads
>> results to server for analysis.
>> 
>> Anton Vinogradov, can we try setting up Findbugs on TC and see how it works
>> and integrates with TC? As it seems to be the most simple option to get
>> results faster.
>> 
>> Then we can compare it to Coverity and take decision what to do next.
>> 
>> --Yakov
>> 

Re: ContinuousQueryWithTransformer implementation questions - 2

[Николай Ижиков]

Vladimir,

Here is a short summary what is wrong with continuous query


OK.
I agree - this is problems of current API.

How we can fix it by not merging ContinuousQueryWIthTransformer?
How we can quickly design, discuss and implement new API?
Because at the moment there is no any ticket to start working at.
Moreover we can't throw ContinuousQuery away until 3.0 version.

> What is worse, this interface is inconsistent with JCache event
listeners, which distinguish between create, update and delete events.

Can't agree with you.

1. As far as I know jcache doesn't have any Transformer conception.
2. We can distinguish create, update and delete events in transformer and
we can push that knowledge to listener.


> What I see in your PR is that we add one more confusing concept - in
> addition to wrongly named "local listener" now we will also have
> "TransformedEventListener".
>

I think usage of jcache API in some Ignite-specific classes is one more
issue of existing ContinuousQuery.
I think we must use Ignite only API for Ignite only features and use some
wrappers to provide external API support.

For these reasons I would still prefer to think of better continuous
> queries design first instead of making current API even more complicated.
>

I think the main reason for some feature is to provide value to the user.
Transformers adds value to a product because usage of transformer can lead
to significant performance win.


> Vladimir.
>
> On Mon, Sep 18, 2017 at 4:04 PM, Николай Ижиков 
> wrote:
>
> > Igniters,
> >
> > I discussed API of ContinuousQuery and ContinuousQueryWithTransformer
> with
> > Anton Vinogradov one more time.
> >
> > Since users who use regular ContinuousQuery already knows pros. and cons
> of
> > using initialQuery and to not to complicate API more and more until 3.0
> we
> > agreed that best choice is to stay with existing initialQuery that return
> > Cache.Entry for ContinuousQueryWithTransformer.
> >
> > Notice that initialQuery is not required and can be null.
> >
> > Thoughts?
> >
> > 2017-09-15 1:45 GMT+03:00 Denis Magda :
> >
> > > Vladimir,
> > >
> > > If the API is so bad then it might take much more time to make up and
> > roll
> > > out the new. Plus, there should be a community member who is ready to
> > take
> > > it over. My suggestion would be to accept this contribution and
> initiate
> > an
> > > activity towards the new API if you like.
> > >
> > > Personally, I considered this API as one of the most vivid we have
> basing
> > > on my practical usage experience. I was aware of initial query’s
> pitfalls
> > > but isn’t it something we can put on paper?
> > >
> > > —
> > > Denis
> > >
> > > > On Sep 12, 2017, at 6:04 AM, Vladimir Ozerov 
> > > wrote:
> > > >
> > > > My opinion is that our query API is big piece of ... you know,
> > especially
> > > > ContinuousQuery. A lot of concepts and features are mixed in a single
> > > > entity, what makes it hard to understand and use. Let's finally
> > deprecate
> > > > ContinuousQuery and design nice and consistent API. E.g.:
> > > >
> > > > interface IgniteCache {
> > > >UUID addListener(CacheEntryListener listener)
> > > >void removeListener(UUID listenerId);
> > > > }
> > > >
> > > > This method set's a listener on all nodes which will process event
> > > locally,
> > > > no network communication. Now if you want semantics similar to
> existing
> > > > continuous queries, you use special entry listener type:
> > > >
> > > > class ContinuousQueryCacheEntryListener implements
> CacheEntryListener
> > {
> > > >ContinuousQueryRemoteFilter rmtFilter;
> > > >ContinuousQueryRemoteTransformer rmtTransformer;
> > > >ContinuousQueryLocalCallback locCb;
> > > > }
> > > >
> > > > Last, "initial query" concept should be dropped from "continuous
> query"
> > > > feature completely. It doesn't guarantee any kind of atomicity or
> > > > visibility wrt to cache events, so it adds no value. The same
> behavior
> > > > could be achieved as follows:
> > > >
> > > > cache.addListener(...)
> > > > QueryCursor cursor = cache.query(initialQuery);
> > > >
> > > > Vladimir.
> > > >
> > > >
> > > > On Tue, Sep 12, 2017 at 3:35 PM, Yakov Zhdanov 
> > > wrote:
> > > >
> > > >> Dmitry, can you please take a look at public API change.
> > > >>
> > > >> Ticket - https://issues.apache.org/jira/browse/IGNITE-425
> > > >> PR - https://github.com/apache/ignite/pull/2372
> > > >>
> > > >> Issues:
> > > >> 1. Do you see any other option other than creating separate class?
> As
> > > for
> > > >> me I don't.
> > > >> 2. In a new class we still have initial query which uses 
> types
> > > which
> > > >> is questionable.
> > > >>
> > > >> Igniters, please share your thoughts as well. Public API is the face
> > of
> > > our
> > > >> product we need to make it as convenient and consistent as we can.
> > > >>
> > > >> --Yakov
> > > >>
> > >
> > >

[jira] [Created] (IGNITE-6424) .NET: IgniteConfiguration.ServiceConfiguration

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6424:
--

 Summary: .NET: IgniteConfiguration.ServiceConfiguration
 Key: IGNITE-6424
 URL: https://issues.apache.org/jira/browse/IGNITE-6424
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn


Add {{ServiceConfiguration[] IgniteConfiguration.ServiceConfiguration}} to be 
able to deploy services on start via config (XML or code).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: MVCC configuration

[Alexey Kuznetsov]

Semyon,

How about to have node attribute "COORDINATOR_RANK" or "COORDINATOR_ORDER"?
This attribute can be 1, 2, 3
And node with minimal number will become coordinator.
If it failed, node with next rank/order will be elected as new coordinator.

Make sense?

On Mon, Sep 18, 2017 at 4:39 PM, Semyon Boikov  wrote:

> Hi all,
>
> Currently I'm working on MVCC feature (IGNITE-3478) and need your opinion
> on related configuration options.
>
> 1. MVCC will definitely bring some performance overhead, so I think it
> should not be enabled by default, I'm going to add special flag on cache
> configuration: CacheConfiguration.isMvccEnabled.
>
> 2. In current mvcc architecture there should be some node in cluster
> assigning versions for tx updates and queries (mvcc coordinator). Mvcc
> coordinator is crucial component and it should perform as fast as possible.
> It seems we need introduce special 'dedicated mvcc coordinator' node role:
> it should not be possible to start cache on such node and it should not
> process user's compute jobs. At the same time it should be possible that
> any regular server node can become mvcc coordinator: this can be useful
> during development (no extra setup for mvcc will be needed), or support
> scenario when all dedicated coordinator nodes fail. So we need a way to
> make node a 'dedicated mvcc coordinator', we can add special flag on ignite
> configuration: IgniteConfiguration.isMvccCoordinator.
>
> What do you think?
>
> Thanks
>



-- 
Alexey Kuznetsov

[jira] [Created] (IGNITE-6423) LFD could be corrupted if partition have been evicted and returned to node

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-6423:
-

 Summary: LFD could be corrupted if partition have been evicted and 
returned to node
 Key: IGNITE-6423
 URL: https://issues.apache.org/jira/browse/IGNITE-6423
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev
Priority: Critical


So, what is going on? 
Partition had been changed, its pages had been put to checkpoint pages.
After it partition was evicted, checkpoint started.
We are allocating a page and because it's already in checkpoint we copy the 
empty page to copy it on disk.
If we restart right now we will read the empty page from disk. Therefore 
assertion error would be thrown etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2684: IGNITE-6391 JDBC thin driver: remove unused JdbcT...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

https://github.com/apache/ignite/pull/2684

IGNITE-6391 JDBC thin driver: remove unused JdbcThinTcpIo.srvProtocolVer



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6391

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2684.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2684


commit 654b456957acde951a910450f5c8eb8ccefecad0
Author: tledkov-gridgain 
Date:   2017-09-18T14:24:10Z

IGNITE-6391 JDBC thin driver: remove unused JdbcThinTcpIo.srvProtocolVer




---

[GitHub] ignite pull request #2536: IGNITE-6210 Size of the checkpoint buffer is limi...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2536


---

[jira] [Created] (IGNITE-6422) In visorcmd "cache on nodes" statistics mixes together primary and backup entries

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-6422:
---

 Summary: In visorcmd "cache on nodes" statistics mixes together 
primary and backup entries
 Key: IGNITE-6422
 URL: https://issues.apache.org/jira/browse/IGNITE-6422
 Project: Ignite
  Issue Type: Bug
  Components: visor
Affects Versions: 2.3
Reporter: Ilya Kasnacheev
Assignee: Vasiliy Sisko


Suppose we have a cache, with 1000 entries, one backup and eviction after 500 
entries. Then, off-heap entries are doubled in visorcmd, while on-heap entries 
are not:

{code}
+-+
| Name(@) | EmployeesCache(@c0)   |
| Nodes   | 2 |
| Total size Min/Avg/Max  | 1500 / 1500.00 / 1500 |
|   Heap size Min/Avg/Max | 500 / 500.00 / 500|
|   Off-heap size Min/Avg/Max | 1000 / 1000.00 / 1000 |
+-+

Nodes for: EmployeesCache(@c0)
+=+
|  Node ID8(@), IP  | CPUs | Heap Used | CPU Load |   Up Time|  
   Size | Hi/Mi/Rd/Wr |
+=+
| 37333BC6(@n0), 172.16.9.1 | 8| 4.47 %| 0.40 %   | 00:00:47:154 | 
Total: 1500  | Hi: 0   |
|   |  |   |  |  |   
Heap: 500  | Mi: 0   |
|   |  |   |  |  |   
Off-Heap: 1000 | Rd: 0   |
|   |  |   |  |  |   
Off-Heap Memory: 0 | Wr: 0   |
+---+--+---+--+--+--+-+
| 26FD4343(@n1), 172.16.9.1 | 8| 3.09 %| 0.23 %   | 00:00:41:602 | 
Total: 1500  | Hi: 0   |
|   |  |   |  |  |   
Heap: 500  | Mi: 0   |
|   |  |   |  |  |   
Off-Heap: 1000 | Rd: 0   |
|   |  |   |  |  |   
Off-Heap Memory: 0 | Wr: 0   |
+-+
'Hi' - Number of cache hits.
{code}

By contrast, on 1.9 it looks like this:
{code}
Cache 'EmployeesCache(@c0)':
+-+
| Name(@) | EmployeesCache(@c0)   |
| Nodes   | 2 |
| Total size Min/Avg/Max  | 1000 / 1000.00 / 1000 |
|   Heap size Min/Avg/Max | 500 / 500.00 / 500|
|   Off-heap size Min/Avg/Max | 500 / 500.00 / 500|
+-+

Nodes for: EmployeesCache(@c0)
++
|  Node ID8(@), IP  | CPUs | Heap Used | CPU Load |   Up Time|  
Size   | Hi/Mi/Rd/Wr |
++
| 3229FABE(@n0), 172.16.9.1 | 8| 1.25 %| 0.23 %   | 00:00:43:111 | 
Total: 1000 | Hi: 0   |
|   |  |   |  |  |   
Heap: 500 | Mi: 0   |
|   |  |   |  |  |   
Off-Heap: 500 | Rd: 0   |
|   |  |   |  |  |   
Off-Heap Memory: 88kb | Wr: 0   |
+---+--+---+--+--+-+-+
| 58FA742B(@n1), 172.16.9.1 | 8| 1.15 %| 0.47 %   | 00:00:38:828 | 
Total: 1000 | Hi: 0   |
|   |  |   |  |  |   
Heap: 500 | Mi: 0   |
|   |  |   |  |  |   
Off-Heap: 500 | Rd: 0   |
|   |  |   |  |  |   
Off-Heap Memory: 88kb | Wr: 0   |
++
{code}

NB: It might be feasible to keep number of backup entries displayed in 
visorcmd, but without adding them up with primary entries. Another dedicated 
line perhaps? Should also probably be consistent with other memory kinds.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Ignite PDS WAL analysis with human readable records

[Dmitry Pavlov]

Dmitriy,

Thank you for your feedback I've created IGNITE-6421 for this change.

Is it common practice to use property file in Ignite utils? I'd like to
support parse and display data entries and its fields, but it is required
to configure several folders: 'binary_meta' and 'marshaller' folders.

My idea is to provide .conf file to configure reader once.

Sincerely,
Dmitriy Pavlov

пн, 18 сент. 2017 г. в 16:10, Dmitriy Setrakyan :

> Thanks!
>
> After looking at the ticket, the way to launch this utility seems complex.
> Does this utility have a shell script? If not, we should add one with
> proper command line options, like we do for other scripts.
>
> D.
>
> On Mon, Sep 18, 2017 at 4:05 AM, Eduard Shangareev <
> eduard.shangar...@gmail.com> wrote:
>
> > Example of output (will add to wiki):
> >
> > [W] InitNewPageRecord [newPageId=0001001c0067, super=PageDeltaRecord
> > [grpId=2141373875, pageId=0001001c0067, super=WALRecord [size=41,
> > chainSize=0, pos=FileWALPointer [idx=1, fileOffset=25406, len=41,
> > forceFlush=false], type=INIT_NEW_PAGE_RECORD]]]
> > [W] InitNewPageRecord [newPageId=0001001c0068, super=PageDeltaRecord
> > [grpId=2141373875, pageId=0001001c0068, super=WALRecord [size=41,
> > chainSize=0, pos=FileWALPointer [idx=1, fileOffset=25447, len=41,
> > forceFlush=false], type=INIT_NEW_PAGE_RECORD]]]
> > [W] PagesListAddPageRecord [dataPageId=0001001c002a,
> > super=PageDeltaRecord [grpId=2141373875, pageId=0001001c0068,
> > super=WALRecord [size=37, chainSize=0, pos=FileWALPointer [idx=1,
> > fileOffset=25488, len=37, forceFlush=false], type=PAGES_LIST_ADD_PAGE]]]
> > [W] PageSnapshot [fullPageId = FullPageId [pageId=0001001c002a,
> > effectivePageId=001c002a, grpId=2141373875], page = [
> > Header [
> > type=1 (DataPageIO),
> > ver=1,
> > crc=0,
> > pageId=281595235794986(offset=0, flags=1, partId=28, index=42)
> > ],
> > DataPageIO [
> > 0001001c002a [4049, 4002, 3955, 3908, 3861, 3814, 3767, 3720, 3673,
> > 3626][][free=3552, actualFree=-544
> > ]],
> > super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> > fileOffset=25525, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> > [W] InsertRecord [idx=12, io=CacheIdAwareDataLeafIO[ver=1],
> > rightId=, super=PageDeltaRecord [grpId=2141373875,
> > pageId=0001001c0004, super=WALRecord [size=59, chainSize=0,
> > pos=FileWALPointer [idx=1, fileOffset=29650, len=59, forceFlush=false],
> > type=BTREE_PAGE_INSERT]]]
> > [W] DataRecord [writeEntries=[DataEntry [cacheId=-1368047377, op=CREATE,
> > writeVer=GridCacheVersion [topVer=116892426, order=1505412445450,
> > nodeOrder=2], partId=28, partCnt=69]], super=WALRecord [size=100,
> > chainSize=0, pos=FileWALPointer [idx=1, fileOffset=29709, len=100,
> > forceFlush=false], type=DATA_RECORD]]
> > [W] PageSnapshot [fullPageId = FullPageId [pageId=0001000a,
> > effectivePageId=000a, grpId=2141373875], page = [
> > Header [
> > type=20 (PagePartitionCountersIO),
> > ver=1,
> > crc=0,
> > pageId=281474976710666(offset=0, flags=1, partId=0, index=10)
> > ],
> > PagePartitionCounters [
> > count=1,
> > lastFlag=true,
> > nextCountersPageId=,
> > size={
> > -1368047377=313
> > }
> > ]],
> > super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> > fileOffset=29809, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> > [W] PageSnapshot [fullPageId = FullPageId [pageId=000100020010,
> > effectivePageId=00020010, grpId=2141373875], page = [
> > Header [
> > type=20 (PagePartitionCountersIO),
> > ver=1,
> > crc=0,
> > pageId=281483566645264(offset=0, flags=1, partId=2, index=16)
> > ],
> > PagePartitionCounters [
> > count=1,
> > lastFlag=true,
> > nextCountersPageId=,
> > size={
> > -1368047377=313
> > }
> > ]],
> > super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> > fileOffset=33934, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> > [W] PageSnapshot [fullPageId = FullPageId [pageId=00010005000d,
> > effectivePageId=0005000d, grpId=2141373875], page = [
> > Header [
> > type=20 (PagePartitionCountersIO),
> > ver=1,
> > crc=0,
> > pageId=281496451547149(offset=0, flags=1, partId=5, index=13)
> > ],
> > PagePartitionCounters [
> > count=1,
> > lastFlag=true,
> > nextCountersPageId=,
> > size={
> > -1368047377=313
> > }
> > ]],
> > super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> > fileOffset=38059, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> > [W] PageSnapshot [fullPageId = FullPageId [pageId=000100090003,
> > effectivePageId=00090003, grpId=2141373875], page = [
> > Header [
> > type=12 (PagesListMetaIO),
> > ver=1,
> > crc=0,
> > pageId=281513631416323(offset=0, flags=1, partId=9, index=3)
> > ],
> > PagesListMeta [
> > nextMetaPageId=,
> > count=230,
> > bucketData={
> > bucket=163, list=GridLongList [idx=6,
> > 

[GitHub] ignite pull request #2647: IGNITE-6355 Calculating cache size during cache s...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2647


---

[jira] [Created] (IGNITE-6421) Ignite WAL reader: add shell script to start converter

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-6421:
--

 Summary: Ignite WAL reader: add shell script to start converter
 Key: IGNITE-6421
 URL: https://issues.apache.org/jira/browse/IGNITE-6421
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


Support simple startup for utility 
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+WAL+reader by 
providing shell and bat files



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2578: IGNITE-6014 Transaction records in WAL.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2578


---

Re: ContinuousQueryWithTransformer implementation questions - 2

[Vladimir Ozerov]

Nikolay,

Here is a short summary what is wrong with continuous query:
1) It should not have "initialQuery"
2) It should not be called through IgniteCache.query() method, as it has
nothing in common with other "query" types
3) Main thing: our listeners are *ALWAYS* executed on a node which
initiated the query.

p.3 is the major problem. JCache specification doesn't define where
listeners should be invoked. Should we have ability to execute them on data
nodes, there would be much less demand in transformers.

What I see in your PR is that we add one more confusing concept - in
addition to wrongly named "local listener" now we will also have
"TransformedEventListener". What is worse, this interface is inconsistent
with JCache event listeners, which distinguish between create, update and
delete events.

For these reasons I would still prefer to think of better continuous
queries design first instead of making current API even more complicated.

Vladimir.

On Mon, Sep 18, 2017 at 4:04 PM, Николай Ижиков 
wrote:

> Igniters,
>
> I discussed API of ContinuousQuery and ContinuousQueryWithTransformer with
> Anton Vinogradov one more time.
>
> Since users who use regular ContinuousQuery already knows pros. and cons of
> using initialQuery and to not to complicate API more and more until 3.0 we
> agreed that best choice is to stay with existing initialQuery that return
> Cache.Entry for ContinuousQueryWithTransformer.
>
> Notice that initialQuery is not required and can be null.
>
> Thoughts?
>
> 2017-09-15 1:45 GMT+03:00 Denis Magda :
>
> > Vladimir,
> >
> > If the API is so bad then it might take much more time to make up and
> roll
> > out the new. Plus, there should be a community member who is ready to
> take
> > it over. My suggestion would be to accept this contribution and initiate
> an
> > activity towards the new API if you like.
> >
> > Personally, I considered this API as one of the most vivid we have basing
> > on my practical usage experience. I was aware of initial query’s pitfalls
> > but isn’t it something we can put on paper?
> >
> > —
> > Denis
> >
> > > On Sep 12, 2017, at 6:04 AM, Vladimir Ozerov 
> > wrote:
> > >
> > > My opinion is that our query API is big piece of ... you know,
> especially
> > > ContinuousQuery. A lot of concepts and features are mixed in a single
> > > entity, what makes it hard to understand and use. Let's finally
> deprecate
> > > ContinuousQuery and design nice and consistent API. E.g.:
> > >
> > > interface IgniteCache {
> > >UUID addListener(CacheEntryListener listener)
> > >void removeListener(UUID listenerId);
> > > }
> > >
> > > This method set's a listener on all nodes which will process event
> > locally,
> > > no network communication. Now if you want semantics similar to existing
> > > continuous queries, you use special entry listener type:
> > >
> > > class ContinuousQueryCacheEntryListener implements CacheEntryListener
> {
> > >ContinuousQueryRemoteFilter rmtFilter;
> > >ContinuousQueryRemoteTransformer rmtTransformer;
> > >ContinuousQueryLocalCallback locCb;
> > > }
> > >
> > > Last, "initial query" concept should be dropped from "continuous query"
> > > feature completely. It doesn't guarantee any kind of atomicity or
> > > visibility wrt to cache events, so it adds no value. The same behavior
> > > could be achieved as follows:
> > >
> > > cache.addListener(...)
> > > QueryCursor cursor = cache.query(initialQuery);
> > >
> > > Vladimir.
> > >
> > >
> > > On Tue, Sep 12, 2017 at 3:35 PM, Yakov Zhdanov 
> > wrote:
> > >
> > >> Dmitry, can you please take a look at public API change.
> > >>
> > >> Ticket - https://issues.apache.org/jira/browse/IGNITE-425
> > >> PR - https://github.com/apache/ignite/pull/2372
> > >>
> > >> Issues:
> > >> 1. Do you see any other option other than creating separate class? As
> > for
> > >> me I don't.
> > >> 2. In a new class we still have initial query which uses  types
> > which
> > >> is questionable.
> > >>
> > >> Igniters, please share your thoughts as well. Public API is the face
> of
> > our
> > >> product we need to make it as convenient and consistent as we can.
> > >>
> > >> --Yakov
> > >>
> >
> >
>
>
> --
> Nikolay Izhikov
> nizhikov@gmail.com
>

Re: Ignite PDS WAL analysis with human readable records

[Dmitriy Setrakyan]

Thanks!

After looking at the ticket, the way to launch this utility seems complex.
Does this utility have a shell script? If not, we should add one with
proper command line options, like we do for other scripts.

D.

On Mon, Sep 18, 2017 at 4:05 AM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:

> Example of output (will add to wiki):
>
> [W] InitNewPageRecord [newPageId=0001001c0067, super=PageDeltaRecord
> [grpId=2141373875, pageId=0001001c0067, super=WALRecord [size=41,
> chainSize=0, pos=FileWALPointer [idx=1, fileOffset=25406, len=41,
> forceFlush=false], type=INIT_NEW_PAGE_RECORD]]]
> [W] InitNewPageRecord [newPageId=0001001c0068, super=PageDeltaRecord
> [grpId=2141373875, pageId=0001001c0068, super=WALRecord [size=41,
> chainSize=0, pos=FileWALPointer [idx=1, fileOffset=25447, len=41,
> forceFlush=false], type=INIT_NEW_PAGE_RECORD]]]
> [W] PagesListAddPageRecord [dataPageId=0001001c002a,
> super=PageDeltaRecord [grpId=2141373875, pageId=0001001c0068,
> super=WALRecord [size=37, chainSize=0, pos=FileWALPointer [idx=1,
> fileOffset=25488, len=37, forceFlush=false], type=PAGES_LIST_ADD_PAGE]]]
> [W] PageSnapshot [fullPageId = FullPageId [pageId=0001001c002a,
> effectivePageId=001c002a, grpId=2141373875], page = [
> Header [
> type=1 (DataPageIO),
> ver=1,
> crc=0,
> pageId=281595235794986(offset=0, flags=1, partId=28, index=42)
> ],
> DataPageIO [
> 0001001c002a [4049, 4002, 3955, 3908, 3861, 3814, 3767, 3720, 3673,
> 3626][][free=3552, actualFree=-544
> ]],
> super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> fileOffset=25525, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> [W] InsertRecord [idx=12, io=CacheIdAwareDataLeafIO[ver=1],
> rightId=, super=PageDeltaRecord [grpId=2141373875,
> pageId=0001001c0004, super=WALRecord [size=59, chainSize=0,
> pos=FileWALPointer [idx=1, fileOffset=29650, len=59, forceFlush=false],
> type=BTREE_PAGE_INSERT]]]
> [W] DataRecord [writeEntries=[DataEntry [cacheId=-1368047377, op=CREATE,
> writeVer=GridCacheVersion [topVer=116892426, order=1505412445450,
> nodeOrder=2], partId=28, partCnt=69]], super=WALRecord [size=100,
> chainSize=0, pos=FileWALPointer [idx=1, fileOffset=29709, len=100,
> forceFlush=false], type=DATA_RECORD]]
> [W] PageSnapshot [fullPageId = FullPageId [pageId=0001000a,
> effectivePageId=000a, grpId=2141373875], page = [
> Header [
> type=20 (PagePartitionCountersIO),
> ver=1,
> crc=0,
> pageId=281474976710666(offset=0, flags=1, partId=0, index=10)
> ],
> PagePartitionCounters [
> count=1,
> lastFlag=true,
> nextCountersPageId=,
> size={
> -1368047377=313
> }
> ]],
> super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> fileOffset=29809, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> [W] PageSnapshot [fullPageId = FullPageId [pageId=000100020010,
> effectivePageId=00020010, grpId=2141373875], page = [
> Header [
> type=20 (PagePartitionCountersIO),
> ver=1,
> crc=0,
> pageId=281483566645264(offset=0, flags=1, partId=2, index=16)
> ],
> PagePartitionCounters [
> count=1,
> lastFlag=true,
> nextCountersPageId=,
> size={
> -1368047377=313
> }
> ]],
> super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> fileOffset=33934, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> [W] PageSnapshot [fullPageId = FullPageId [pageId=00010005000d,
> effectivePageId=0005000d, grpId=2141373875], page = [
> Header [
> type=20 (PagePartitionCountersIO),
> ver=1,
> crc=0,
> pageId=281496451547149(offset=0, flags=1, partId=5, index=13)
> ],
> PagePartitionCounters [
> count=1,
> lastFlag=true,
> nextCountersPageId=,
> size={
> -1368047377=313
> }
> ]],
> super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
> fileOffset=38059, len=4125, forceFlush=false], type=PAGE_RECORD]]]
> [W] PageSnapshot [fullPageId = FullPageId [pageId=000100090003,
> effectivePageId=00090003, grpId=2141373875], page = [
> Header [
> type=12 (PagesListMetaIO),
> ver=1,
> crc=0,
> pageId=281513631416323(offset=0, flags=1, partId=9, index=3)
> ],
> PagesListMeta [
> nextMetaPageId=,
> count=230,
> bucketData={
> bucket=163, list=GridLongList [idx=6,
> arr=[281513631416558,281513631416559,281513631416560,281513631416561,
> 281513631416562,281513631416563]]
> bucket=166, list=GridLongList [idx=8,
> arr=[281513631416550,281513631416551,281513631416552,281513631416553,
> 281513631416554,281513631416555,281513631416556,281513631416557]]
> bucket=169, list=GridLongList [idx=8,
> arr=[281513631416542,281513631416543,281513631416544,281513631416545,
> 281513631416546,281513631416547,281513631416548,281513631416549]]
> bucket=172, list=GridLongList [idx=8,
> arr=[281513631416534,281513631416535,281513631416536,281513631416537,
> 281513631416538,281513631416539,281513631416540,281513631416541]]
> bucket=175, list=GridLongList [idx=8,
> 

Re: ContinuousQueryWithTransformer implementation questions - 2

[Николай Ижиков]

Igniters,

I discussed API of ContinuousQuery and ContinuousQueryWithTransformer with
Anton Vinogradov one more time.

Since users who use regular ContinuousQuery already knows pros. and cons of
using initialQuery and to not to complicate API more and more until 3.0 we
agreed that best choice is to stay with existing initialQuery that return
Cache.Entry for ContinuousQueryWithTransformer.

Notice that initialQuery is not required and can be null.

Thoughts?

2017-09-15 1:45 GMT+03:00 Denis Magda :

> Vladimir,
>
> If the API is so bad then it might take much more time to make up and roll
> out the new. Plus, there should be a community member who is ready to take
> it over. My suggestion would be to accept this contribution and initiate an
> activity towards the new API if you like.
>
> Personally, I considered this API as one of the most vivid we have basing
> on my practical usage experience. I was aware of initial query’s pitfalls
> but isn’t it something we can put on paper?
>
> —
> Denis
>
> > On Sep 12, 2017, at 6:04 AM, Vladimir Ozerov 
> wrote:
> >
> > My opinion is that our query API is big piece of ... you know, especially
> > ContinuousQuery. A lot of concepts and features are mixed in a single
> > entity, what makes it hard to understand and use. Let's finally deprecate
> > ContinuousQuery and design nice and consistent API. E.g.:
> >
> > interface IgniteCache {
> >UUID addListener(CacheEntryListener listener)
> >void removeListener(UUID listenerId);
> > }
> >
> > This method set's a listener on all nodes which will process event
> locally,
> > no network communication. Now if you want semantics similar to existing
> > continuous queries, you use special entry listener type:
> >
> > class ContinuousQueryCacheEntryListener implements CacheEntryListener {
> >ContinuousQueryRemoteFilter rmtFilter;
> >ContinuousQueryRemoteTransformer rmtTransformer;
> >ContinuousQueryLocalCallback locCb;
> > }
> >
> > Last, "initial query" concept should be dropped from "continuous query"
> > feature completely. It doesn't guarantee any kind of atomicity or
> > visibility wrt to cache events, so it adds no value. The same behavior
> > could be achieved as follows:
> >
> > cache.addListener(...)
> > QueryCursor cursor = cache.query(initialQuery);
> >
> > Vladimir.
> >
> >
> > On Tue, Sep 12, 2017 at 3:35 PM, Yakov Zhdanov 
> wrote:
> >
> >> Dmitry, can you please take a look at public API change.
> >>
> >> Ticket - https://issues.apache.org/jira/browse/IGNITE-425
> >> PR - https://github.com/apache/ignite/pull/2372
> >>
> >> Issues:
> >> 1. Do you see any other option other than creating separate class? As
> for
> >> me I don't.
> >> 2. In a new class we still have initial query which uses  types
> which
> >> is questionable.
> >>
> >> Igniters, please share your thoughts as well. Public API is the face of
> our
> >> product we need to make it as convenient and consistent as we can.
> >>
> >> --Yakov
> >>
>
>


-- 
Nikolay Izhikov
nizhikov@gmail.com

[GitHub] ignite pull request #2682: IGNITE-6317 JDBC thick driver: SQLSTATE error cod...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2682


---

[GitHub] ignite pull request #2683: Ignite-6420 Time metrics (CacheMetrics.getAverage...

[sk0x50]

GitHub user sk0x50 opened a pull request:

https://github.com/apache/ignite/pull/2683

Ignite-6420 Time metrics (CacheMetrics.getAverage###Time) should be 
calculated on primary node in case of ATOMIC cache



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sk0x50/ignite ignite-6420

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2683.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2683


commit d939944f84aa415099a945b720dd4cd65132f6af
Author: Alexey Kuznetsov 
Date:   2017-03-21T03:05:33Z

IGNITE-1.8.4 Manual merge with master.

commit 71c62f70df2b79f706b6cca157bccfbcea0ae5ef
Author: Alexey Kuznetsov 
Date:   2017-03-21T03:20:39Z

IGNITE-4830 Implemented better SQL errors handling.
(cherry picked from commit fbb9940)

commit 93faee3579389c5754e3b91bcd39cc88dcf39125
Author: Alexey Kuznetsov 
Date:   2017-03-21T04:07:15Z

Web Console: Update classnames.properties.

commit 45812566694d016c07b47fa589bbba612c26f824
Author: Alexey Kuznetsov 
Date:   2017-03-21T04:23:18Z

Web Console: minor fix.
(cherry picked from commit 92bce6e)

commit f4232e9557fca89065f4ee424afab940265e2d1b
Author: oleg-ostanin 
Date:   2017-03-21T12:32:33Z

IGNITE-4822 Fixed change jvm options for benchmarks

commit ab3b2926213291a45305c21e7efe066855c1342f
Author: Igor Sapego 
Date:   2017-03-21T14:47:09Z

IGNITE-4200: Added copying of the C++ binaries.

commit e0c012d977b6db13dfdf2fb8347677998287c1e4
Author: Igor Sapego 
Date:   2017-03-21T14:50:06Z

IGNITE-4200: Added copying of the C++ binaries.

commit 6e2bc4bfb0b200e59c9fc3cf4fcbd408d52acb9c
Author: Igor Sapego 
Date:   2017-03-21T14:51:40Z

IGNITE-4200: Added copying of the C++ binaries.

commit 8273e6703944ea50b229a512398ac741eb713073
Author: Anton Vinogradov 
Date:   2017-03-21T15:04:01Z

IGNITE-4779 Missed discovery data snapshot during exchange processing 
(Backport from 2.0)

commit 6775f646df127f5cdbabf7a154b65856f38afa1e
Author: Dmitriy Shabalin 
Date:   2017-03-22T03:37:05Z

IGNITE-4686 Added ability to group registered users in admin panel.

(cherry picked from commit 827befb)

commit 7d94963251cc66823883d760668c2e2b31574bf1
Author: Andrey Novikov 
Date:   2017-03-22T11:20:32Z

IGNITE-4659 Fixed error page.

(cherry picked from commit 50de012)

commit eb837c7853ffc68e5a3f690e985407e603e3f955
Author: Andrey Novikov 
Date:   2017-03-22T11:21:03Z

IGNITE-4854 Fixed project structure button on summary page under firefox.

(cherry picked from commit 117e18e)

commit 8d9ade2cc2d71f12a427e3effa3846a928b0681e
Author: dkarachentsev 
Date:   2017-03-22T11:57:24Z

Merge branch 'ignite-1.7.9-p1' into ignite-1.7.10

commit 3aa2a68c02879ec57c46091cd2f22a9ac4b129ad
Author: dkarachentsev 
Date:   2017-03-22T12:22:50Z

Merge branch 'ignite-1.7.9-p1' into ignite-1.8.5

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java

commit ec7b9d848274b229b69dc7b8a20902654f719c44
Author: Andrey Novikov 
Date:   2017-03-23T02:32:38Z

IGNITE-4855 Fixed error on switching between notebooks.

(cherry picked from commit 6a148e2)

commit 36f7621b6eaa710d3b1eba7fddd0dfe92e11133e
Author: Andrey Novikov 
Date:   2017-03-23T03:57:03Z

IGNITE-4830 Fixed error ui.

(cherry picked from commit 48e78a9)

commit 1f3b2fcd003c1f084874d5c421953da0a7cd02cb
Author: Valentin Kulichenko 
Date:   2017-03-28T01:12:17Z

IGNITE-4802 - Separate thread pool for managed services

commit 39edcc7890ce497771f532a83a57ecae318d8c88
Author: Andrey V. Mashenkov 
Date:   2017-03-28T15:56:17Z

IGNITE-4815: Fixed confusing javadoc. This closes #1613.

commit e47bf27b5582cd695a7d3de3c39d54b3df4c59cc
Author: Valentin Kulichenko 
Date:   2017-03-28T23:51:44Z

IGNITE-4762 - transactionsAllowed flag for JDBC driver

commit 336672432486830c31cb4b6f8bb1b401c276f3e5
Author: Alexey Kuznetsov 
Date:   2017-03-29T03:53:25Z

IGNITE-4659 Fixed typo.
(cherry picked from commit 6f1e970)

commit 1ddce5517815fc85136e2ead9973c8cf74054f9f
Author: Alexey Kuznetsov 
Date:   2017-03-29T04:11:33Z

Merge branch 'web-console-production' of 

[jira] [Created] (IGNITE-6420) Time metrics (CacheMetrics.getAverage###Time) should be calculated on primary node in case of ATOMIC cache

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-6420:
---

 Summary: Time metrics (CacheMetrics.getAverage###Time) should be 
calculated on primary node in case of ATOMIC cache
 Key: IGNITE-6420
 URL: https://issues.apache.org/jira/browse/IGNITE-6420
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: MVCC configuration

[Semyon Boikov]

Vladimir, thanks for comments

> 2) I would also avoid this flag until we clearly understand it is needed.
> All numbers will be assigned from a single thread. For this reason even
> peak load on coordinator should not consume too much resources. I think we
> can assign coordinators automatically in first iteration.

For me need of dedicated coordinator nodes is clear: each mvcc
transaction/query will wait for mvcc coordinator response, if coordinator
will also process cache operations/compute jobs then any user code executed
on coordinator and consuming lot of CPU/heap will slowdown ALL mvcc
transactions/queries. As a user I want to make sure that coordinator node
will process only internal requests related to mvcc.

Also why do you think that all numbers should be assigned from single
thread?

Thanks

On Mon, Sep 18, 2017 at 2:59 PM, Semyon Boikov  wrote:

> Nikolay, thanks for comments
>
>
> > How will Ignite handle "mvcc coordinator" fail?
> > What will happen with if coordinator fails in the middle of a
> transaction?
> > Could tx be committed or rollbacked?
>
> I think coordinator failure will be handled in the same way as failure of
> one of transaction's 'primary' node: if coordinator fails during 'prepare'
> phase then tx is rolledback.
>
> >> Will we have some user notification if coordinator becomes slower?
>
> Now in Ignite we do not have common notion of 'user notification's, but we
> can add some metrics for coordinator performance on public API.
>
> Thanks
>
>
> On Mon, Sep 18, 2017 at 1:01 PM, Николай Ижиков 
> wrote:
>
>> Hello, Semyon!
>>
>> > It seems we need introduce special 'dedicated mvcc coordinator' node
>> role
>>
>> How will Ignite handle "mvcc coordinator" fail?
>>
>> What will happen with if coordinator fails in the middle of a transaction?
>> Could tx be committed or rollbacked?
>>
>> Will we have some user notification if coordinator becomes slower?
>>
>> > IgniteConfiguration.isMvccCoordinator
>>
>> flag name seems OK.
>>
>>
>> 2017-09-18 12:39 GMT+03:00 Semyon Boikov :
>>
>> > Hi all,
>> >
>> > Currently I'm working on MVCC feature (IGNITE-3478) and need your
>> opinion
>> > on related configuration options.
>> >
>> > 1. MVCC will definitely bring some performance overhead, so I think it
>> > should not be enabled by default, I'm going to add special flag on cache
>> > configuration: CacheConfiguration.isMvccEnabled.
>> >
>> > 2. In current mvcc architecture there should be some node in cluster
>> > assigning versions for tx updates and queries (mvcc coordinator). Mvcc
>> > coordinator is crucial component and it should perform as fast as
>> possible.
>> > It seems we need introduce special 'dedicated mvcc coordinator' node
>> role:
>> > it should not be possible to start cache on such node and it should not
>> > process user's compute jobs. At the same time it should be possible that
>> > any regular server node can become mvcc coordinator: this can be useful
>> > during development (no extra setup for mvcc will be needed), or support
>> > scenario when all dedicated coordinator nodes fail. So we need a way to
>> > make node a 'dedicated mvcc coordinator', we can add special flag on
>> ignite
>> > configuration: IgniteConfiguration.isMvccCoordinator.
>> >
>> > What do you think?
>> >
>> > Thanks
>> >
>>
>>
>>
>> --
>> Nikolay Izhikov
>> nizhikov@gmail.com
>>
>
>

Re: [VOTE] Apache Ignite 2.2.0 RC2

[Pavel Tupitsyn]

+1 (binding)
Checked .NET - build from sources, build and run examples

On Mon, Sep 18, 2017 at 2:57 PM, Vyacheslav Daradur 
wrote:

> +1
>
> On Mon, Sep 18, 2017 at 1:14 PM, Andrey Novikov 
> wrote:
>
> > +1 (binding)
> >
> > On Mon, Sep 18, 2017 at 4:35 PM, Alexey Kuznetsov  >
> > wrote:
> >
> > > +1 (binding)
> > >
> > > On Mon, Sep 18, 2017 at 4:29 PM, Vladimir Ozerov  >
> > > wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > On Mon, Sep 18, 2017 at 12:24 PM, Konstantin Dudkov 
> > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > >
> > > > > 15/09/2017 17:48, Anton Vinogradov пишет:
> > > > >
> > > > > Igniters,
> > > > >>
> > > > >> We have uploaded a 2.2.0 release candidate to
> > > > >> https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc2/
> > > > >>
> > > > >> Git tag name is
> > > > >> 2.2.0-rc2
> > > > >>
> > > > >> This release includes the following changes:
> > > > >>
> > > > >> Ignite:
> > > > >> * Checkpointing algorithm optimized
> > > > >> * Default max memory size changed from 80% to 20%
> > > > >>
> > > > >> Complete list of closed issues:
> > > > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> > > > >> 20IGNITE%20AND%20fixVersion%20%3D%202.2%20AND%20(status%
> > > > >> 20%3D%20closed%20or%20status%20%3D%20resolved)
> > > > >>
> > > > >> DEVNOTES
> > > > >> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > >> plain;f=DEVNOTES.txt;hb=refs/tags/2.2.0-rc2
> > > > >>
> > > > >> RELEASE NOTES
> > > > >> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > >> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.2.0-rc2
> > > > >>
> > > > >> Please start voting.
> > > > >>
> > > > >> +1 - to accept Apache Ignite 2.2.0-RC2
> > > > >> 0 - don't care either way
> > > > >> -1 - DO NOT accept Apache Ignite 2.2.0-RC2 (explain why)
> > > > >>
> > > > >> This vote will go for 72 hours.
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > >
> >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: MVCC configuration

[Semyon Boikov]

Nikolay, thanks for comments


> How will Ignite handle "mvcc coordinator" fail?
> What will happen with if coordinator fails in the middle of a transaction?
> Could tx be committed or rollbacked?

I think coordinator failure will be handled in the same way as failure of
one of transaction's 'primary' node: if coordinator fails during 'prepare'
phase then tx is rolledback.

>> Will we have some user notification if coordinator becomes slower?

Now in Ignite we do not have common notion of 'user notification's, but we
can add some metrics for coordinator performance on public API.

Thanks


On Mon, Sep 18, 2017 at 1:01 PM, Николай Ижиков 
wrote:

> Hello, Semyon!
>
> > It seems we need introduce special 'dedicated mvcc coordinator' node role
>
> How will Ignite handle "mvcc coordinator" fail?
>
> What will happen with if coordinator fails in the middle of a transaction?
> Could tx be committed or rollbacked?
>
> Will we have some user notification if coordinator becomes slower?
>
> > IgniteConfiguration.isMvccCoordinator
>
> flag name seems OK.
>
>
> 2017-09-18 12:39 GMT+03:00 Semyon Boikov :
>
> > Hi all,
> >
> > Currently I'm working on MVCC feature (IGNITE-3478) and need your opinion
> > on related configuration options.
> >
> > 1. MVCC will definitely bring some performance overhead, so I think it
> > should not be enabled by default, I'm going to add special flag on cache
> > configuration: CacheConfiguration.isMvccEnabled.
> >
> > 2. In current mvcc architecture there should be some node in cluster
> > assigning versions for tx updates and queries (mvcc coordinator). Mvcc
> > coordinator is crucial component and it should perform as fast as
> possible.
> > It seems we need introduce special 'dedicated mvcc coordinator' node
> role:
> > it should not be possible to start cache on such node and it should not
> > process user's compute jobs. At the same time it should be possible that
> > any regular server node can become mvcc coordinator: this can be useful
> > during development (no extra setup for mvcc will be needed), or support
> > scenario when all dedicated coordinator nodes fail. So we need a way to
> > make node a 'dedicated mvcc coordinator', we can add special flag on
> ignite
> > configuration: IgniteConfiguration.isMvccCoordinator.
> >
> > What do you think?
> >
> > Thanks
> >
>
>
>
> --
> Nikolay Izhikov
> nizhikov@gmail.com
>

Re: [VOTE] Apache Ignite 2.2.0 RC2

[Vyacheslav Daradur]

+1

On Mon, Sep 18, 2017 at 1:14 PM, Andrey Novikov  wrote:

> +1 (binding)
>
> On Mon, Sep 18, 2017 at 4:35 PM, Alexey Kuznetsov 
> wrote:
>
> > +1 (binding)
> >
> > On Mon, Sep 18, 2017 at 4:29 PM, Vladimir Ozerov 
> > wrote:
> >
> > > +1 (binding)
> > >
> > > On Mon, Sep 18, 2017 at 12:24 PM, Konstantin Dudkov 
> > wrote:
> > >
> > > > +1
> > > >
> > > >
> > > > 15/09/2017 17:48, Anton Vinogradov пишет:
> > > >
> > > > Igniters,
> > > >>
> > > >> We have uploaded a 2.2.0 release candidate to
> > > >> https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc2/
> > > >>
> > > >> Git tag name is
> > > >> 2.2.0-rc2
> > > >>
> > > >> This release includes the following changes:
> > > >>
> > > >> Ignite:
> > > >> * Checkpointing algorithm optimized
> > > >> * Default max memory size changed from 80% to 20%
> > > >>
> > > >> Complete list of closed issues:
> > > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> > > >> 20IGNITE%20AND%20fixVersion%20%3D%202.2%20AND%20(status%
> > > >> 20%3D%20closed%20or%20status%20%3D%20resolved)
> > > >>
> > > >> DEVNOTES
> > > >> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > >> plain;f=DEVNOTES.txt;hb=refs/tags/2.2.0-rc2
> > > >>
> > > >> RELEASE NOTES
> > > >> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > >> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.2.0-rc2
> > > >>
> > > >> Please start voting.
> > > >>
> > > >> +1 - to accept Apache Ignite 2.2.0-RC2
> > > >> 0 - don't care either way
> > > >> -1 - DO NOT accept Apache Ignite 2.2.0-RC2 (explain why)
> > > >>
> > > >> This vote will go for 72 hours.
> > > >>
> > > >>
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> >
>



-- 
Best Regards, Vyacheslav D.

Re: MVCC configuration

[Vladimir Ozerov]

Alex,

With putAll() on ATOMIC cache all bets are off, for sure.

On Mon, Sep 18, 2017 at 2:53 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Vladimir,
>
> I doubt it will be possible to add any meaningful guarantees to ATOMIC
> caches with MVCC. Consider a case when a user does a putAll, not a single
> put. In this case, updates received by multiple primary nodes are not
> connected in any way. Moreover, whenever a primary node fails, the put for
> failed keys will be re-tried, which will lead to all sorts of overlapping
> updates in case of parallel putAll. It is hard to suggest how we should
> handle this, let alone explain this to a user.
>
> -- AG
>
> 2017-09-18 14:50 GMT+03:00 Vladimir Ozerov :
>
> > Yakov,
> >
> > I would say that my example is not about adding transactions to ATOMIC
> > cache, but rather about adding consistent snapshots to it.
> >
> > On Mon, Sep 18, 2017 at 1:59 PM, Yakov Zhdanov 
> > wrote:
> >
> > > Vladimir, I think we can ask user to switch to transactional cache to
> > > support your example. Otherwise, it seems we are turning atomic caches
> to
> > > tx implicitly.
> > >
> > > --Yakov
> > >
> > > 2017-09-18 13:49 GMT+03:00 Vladimir Ozerov :
> > >
> > > > Semen,
> > > >
> > > > Consider use case of some audit table where I log user actions over
> > time.
> > > > Every actions is a put to ATOMIC cache. User interacts with my
> > > application,
> > > > and performs the following set of actions:
> > > > 1. 08:00 MSK -> LOGIN
> > > > 2. 08:10 MSK -> Update something
> > > > 3. 08:20 MSK -> LOGUT
> > > >
> > > > If MVCC is there, whenever I query all actions performed by the
> user, I
> > > > would see either {}, {1}, {1, 2} or {1, 2, 3}
> > > > Without MVCC I can see weird things, such as {1, 3} or {2}, or
> > > whatsoever.
> > > >
> > > > Vladimir.
> > > >
> > > >
> > > > On Mon, Sep 18, 2017 at 1:41 PM, Semyon Boikov  >
> > > > wrote:
> > > >
> > > > > Guys,
> > > > >
> > > > > I do not really understand mvcc for atomic cache, could you please
> > > > provide
> > > > > some real use case.
> > > > >
> > > > > Thank you
> > > > >
> > > > > On Mon, Sep 18, 2017 at 1:37 PM, Yakov Zhdanov <
> yzhda...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Ouch... of course it makes sense for atomic caches. Seems I am
> not
> > > > fully
> > > > > > switched on after weekend =)
> > > > > >
> > > > > > Agree on other points.
> > > > > >
> > > > > > --Yakov
> > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-6419) Thin client: pass user agent string

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6419:
--

 Summary: Thin client: pass user agent string
 Key: IGNITE-6419
 URL: https://issues.apache.org/jira/browse/IGNITE-6419
 Project: Ignite
  Issue Type: Improvement
  Components: thin client
Reporter: Pavel Tupitsyn


Include a string field in handshake for something like "user agent". Print this 
in the server log.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: MVCC configuration

[Alexey Goncharuk]

Vladimir,

I doubt it will be possible to add any meaningful guarantees to ATOMIC
caches with MVCC. Consider a case when a user does a putAll, not a single
put. In this case, updates received by multiple primary nodes are not
connected in any way. Moreover, whenever a primary node fails, the put for
failed keys will be re-tried, which will lead to all sorts of overlapping
updates in case of parallel putAll. It is hard to suggest how we should
handle this, let alone explain this to a user.

-- AG

2017-09-18 14:50 GMT+03:00 Vladimir Ozerov :

> Yakov,
>
> I would say that my example is not about adding transactions to ATOMIC
> cache, but rather about adding consistent snapshots to it.
>
> On Mon, Sep 18, 2017 at 1:59 PM, Yakov Zhdanov 
> wrote:
>
> > Vladimir, I think we can ask user to switch to transactional cache to
> > support your example. Otherwise, it seems we are turning atomic caches to
> > tx implicitly.
> >
> > --Yakov
> >
> > 2017-09-18 13:49 GMT+03:00 Vladimir Ozerov :
> >
> > > Semen,
> > >
> > > Consider use case of some audit table where I log user actions over
> time.
> > > Every actions is a put to ATOMIC cache. User interacts with my
> > application,
> > > and performs the following set of actions:
> > > 1. 08:00 MSK -> LOGIN
> > > 2. 08:10 MSK -> Update something
> > > 3. 08:20 MSK -> LOGUT
> > >
> > > If MVCC is there, whenever I query all actions performed by the user, I
> > > would see either {}, {1}, {1, 2} or {1, 2, 3}
> > > Without MVCC I can see weird things, such as {1, 3} or {2}, or
> > whatsoever.
> > >
> > > Vladimir.
> > >
> > >
> > > On Mon, Sep 18, 2017 at 1:41 PM, Semyon Boikov 
> > > wrote:
> > >
> > > > Guys,
> > > >
> > > > I do not really understand mvcc for atomic cache, could you please
> > > provide
> > > > some real use case.
> > > >
> > > > Thank you
> > > >
> > > > On Mon, Sep 18, 2017 at 1:37 PM, Yakov Zhdanov 
> > > > wrote:
> > > >
> > > > > Ouch... of course it makes sense for atomic caches. Seems I am not
> > > fully
> > > > > switched on after weekend =)
> > > > >
> > > > > Agree on other points.
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > >
> >
>

Re: MVCC configuration

[Vladimir Ozerov]

Yakov,

I would say that my example is not about adding transactions to ATOMIC
cache, but rather about adding consistent snapshots to it.

On Mon, Sep 18, 2017 at 1:59 PM, Yakov Zhdanov  wrote:

> Vladimir, I think we can ask user to switch to transactional cache to
> support your example. Otherwise, it seems we are turning atomic caches to
> tx implicitly.
>
> --Yakov
>
> 2017-09-18 13:49 GMT+03:00 Vladimir Ozerov :
>
> > Semen,
> >
> > Consider use case of some audit table where I log user actions over time.
> > Every actions is a put to ATOMIC cache. User interacts with my
> application,
> > and performs the following set of actions:
> > 1. 08:00 MSK -> LOGIN
> > 2. 08:10 MSK -> Update something
> > 3. 08:20 MSK -> LOGUT
> >
> > If MVCC is there, whenever I query all actions performed by the user, I
> > would see either {}, {1}, {1, 2} or {1, 2, 3}
> > Without MVCC I can see weird things, such as {1, 3} or {2}, or
> whatsoever.
> >
> > Vladimir.
> >
> >
> > On Mon, Sep 18, 2017 at 1:41 PM, Semyon Boikov 
> > wrote:
> >
> > > Guys,
> > >
> > > I do not really understand mvcc for atomic cache, could you please
> > provide
> > > some real use case.
> > >
> > > Thank you
> > >
> > > On Mon, Sep 18, 2017 at 1:37 PM, Yakov Zhdanov 
> > > wrote:
> > >
> > > > Ouch... of course it makes sense for atomic caches. Seems I am not
> > fully
> > > > switched on after weekend =)
> > > >
> > > > Agree on other points.
> > > >
> > > > --Yakov
> > > >
> > >
> >
>

Re: Ignite PDS WAL analysis with human readable records

[Eduard Shangareev]

Example of output (will add to wiki):

[W] InitNewPageRecord [newPageId=0001001c0067, super=PageDeltaRecord
[grpId=2141373875, pageId=0001001c0067, super=WALRecord [size=41,
chainSize=0, pos=FileWALPointer [idx=1, fileOffset=25406, len=41,
forceFlush=false], type=INIT_NEW_PAGE_RECORD]]]
[W] InitNewPageRecord [newPageId=0001001c0068, super=PageDeltaRecord
[grpId=2141373875, pageId=0001001c0068, super=WALRecord [size=41,
chainSize=0, pos=FileWALPointer [idx=1, fileOffset=25447, len=41,
forceFlush=false], type=INIT_NEW_PAGE_RECORD]]]
[W] PagesListAddPageRecord [dataPageId=0001001c002a,
super=PageDeltaRecord [grpId=2141373875, pageId=0001001c0068,
super=WALRecord [size=37, chainSize=0, pos=FileWALPointer [idx=1,
fileOffset=25488, len=37, forceFlush=false], type=PAGES_LIST_ADD_PAGE]]]
[W] PageSnapshot [fullPageId = FullPageId [pageId=0001001c002a,
effectivePageId=001c002a, grpId=2141373875], page = [
Header [
type=1 (DataPageIO),
ver=1,
crc=0,
pageId=281595235794986(offset=0, flags=1, partId=28, index=42)
],
DataPageIO [
0001001c002a [4049, 4002, 3955, 3908, 3861, 3814, 3767, 3720, 3673,
3626][][free=3552, actualFree=-544
]],
super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
fileOffset=25525, len=4125, forceFlush=false], type=PAGE_RECORD]]]
[W] InsertRecord [idx=12, io=CacheIdAwareDataLeafIO[ver=1],
rightId=, super=PageDeltaRecord [grpId=2141373875,
pageId=0001001c0004, super=WALRecord [size=59, chainSize=0,
pos=FileWALPointer [idx=1, fileOffset=29650, len=59, forceFlush=false],
type=BTREE_PAGE_INSERT]]]
[W] DataRecord [writeEntries=[DataEntry [cacheId=-1368047377, op=CREATE,
writeVer=GridCacheVersion [topVer=116892426, order=1505412445450,
nodeOrder=2], partId=28, partCnt=69]], super=WALRecord [size=100,
chainSize=0, pos=FileWALPointer [idx=1, fileOffset=29709, len=100,
forceFlush=false], type=DATA_RECORD]]
[W] PageSnapshot [fullPageId = FullPageId [pageId=0001000a,
effectivePageId=000a, grpId=2141373875], page = [
Header [
type=20 (PagePartitionCountersIO),
ver=1,
crc=0,
pageId=281474976710666(offset=0, flags=1, partId=0, index=10)
],
PagePartitionCounters [
count=1,
lastFlag=true,
nextCountersPageId=,
size={
-1368047377=313
}
]],
super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
fileOffset=29809, len=4125, forceFlush=false], type=PAGE_RECORD]]]
[W] PageSnapshot [fullPageId = FullPageId [pageId=000100020010,
effectivePageId=00020010, grpId=2141373875], page = [
Header [
type=20 (PagePartitionCountersIO),
ver=1,
crc=0,
pageId=281483566645264(offset=0, flags=1, partId=2, index=16)
],
PagePartitionCounters [
count=1,
lastFlag=true,
nextCountersPageId=,
size={
-1368047377=313
}
]],
super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
fileOffset=33934, len=4125, forceFlush=false], type=PAGE_RECORD]]]
[W] PageSnapshot [fullPageId = FullPageId [pageId=00010005000d,
effectivePageId=0005000d, grpId=2141373875], page = [
Header [
type=20 (PagePartitionCountersIO),
ver=1,
crc=0,
pageId=281496451547149(offset=0, flags=1, partId=5, index=13)
],
PagePartitionCounters [
count=1,
lastFlag=true,
nextCountersPageId=,
size={
-1368047377=313
}
]],
super = [WALRecord [size=4125, chainSize=0, pos=FileWALPointer [idx=1,
fileOffset=38059, len=4125, forceFlush=false], type=PAGE_RECORD]]]
[W] PageSnapshot [fullPageId = FullPageId [pageId=000100090003,
effectivePageId=00090003, grpId=2141373875], page = [
Header [
type=12 (PagesListMetaIO),
ver=1,
crc=0,
pageId=281513631416323(offset=0, flags=1, partId=9, index=3)
],
PagesListMeta [
nextMetaPageId=,
count=230,
bucketData={
bucket=163, list=GridLongList [idx=6,
arr=[281513631416558,281513631416559,281513631416560,281513631416561,281513631416562,281513631416563]]
bucket=166, list=GridLongList [idx=8,
arr=[281513631416550,281513631416551,281513631416552,281513631416553,281513631416554,281513631416555,281513631416556,281513631416557]]
bucket=169, list=GridLongList [idx=8,
arr=[281513631416542,281513631416543,281513631416544,281513631416545,281513631416546,281513631416547,281513631416548,281513631416549]]
bucket=172, list=GridLongList [idx=8,
arr=[281513631416534,281513631416535,281513631416536,281513631416537,281513631416538,281513631416539,281513631416540,281513631416541]]
bucket=175, list=GridLongList [idx=8,
arr=[281513631416526,281513631416527,281513631416528,281513631416529,281513631416530,281513631416531,281513631416532,281513631416533]]
bucket=178, list=GridLongList [idx=8,
arr=[281513631416512,281513631416513,281513631416520,281513631416521,281513631416522,281513631416523,281513631416524,281513631416525]]
bucket=181, list=GridLongList [idx=8,
arr=[281513631416510,281513631416511,281513631416514,281513631416515,281513631416516,281513631416517,281513631416518,281513631416519]]
bucket=184, list=GridLongList [idx=8,

Re: MVCC configuration

[Yakov Zhdanov]

Vladimir, I think we can ask user to switch to transactional cache to
support your example. Otherwise, it seems we are turning atomic caches to
tx implicitly.

--Yakov

2017-09-18 13:49 GMT+03:00 Vladimir Ozerov :

> Semen,
>
> Consider use case of some audit table where I log user actions over time.
> Every actions is a put to ATOMIC cache. User interacts with my application,
> and performs the following set of actions:
> 1. 08:00 MSK -> LOGIN
> 2. 08:10 MSK -> Update something
> 3. 08:20 MSK -> LOGUT
>
> If MVCC is there, whenever I query all actions performed by the user, I
> would see either {}, {1}, {1, 2} or {1, 2, 3}
> Without MVCC I can see weird things, such as {1, 3} or {2}, or whatsoever.
>
> Vladimir.
>
>
> On Mon, Sep 18, 2017 at 1:41 PM, Semyon Boikov 
> wrote:
>
> > Guys,
> >
> > I do not really understand mvcc for atomic cache, could you please
> provide
> > some real use case.
> >
> > Thank you
> >
> > On Mon, Sep 18, 2017 at 1:37 PM, Yakov Zhdanov 
> > wrote:
> >
> > > Ouch... of course it makes sense for atomic caches. Seems I am not
> fully
> > > switched on after weekend =)
> > >
> > > Agree on other points.
> > >
> > > --Yakov
> > >
> >
>

Re: MVCC configuration

[Vladimir Ozerov]

Semen,

Consider use case of some audit table where I log user actions over time.
Every actions is a put to ATOMIC cache. User interacts with my application,
and performs the following set of actions:
1. 08:00 MSK -> LOGIN
2. 08:10 MSK -> Update something
3. 08:20 MSK -> LOGUT

If MVCC is there, whenever I query all actions performed by the user, I
would see either {}, {1}, {1, 2} or {1, 2, 3}
Without MVCC I can see weird things, such as {1, 3} or {2}, or whatsoever.

Vladimir.


On Mon, Sep 18, 2017 at 1:41 PM, Semyon Boikov  wrote:

> Guys,
>
> I do not really understand mvcc for atomic cache, could you please provide
> some real use case.
>
> Thank you
>
> On Mon, Sep 18, 2017 at 1:37 PM, Yakov Zhdanov 
> wrote:
>
> > Ouch... of course it makes sense for atomic caches. Seems I am not fully
> > switched on after weekend =)
> >
> > Agree on other points.
> >
> > --Yakov
> >
>

Re: MVCC configuration

[Semyon Boikov]

Guys,

I do not really understand mvcc for atomic cache, could you please provide
some real use case.

Thank you

On Mon, Sep 18, 2017 at 1:37 PM, Yakov Zhdanov  wrote:

> Ouch... of course it makes sense for atomic caches. Seems I am not fully
> switched on after weekend =)
>
> Agree on other points.
>
> --Yakov
>

[GitHub] ignite pull request #2680: IGNITE-6413

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2680


---

Re: MVCC configuration

[Yakov Zhdanov]

Ouch... of course it makes sense for atomic caches. Seems I am not fully
switched on after weekend =)

Agree on other points.

--Yakov

Re: MVCC configuration

[Vladimir Ozerov]

Yakov,

MVCC for atomic caches makes sense as well - we will be able to read
consistent data set, which is not possible now. As I explained above,
per-cache configuration might not work when we start working on
transactional SQL design.

Moreover, it looks like an overkill for me at the moment. We will need
global flag anyway - this is convenient, as many application will require
all data to be MVCC-protected. So ideal solution would be to have
IgniteConfiguration.mvccEnabled
+ CacheConfiguration.mvccEnabled, but the latter could be skipped in the
first iteration.

On Mon, Sep 18, 2017 at 1:25 PM, Yakov Zhdanov  wrote:

> Vladimir, should it be on IgniteConfiguration or on CacheConfiguration? I
> think mvcc should be enabled on per cache basis and moreover it makes sense
> only for tx caches.
>
> --Yakov
>

Re: MVCC configuration

[Yakov Zhdanov]

Vladimir, should it be on IgniteConfiguration or on CacheConfiguration? I
think mvcc should be enabled on per cache basis and moreover it makes sense
only for tx caches.

--Yakov

Re: MVCC configuration

[Vladimir Ozerov]

Semen,

My comments:
1) I would propose to have only global flag for now -
IgniteConfiguration.isMvccEnabled.
One key design point we should keep in mind is that MVCC data *MSUT* be
persistent. We can skip it in the first iteration, as we are focused on
key-based cache updates, when typical transaction will update dozens or
hundreds keys. But when transactional SQL is ready, we will have to handle
cases when many thousands and millions rows are updated from concurrent
transactions. Without storing MVCC data on disk we will run out of memory.
Other vendors such as Oracle and Postgres, store MVCC-related data in data
blocks. So there is a risk that we will not be able to manage both MVCC and
non-MVCC caches in a single cache group or single memory policy. So
per-cache configuration looks too dangerous for me at the moment.

2) I would also avoid this flag until we clearly understand it is needed.
All numbers will be assigned from a single thread. For this reason even
peak load on coordinator should not consume too much resources. I think we
can assign coordinators automatically in first iteration.

So my vote is to have single global flag, nothing more -
IgniteConfiguration.isMvccEnabled.

Vladimir.

On Mon, Sep 18, 2017 at 12:39 PM, Semyon Boikov  wrote:

> Hi all,
>
> Currently I'm working on MVCC feature (IGNITE-3478) and need your opinion
> on related configuration options.
>
> 1. MVCC will definitely bring some performance overhead, so I think it
> should not be enabled by default, I'm going to add special flag on cache
> configuration: CacheConfiguration.isMvccEnabled.
>
> 2. In current mvcc architecture there should be some node in cluster
> assigning versions for tx updates and queries (mvcc coordinator). Mvcc
> coordinator is crucial component and it should perform as fast as possible.
> It seems we need introduce special 'dedicated mvcc coordinator' node role:
> it should not be possible to start cache on such node and it should not
> process user's compute jobs. At the same time it should be possible that
> any regular server node can become mvcc coordinator: this can be useful
> during development (no extra setup for mvcc will be needed), or support
> scenario when all dedicated coordinator nodes fail. So we need a way to
> make node a 'dedicated mvcc coordinator', we can add special flag on ignite
> configuration: IgniteConfiguration.isMvccCoordinator.
>
> What do you think?
>
> Thanks
>

Re: MVCC configuration

[Yakov Zhdanov]

1. Agree. Let's disable MVCC by default.
2. Sam, if user wants to have dedicated mvcc-coordinator, then we can use
configuration you suggested. However, I expect more properties will be
needed. How about having MvccConfiguration bean? Once topology has no
dedicated coordinators, topology should pick up some ordinary server (maybe
based on some stats about load and current partition distribution).

One more point - user should have an ability to assign coordinator
manually. I am pretty sure we can do it via custom discovery message.

--Yakov

Re: [VOTE] Apache Ignite 2.2.0 RC2

[Andrey Novikov]

+1 (binding)

On Mon, Sep 18, 2017 at 4:35 PM, Alexey Kuznetsov 
wrote:

> +1 (binding)
>
> On Mon, Sep 18, 2017 at 4:29 PM, Vladimir Ozerov 
> wrote:
>
> > +1 (binding)
> >
> > On Mon, Sep 18, 2017 at 12:24 PM, Konstantin Dudkov 
> wrote:
> >
> > > +1
> > >
> > >
> > > 15/09/2017 17:48, Anton Vinogradov пишет:
> > >
> > > Igniters,
> > >>
> > >> We have uploaded a 2.2.0 release candidate to
> > >> https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc2/
> > >>
> > >> Git tag name is
> > >> 2.2.0-rc2
> > >>
> > >> This release includes the following changes:
> > >>
> > >> Ignite:
> > >> * Checkpointing algorithm optimized
> > >> * Default max memory size changed from 80% to 20%
> > >>
> > >> Complete list of closed issues:
> > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> > >> 20IGNITE%20AND%20fixVersion%20%3D%202.2%20AND%20(status%
> > >> 20%3D%20closed%20or%20status%20%3D%20resolved)
> > >>
> > >> DEVNOTES
> > >> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > >> plain;f=DEVNOTES.txt;hb=refs/tags/2.2.0-rc2
> > >>
> > >> RELEASE NOTES
> > >> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > >> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.2.0-rc2
> > >>
> > >> Please start voting.
> > >>
> > >> +1 - to accept Apache Ignite 2.2.0-RC2
> > >> 0 - don't care either way
> > >> -1 - DO NOT accept Apache Ignite 2.2.0-RC2 (explain why)
> > >>
> > >> This vote will go for 72 hours.
> > >>
> > >>
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
>

Re: Ignite PDS WAL analysis with human readable records

[Dmitry Pavlov]

Hi Igniters,

Page https://cwiki.apache.org/confluence/display/IGNITE/Ignite+WAL+reader to
collect related information about this prototype was created.

Sincerely,
Dmitriy Pavlov

пн, 18 сент. 2017 г. в 7:01, Dmitriy Setrakyan :

> Can we get a sample print out from this utility?
>
> On Sun, Sep 17, 2017 at 3:42 PM, Eduard Shangareev <
> eduard.shangar...@gmail.com> wrote:
>
> > Dmitry,
> > thank you for starting this topic.
> >
> > The IDEA of this utility is very simple - get the possibility to look
> into
> > your WAL.
> > But it also requires understanding what's going on in WAL mechanism (We
> > need to describe it in more details in the wiki).
> >
> > It could be useful for a debug some weird things with recovery mechanism.
> > Initially, it was created for dealing with the issue in IGNITE-6342. It
> > helped to find out the error in how we deal with partition size.
> >
> > Best regards,
> > Ed.
> >
> >
> >
> >
> > On Sat, Sep 16, 2017 at 2:09 AM, Dmitry Pavlov 
> > wrote:
> >
> > > Hi Denis,
> > >
> > > Thank you for your feedback. It is very important to us to understand
> > that
> > > this tool may be useful not only for Ignite tests but for all
> developers.
> > >
> > > I will create wiki page.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > сб, 16 сент. 2017 г. в 1:54, Denis Magda :
> > >
> > > > Dmitriy, Eduard,
> > > >
> > > > Sounds like a useful thing. I’ll be happy to give a feedback but
> need a
> > > > documentation that explains how to use the tool, what’s the output
> > > format,
> > > > how do decipher the output, etc (basic things). The Wiki description
> > > should
> > > > be enough.
> > > >
> > > > —
> > > > Denis
> > > >
> > > > > On Sep 15, 2017, at 11:36 AM, Dmitry Pavlov  >
> > > > wrote:
> > > > >
> > > > > Hi Igniters,
> > > > >
> > > > > Eduard Shangareev created WAL converter utility which shows WAL
> > > > > archive/work directory segments content in human readable form.
> This
> > > > > utility outputs all WAL records to output stream (may be redirected
> > to
> > > > > file). How to use tips can be found in issue
> > > > > https://issues.apache.org/jira/browse/IGNITE-6277
> > > > >
> > > > >
> > > > > This utility does not require Ignite node to be up and running and
> > may
> > > be
> > > > > used for offline analysis of copied files. Thanks to Alexey G. for
> > idea
> > > > and
> > > > > review. Code is now available in modules/ignite-dev-tools.
> > > > >
> > > > > 1. Could you please write if utility can be useful for you?
> > > > >
> > > > > 2. Please respond if you need short wiki description.
> > > > >
> > > > > 3. What is your opinion what should be next steps to develop this
> > > > utility?
> > > > >
> > > > > 4. Does utility need property file to refer Ignite Work directory
> > using
> > > > > conf file.
> > > > >
> > > > > 5. What do you think if utility remains console non interactive, or
> > > some
> > > > > UI/Interactive console shell may be preferable?
> > > > >
> > > > > Sincerely,
> > > > >
> > > > > Dmitriy Pavlov
> > > >
> > > >
> > >
> >
>

Re: MVCC configuration

[Николай Ижиков]

Hello, Semyon!

> It seems we need introduce special 'dedicated mvcc coordinator' node role

How will Ignite handle "mvcc coordinator" fail?

What will happen with if coordinator fails in the middle of a transaction?
Could tx be committed or rollbacked?

Will we have some user notification if coordinator becomes slower?

> IgniteConfiguration.isMvccCoordinator

flag name seems OK.


2017-09-18 12:39 GMT+03:00 Semyon Boikov :

> Hi all,
>
> Currently I'm working on MVCC feature (IGNITE-3478) and need your opinion
> on related configuration options.
>
> 1. MVCC will definitely bring some performance overhead, so I think it
> should not be enabled by default, I'm going to add special flag on cache
> configuration: CacheConfiguration.isMvccEnabled.
>
> 2. In current mvcc architecture there should be some node in cluster
> assigning versions for tx updates and queries (mvcc coordinator). Mvcc
> coordinator is crucial component and it should perform as fast as possible.
> It seems we need introduce special 'dedicated mvcc coordinator' node role:
> it should not be possible to start cache on such node and it should not
> process user's compute jobs. At the same time it should be possible that
> any regular server node can become mvcc coordinator: this can be useful
> during development (no extra setup for mvcc will be needed), or support
> scenario when all dedicated coordinator nodes fail. So we need a way to
> make node a 'dedicated mvcc coordinator', we can add special flag on ignite
> configuration: IgniteConfiguration.isMvccCoordinator.
>
> What do you think?
>
> Thanks
>



-- 
Nikolay Izhikov
nizhikov@gmail.com

[GitHub] ignite pull request #2682: IGNITE-6317 JDBC thick driver: SQLSTATE error cod...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

https://github.com/apache/ignite/pull/2682

IGNITE-6317 JDBC thick driver: SQLSTATE error codes



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6317

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2682.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2682


commit 5c0874281e1daecf72dbe7f3eb62221515e5d566
Author: Alexander Paschenko 
Date:   2017-08-28T17:18:29Z

IGNITE-5620 Began sorting out errors.

commit 71c3bb261ad9c80948fc797865dfe3583cee372e
Author: Alexander Paschenko 
Date:   2017-08-29T15:57:34Z

IGNITE-5620 contd

commit 2bb7ca19787d27b1c35ad2a1a9904a6ae0d84944
Author: Alexander Paschenko 
Date:   2017-08-29T15:59:58Z

Merge remote-tracking branch 'apache/master' into ignite-5620

commit 5a909c68e31e6280fde5b0fa7bd9e01aa4b6b0f8
Author: Alexander Paschenko 
Date:   2017-08-29T19:07:04Z

IGNITE-5620 JDBC error tests - started

commit d907d785814b73f353d736895d063158ff1bb578
Author: Alexander Paschenko 
Date:   2017-08-30T16:47:11Z

Thin JDBC - errors

commit d2b1d454aad70ba8f817dc2030df443258024e5d
Author: Alexander Paschenko 
Date:   2017-08-31T14:33:04Z

IGNITE-5620 Errors propagation + tests.

commit e948325a40b9c727e676b9434d0fb4177e5dbb1a
Author: Alexander Paschenko 
Date:   2017-08-31T14:36:06Z

Added tests to suite.

commit 92413cf5bb6643d89da092ff25d2977bef119d73
Author: Alexander Paschenko 
Date:   2017-08-31T14:43:51Z

Merge remote-tracking branch 'apache/master' into ignite-5620

commit 002e747459677f64f3c533db0ca5e69f8ce3e469
Author: devozerov 
Date:   2017-09-05T11:05:41Z

Merge branch 'master' into ignite-5620

commit fae838e6bdeca976f4c12ced4f7f2169ee6bfe26
Author: Alexander Paschenko 
Date:   2017-09-05T11:21:48Z

Merge remote-tracking branch 'apache/master' into ignite-5620

commit e4f630f72f28109020bb2da3b0d21428f0e00e24
Author: Alexander Paschenko 
Date:   2017-09-05T12:12:47Z

Review fixes 1

commit 48982c61bad440efc5b7ae7f2567cc27b87fccda
Author: Alexander Paschenko 
Date:   2017-09-05T13:07:06Z

Merge remote-tracking branch 'origin/ignite-5620' into ignite-5620

commit 99cdffc19f938e99444085ab81fb8b4859a573b6
Author: Alexander Paschenko 
Date:   2017-09-06T13:04:36Z

Merge remote-tracking branch 'apache/master' into ignite-5620

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/odbc/SqlListenerNioListener.java

commit db493b11d2c1bb2a8cfc6d2908a5bee77a44fd75
Author: Alexander Paschenko 
Date:   2017-09-06T15:20:42Z

Merge remote-tracking branch 'apache/master' into ignite-5620

commit 8376518edaa050e4fce89080948e42bd9cec2b74
Author: Alexander Paschenko 
Date:   2017-09-06T17:45:42Z

Fixes

commit 60792ae572575734f2f0676b52d9263e3e416628
Author: Alexander Paschenko 
Date:   2017-09-07T09:26:14Z

Merge remote-tracking branch 'apache/master' into ignite-5620

commit 11c9b947cfd0e5421146606340f809496412c3d3
Author: Alexander Paschenko 
Date:   2017-09-07T20:34:47Z

IGNITE-5620 review fixes

commit bb015909b8ec12786221ddd922c4bc9d287c030f
Author: Alexander Paschenko 
Date:   2017-09-08T10:11:36Z

Merge remote-tracking branch 'apache/master' into ignite-5620

commit 5070e91d77ca1849fc7e9eaf5caf0e12af1fdc57
Author: Alexander Paschenko 
Date:   2017-09-08T12:33:35Z

IGNITE-5620 tests

commit 8649f91ba90ed161318865320d225eb53ab45b71
Author: Alexander Paschenko 
Date:   2017-09-11T11:43:50Z

Merge remote-tracking branch 'apache/master' into ignite-5620

commit 37db2767fbd7f01cbc958973e0cdfc69206d3ab0
Author: Alexander Paschenko 
Date:   2017-09-11T18:18:44Z

Review fixes - 1.

commit 3b0ebc3c8afe2871622fcb97d2b18b6bfb639bff
Author: Alexander Paschenko 
Date:   2017-09-12T10:31:49Z

Merge remote-tracking branch 'apache/master' into ignite-5620

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/jdbc/thin/JdbcThinPreparedStatement.java
#   

MVCC configuration

[Semyon Boikov]

Hi all,

Currently I'm working on MVCC feature (IGNITE-3478) and need your opinion
on related configuration options.

1. MVCC will definitely bring some performance overhead, so I think it
should not be enabled by default, I'm going to add special flag on cache
configuration: CacheConfiguration.isMvccEnabled.

2. In current mvcc architecture there should be some node in cluster
assigning versions for tx updates and queries (mvcc coordinator). Mvcc
coordinator is crucial component and it should perform as fast as possible.
It seems we need introduce special 'dedicated mvcc coordinator' node role:
it should not be possible to start cache on such node and it should not
process user's compute jobs. At the same time it should be possible that
any regular server node can become mvcc coordinator: this can be useful
during development (no extra setup for mvcc will be needed), or support
scenario when all dedicated coordinator nodes fail. So we need a way to
make node a 'dedicated mvcc coordinator', we can add special flag on ignite
configuration: IgniteConfiguration.isMvccCoordinator.

What do you think?

Thanks

Re: [VOTE] Apache Ignite 2.2.0 RC2

[Alexey Kuznetsov]

+1 (binding)

On Mon, Sep 18, 2017 at 4:29 PM, Vladimir Ozerov 
wrote:

> +1 (binding)
>
> On Mon, Sep 18, 2017 at 12:24 PM, Konstantin Dudkov  wrote:
>
> > +1
> >
> >
> > 15/09/2017 17:48, Anton Vinogradov пишет:
> >
> > Igniters,
> >>
> >> We have uploaded a 2.2.0 release candidate to
> >> https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc2/
> >>
> >> Git tag name is
> >> 2.2.0-rc2
> >>
> >> This release includes the following changes:
> >>
> >> Ignite:
> >> * Checkpointing algorithm optimized
> >> * Default max memory size changed from 80% to 20%
> >>
> >> Complete list of closed issues:
> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> >> 20IGNITE%20AND%20fixVersion%20%3D%202.2%20AND%20(status%
> >> 20%3D%20closed%20or%20status%20%3D%20resolved)
> >>
> >> DEVNOTES
> >> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> >> plain;f=DEVNOTES.txt;hb=refs/tags/2.2.0-rc2
> >>
> >> RELEASE NOTES
> >> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> >> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.2.0-rc2
> >>
> >> Please start voting.
> >>
> >> +1 - to accept Apache Ignite 2.2.0-RC2
> >> 0 - don't care either way
> >> -1 - DO NOT accept Apache Ignite 2.2.0-RC2 (explain why)
> >>
> >> This vote will go for 72 hours.
> >>
> >>
> >
>



-- 
Alexey Kuznetsov

[GitHub] ignite pull request #2675: Ignite-gg-12692

[AMashenkov]

Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/2675


---

Re: [VOTE] Apache Ignite 2.2.0 RC2

[Vladimir Ozerov]

+1 (binding)

On Mon, Sep 18, 2017 at 12:24 PM, Konstantin Dudkov  wrote:

> +1
>
>
> 15/09/2017 17:48, Anton Vinogradov пишет:
>
> Igniters,
>>
>> We have uploaded a 2.2.0 release candidate to
>> https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc2/
>>
>> Git tag name is
>> 2.2.0-rc2
>>
>> This release includes the following changes:
>>
>> Ignite:
>> * Checkpointing algorithm optimized
>> * Default max memory size changed from 80% to 20%
>>
>> Complete list of closed issues:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20IGNITE%20AND%20fixVersion%20%3D%202.2%20AND%20(status%
>> 20%3D%20closed%20or%20status%20%3D%20resolved)
>>
>> DEVNOTES
>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
>> plain;f=DEVNOTES.txt;hb=refs/tags/2.2.0-rc2
>>
>> RELEASE NOTES
>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.2.0-rc2
>>
>> Please start voting.
>>
>> +1 - to accept Apache Ignite 2.2.0-RC2
>> 0 - don't care either way
>> -1 - DO NOT accept Apache Ignite 2.2.0-RC2 (explain why)
>>
>> This vote will go for 72 hours.
>>
>>
>

[jira] [Created] (IGNITE-6418) Binary: optionally write integer datatypes with varint encoding

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6418:
---

 Summary: Binary: optionally write integer datatypes with varint 
encoding
 Key: IGNITE-6418
 URL: https://issues.apache.org/jira/browse/IGNITE-6418
 Project: Ignite
  Issue Type: Task
  Components: binary
Affects Versions: 2.1
Reporter: Vladimir Ozerov


Currently all integer data types are written as is. {{Integer}} always takes 4 
bytes, {{Long}} - 8 bytes, etc.

There is well-known technique called "varint encoding" which can compress 
integer values [1]. When used, {{Integer}} can take 1-5 bytes, {{Long}} - 1-10 
bytes. So when values are small enough we can save a lot of space. 

But this technique is not unversal, as big encoded values might require more 
bytes comparing to plain form. Also it might cause slowdowns in SQL engine. So 
this approach cannot be applied globally. Instead, we should allow users to 
control whether they want to use this technique or not.

One possible approach is to add some annotation and several new methods to 
{{BinaryWriter}} and {{BinaryReader}}, which will control whether varint is 
used or not.

[1] https://developers.google.com/protocol-buffers/docs/encoding#varints



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2681: IGNITE-6396: Added test for SQL state error code ...

[skalashnikov]

GitHub user skalashnikov opened a pull request:

https://github.com/apache/ignite/pull/2681

IGNITE-6396: Added test for SQL state error code for NOT NULL violation



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6396

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2681.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2681


commit 01a39a396574678c4199f7711757c7cea9220b07
Author: skalashnikov 
Date:   2017-09-18T09:23:36Z

IGNITE-6396: Added test for error code for NOT NULL violation




---

Re: [VOTE] Apache Ignite 2.2.0 RC2

[Konstantin Dudkov]

+1


15/09/2017 17:48, Anton Vinogradov пишет:

Igniters,

We have uploaded a 2.2.0 release candidate to
https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc2/

Git tag name is
2.2.0-rc2

This release includes the following changes:

Ignite:
* Checkpointing algorithm optimized
* Default max memory size changed from 80% to 20%

Complete list of closed issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.2%20AND%20(status%20%3D%20closed%20or%20status%20%3D%20resolved)

DEVNOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.2.0-rc2

RELEASE NOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.2.0-rc2

Please start voting.

+1 - to accept Apache Ignite 2.2.0-RC2
0 - don't care either way
-1 - DO NOT accept Apache Ignite 2.2.0-RC2 (explain why)

This vote will go for 72 hours.

[GitHub] ignite pull request #2666: IGNITE-6385 Offheap page eviction doesn't work if...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2666


---

Re: [VOTE] Apache Ignite 2.2.0 RC2

[Ilya Suntsov]

+1
Checked md5, sha512
Build from sources
Build examples

2017-09-16 10:45 GMT+03:00 Andrey Gura :

> +1
>
> 15 сент. 2017 г. 5:48 PM пользователь "Anton Vinogradov" 
> написал:
>
> > Igniters,
> >
> > We have uploaded a 2.2.0 release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc2/
> >
> > Git tag name is
> > 2.2.0-rc2
> >
> > This release includes the following changes:
> >
> > Ignite:
> > * Checkpointing algorithm optimized
> > * Default max memory size changed from 80% to 20%
> >
> > Complete list of closed issues:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> > 20fixVersion%20%3D%202.2%20AND%20(status%20%3D%
> > 20closed%20or%20status%20%3D%20resolved)
> >
> > DEVNOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > plain;f=DEVNOTES.txt;hb=refs/tags/2.2.0-rc2
> >
> > RELEASE NOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.2.0-rc2
> >
> > Please start voting.
> >
> > +1 - to accept Apache Ignite 2.2.0-RC2
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite 2.2.0-RC2 (explain why)
> >
> > This vote will go for 72 hours.
> >
>



-- 
Ilya Suntsov

[GitHub] ignite pull request #2680: IGNITE-6413

[devozerov]

GitHub user devozerov opened a pull request:

https://github.com/apache/ignite/pull/2680

IGNITE-6413



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6413

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/2680.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2680


commit 88ea406deb70c2b4b15a3216ac83304ca00c44d9
Author: devozerov 
Date:   2017-09-18T08:09:57Z

Tests.

commit 5fe62b5118301dfb56ec44af9234f40f2e68cf8b
Author: devozerov 
Date:   2017-09-18T08:20:12Z

Done.




---

Re: Unintuitive error message when invalid marshaller files found

[Michael Griggs]

Sure

SEVERE: Exception during start processors, node will be stopped and
close connections
class org.apache.ignite.IgniteCheckedException: Failed to start
processor: GridProcessorAdapter []
    at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1813)
    at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:946)
    at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1904)
    at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1646)
    at
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1074)
    at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:992)
    at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:878)
    at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:777)
    at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:647)
    at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:616)
    at org.apache.ignite.Ignition.start(Ignition.java:347)
    at com.gridgain.proserv.ServerNode.run(ServerNode.java:26)
    at com.gridgain.proserv.ServerNode.main(ServerNode.java:21)
Caused by: class org.apache.ignite.IgniteCheckedException: Reading
marshaller mapping from file 248380598.classname failed; last symbol
of file name is expected to be numeric.
    at
org.apache.ignite.internal.MarshallerMappingFileStore.getPlatformId(MarshallerMappingFileStore.java:186)
    at
org.apache.ignite.internal.MarshallerMappingFileStore.restoreMappings(MarshallerMappingFileStore.java:153)
    at
org.apache.ignite.internal.MarshallerContextImpl.onMarshallerProcessorStarted(MarshallerContextImpl.java:524)
    at
org.apache.ignite.internal.processors.marshaller.GridMarshallerMappingProcessor.start(GridMarshallerMappingProcessor.java:114)
    at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1810)
    ... 12 more
Caused by: java.lang.NumberFormatException: For input string: "e"
    at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Byte.parseByte(Byte.java:149)
    at java.lang.Byte.parseByte(Byte.java:175)
    at
org.apache.ignite.internal.MarshallerMappingFileStore.getPlatformId(MarshallerMappingFileStore.java:183)
    ... 16 more

Sep 18, 2017 8:22:35 AM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Got exception while starting (will rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start
processor: GridProcessorAdapter []
    at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1813)
    at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:946)
    at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1904)
    at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1646)
    at
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1074)
    at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:992)
    at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:878)
    at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:777)
    at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:647)
    at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:616)
    at org.apache.ignite.Ignition.start(Ignition.java:347)
    at com.gridgain.proserv.ServerNode.run(ServerNode.java:26)
    at com.gridgain.proserv.ServerNode.main(ServerNode.java:21)
Caused by: class org.apache.ignite.IgniteCheckedException: Reading
marshaller mapping from file 248380598.classname failed; last symbol
of file name is expected to be numeric.
    at
org.apache.ignite.internal.MarshallerMappingFileStore.getPlatformId(MarshallerMappingFileStore.java:186)
    at
org.apache.ignite.internal.MarshallerMappingFileStore.restoreMappings(MarshallerMappingFileStore.java:153)
    at
org.apache.ignite.internal.MarshallerContextImpl.onMarshallerProcessorStarted(MarshallerContextImpl.java:524)
    at
org.apache.ignite.internal.processors.marshaller.GridMarshallerMappingProcessor.start(GridMarshallerMappingProcessor.java:114)
    at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1810)
    ... 12 more
Caused by: java.lang.NumberFormatException: For input string: "e"
    at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Byte.parseByte(Byte.java:149)
    at java.lang.Byte.parseByte(Byte.java:175)
    at
org.apache.ignite.internal.MarshallerMappingFileStore.getPlatformId(MarshallerMappingFileStore.java:183)
    ... 16 more

Sep 18, 2017 8:22:35 AM org.apache.ignite.logger.java.JavaLogger
warning
WARNING: Attempt to stop starting grid. This operation cannot be
guaranteed to be successful.
Sep 18, 2017 8:22:35 AM org.apache.ignite.logger.java.JavaLogger info

[jira] [Created] (IGNITE-6417) Missed binary type configuration in VisorGridConfiguration.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-6417:
-

 Summary: Missed binary type configuration in 
VisorGridConfiguration.
 Key: IGNITE-6417
 URL: https://issues.apache.org/jira/browse/IGNITE-6417
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Vasiliy Sisko
Assignee: Alexey Kuznetsov
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)