[jira] [Created] (IGNITE-6531) Need to add a 'required' field to the SpringResource annotation.

[joungdal.nam (JIRA)]

joungdal.nam created IGNITE-6531:


 Summary: Need to add a 'required' field to the SpringResource 
annotation.
 Key: IGNITE-6531
 URL: https://issues.apache.org/jira/browse/IGNITE-6531
 Project: Ignite
  Issue Type: Improvement
  Components: spring
Affects Versions: 2.3
Reporter: joungdal.nam
Priority: Minor


In my test environment, only the client is used(setForceServerMode(true)). 
Operating environments use clients and servers.
Sometimes Injection is not required in the test environment.
NoSuchBeanDefinitionException is not generated by specifying a value of false.

public @interface SpringResource {

/**
 * Declares whether the annotated dependency is required.
 * Defaults to {@code true}.
 */
boolean required() default true;





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

[GitHub] ignite pull request #2771: IGNITE-5784 .NET: QueryIndex.InlineSize

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-6532) Introduce preallocation in LFS files to avoid high fragmentation on filesystem level

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-6532:
--

 Summary: Introduce preallocation in LFS files to avoid high 
fragmentation on filesystem level
 Key: IGNITE-6532
 URL: https://issues.apache.org/jira/browse/IGNITE-6532
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.2
Reporter: Ivan Rakov
 Fix For: 2.4


Modern databases (Oracle, MySql) work with storage drive on physical level, 
creating their own partition table and filesystem.
Ignite Persistent Store work with regular files. It appends new pages to 
partition file once new pages are allocated and written on checkpoint. These 
new pages can form one or several fragments on filesystem level.
As a result, after weeks of uptime, partition files can contain huge amount of 
fragments. There were reports about 120 fragments in index.bin file on XFS 
filesystem. 
We can work this around by preallocating files in bigger chunks, e.g. 1000 
pages at a time. On the other hand, early allocation will increase LFS size 
overhead, so we should consider reasonable heuristic for allocation.
Allocation should be performed on native level. Just writing a byte at position 
(file_size + page_size * 1000) won't do it because XFS (and other filesystems 
as well) has an optimization for that case. Missing range will be just skipped.



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

[GitHub] ignite pull request #2724: IGNITE-6473 Introduce a constant of default persi...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #2765: GG-12821 IGNITE-4642: Added "enforceJoinOrder" fl...

[alamar]

Github user alamar closed the pull request at:

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


---

[GitHub] ignite pull request #2764: GG-12826 Backport fixes for NPE in GridDhtPartiti...

[alamar]

Github user alamar closed the pull request at:

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


---

[GitHub] ignite pull request #2777: IGNITE-6358 JDBC thick: support multiple SQL stat...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-6358  JDBC thick: support multiple SQL statements



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

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

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

https://github.com/apache/ignite/pull/2777.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 #2777


commit f4c6603799c8752c6ee1ef13c697348fa36f9761
Author: tledkov-gridgain 
Date:   2017-09-04T08:31:28Z

IGNITE-6046: prototype of execution SQL query with multiple SQL statements

commit fc579cb0cb97c52adeb163ab2a719ccf4039e2c6
Author: devozerov 
Date:   2017-09-04T09:26:01Z

Merge branch 'master' into ignite-6046

commit 23509bd2f63fc83ee4aa7556317b3f9d05ae370e
Author: tledkov-gridgain 
Date:   2017-09-04T12:04:50Z

Merge branch '_master' into ignite-6046

commit f43bb01dee136f4e59b6b17ccd6877555aaedab9
Author: tledkov-gridgain 
Date:   2017-09-04T13:03:53Z

IGNITE-6046: prototype of execution SQL query with multiple SQL statements

commit c9670c3ce27ad98574467e0e418be1b1271916fc
Author: tledkov-gridgain 
Date:   2017-09-04T15:26:46Z

IGNITE-6046: save the progress

commit 5cef75bcab5d8f31712b0ad5dcbe53ebca110dc4
Author: tledkov-gridgain 
Date:   2017-09-05T06:53:32Z

IGNITE-6046: save the progress

commit 4c49d4f8489be223627f03c3de1c5a4e45d92e38
Author: tledkov-gridgain 
Date:   2017-09-05T06:54:16Z

Merge branch '_master' into ignite-6046

commit 1c7173a8979f8ef876d522bb1b017287f139f9bc
Author: tledkov-gridgain 
Date:   2017-09-05T08:53:41Z

IGNITE-6046: save the progress

commit 23e7cd395618406e1159d52b1b7c30603bd83a48
Author: tledkov-gridgain 
Date:   2017-09-07T09:39:06Z

Merge branch 'master' into ignite-6046

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

commit 44295708f0d46f430680954c9bdb20ae4843d783
Author: tledkov-gridgain 
Date:   2017-09-07T09:39:35Z

IGNITE-6046: add jdbc test

commit 96e22b6cb72a09ef04b78693f2957322e48a1c56
Author: tledkov-gridgain 
Date:   2017-09-07T09:44:34Z

IGNITE-6046: minors

commit 00fc06c5f0ee9a4ee83fee1f734ac5aa6151915b
Author: devozerov 
Date:   2017-09-07T09:46:34Z

Merge remote-tracking branch 'upstream/ignite-6046' into ignite-6046

commit 1d4de2f43c15527df21bf94e0b909d1fb34c3cea
Author: tledkov-gridgain 
Date:   2017-09-07T11:47:35Z

IGNITE-6046: refactoring

commit dbf9a97e1b286c56387ac65864aa2d1b7b829552
Author: tledkov-gridgain 
Date:   2017-09-07T11:50:37Z

Merge remote-tracking branch 'community/ignite-6046' into ignite-6046

commit df43b69b2c88fe7788cbe09865e62cf1ba4f3464
Author: tledkov-gridgain 
Date:   2017-09-07T12:48:43Z

IGNITE-6046: cosmetic

commit 0442727cea44e3287f7aee19f9322e0fda1a5c64
Author: tledkov-gridgain 
Date:   2017-09-07T14:00:08Z

IGNITE-6046: saver progress

commit df05d6387c828347a07b4d8e272c170c16a19b27
Author: tledkov-gridgain 
Date:   2017-09-07T15:45:14Z

IGNITE-6046: fix query cache usage, add tests

commit 59228fe25b050217acd18ee9f366c8b9454f2a7c
Author: tledkov-gridgain 
Date:   2017-09-08T12:35:52Z

IGNITE-6046: check parameters count

commit 878e3bffe095abeef38e4e53dc0222ec0413fbfe
Author: tledkov-gridgain 
Date:   2017-09-08T13:04:53Z

Merge branch 'master' into ignite-6046

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

commit 08c2eb368c147f02924c73ca353caeb70717177e
Author: tledkov-gridgain 
Date:   2017-09-08T13:28:51Z

IGNITE-6046: fix closeOnCompletion and test

commit 2436ebd8ce39c57bb260a997f179a3bb79d5e189
Author: tledkov-gridgain 
Date:   2017-09-11T10:20:02Z

Merge branch '_master' into ignite-6046

commit d366f6219068b87bfca9b840c86f8065ee99b079
Author: tledkov-gridgain 
Date:   2017-09-11T15:12:46Z

Merge branch '_master' into ignite-6046

commit c59769809b0dc7eee0b7ab4acc16dc6db001cd4c
Author: tledkov-gridgain 
Date:   2017-09-11T15:14:35Z

IGNITE-6046: fix after merge

commit 6d32f98e9fdf39b58f36cd0d0694e10f0a62e1e5
Author: tledkov-gridgain 
Date:   2017-09-12T08:47:14Z

Merge branch 'master' into ignite-6046

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

commit 46eec0ad2e8a0596c6f3faafc5d4d766d8017313
Author: tledkov-gridgain 
Date:   2017-09-12T09:02:59Z

IGNITE-6046: minors

commit 600f8e4f322ebc21564343b127e024af146daeed
Author: tledkov-gridgain 
Date:   2017-09-12T09:06:39Z

IGNITE-6046: self review

commit bb9afad504acd9ddb4dda0e9b5a03e3f3992925a
Author: tledkov-gridgain 
Date:   2017-09-12T09:14:45Z

IGNITE

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

[Yakov Zhdanov]

If user has Ignite deployment and does not want Ignite to automatically
change this property and does not want to set it to false. Which means user
wants to have completely default behavior as we have now.

--Yakov

Support for packed int and long primitives in raw binary API

[Alexei Scherbakov]

Guys,

I notices we do not have support for packed ints and longs in raw binary
API [1] [2]

Such methods are essential for implementing efficient custom compression
schemes.

Their addition can simplify implementing custom serializers for the cases
then default binary marshaller is not enough, without additional library
dependencies.

Proposed API extension for rawReader/rawWriter:

org.apache.ignite.binary.BinaryRawWriter#writePackedInt

org.apache.ignite.binary.BinaryRawWriter#writePackedLong

org.apache.ignite.binary.BinaryRawReader#readPackedInt

org.apache.ignite.binary.BinaryRawReader#readPackedLong

JIRA ticket: [3]

Thoughs ?

[1] org.apache.ignite.binary.BinaryRawReader

[2] org.apache.ignite.binary.BinaryRawWriter

[3] https://issues.apache.org/jira/browse/IGNITE-6426

-- 

Best regards,
Alexei Scherbakov

welcome

[Alexey Popov]

Hello Ignite Community!

My name is Alexey Popov. I want to contribute to Apache Ignite.
My Jira ID alexey.tank2

Thanks!

[GitHub] ignite pull request #2778: ignite-6485 Binary marshalling with writeReplace/...

[agura]

GitHub user agura opened a pull request:

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

ignite-6485 Binary marshalling with writeReplace/readResolve fixed



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

$ git pull https://github.com/agura/incubator-ignite ignite-6485

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

https://github.com/apache/ignite/pull/2778.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 #2778


commit f33d86b477e0ba7871c41f326fc5aa40be16f04b
Author: Andrey Gura 
Date:   2017-09-29T11:58:08Z

ignite-6485 Binary marshalling with writeReplace/readResolve fixed




---

Re: Support for packed int and long primitives in raw binary API

[Dmitriy Setrakyan]

Alexey, are you talking about arrays of ints and longs?

On Fri, Sep 29, 2017 at 3:29 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:

> Guys,
>
> I notices we do not have support for packed ints and longs in raw binary
> API [1] [2]
>
> Such methods are essential for implementing efficient custom compression
> schemes.
>
> Their addition can simplify implementing custom serializers for the cases
> then default binary marshaller is not enough, without additional library
> dependencies.
>
> Proposed API extension for rawReader/rawWriter:
>
> org.apache.ignite.binary.BinaryRawWriter#writePackedInt
>
> org.apache.ignite.binary.BinaryRawWriter#writePackedLong
>
> org.apache.ignite.binary.BinaryRawReader#readPackedInt
>
> org.apache.ignite.binary.BinaryRawReader#readPackedLong
>
> JIRA ticket: [3]
>
> Thoughs ?
>
> [1] org.apache.ignite.binary.BinaryRawReader
>
> [2] org.apache.ignite.binary.BinaryRawWriter
>
> [3] https://issues.apache.org/jira/browse/IGNITE-6426
>
> --
>
> Best regards,
> Alexei Scherbakov
>

Re: Future of Ignite transactions

[Dmitriy Setrakyan]

On Thu, Sep 28, 2017 at 10:30 PM, Vladimir Ozerov 
wrote:

> Dima,
>
> IgniteCache.withReadForUpdate() :-)
>

And how is it better than a pessimistic transaction with read?

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

[Dmitriy Setrakyan]

Hm... I am not sure I understand why. But in any case, to the list, we
should provide proper error messages suggesting to change this property. Do
you agree?

D.

On Fri, Sep 29, 2017 at 3:18 AM, Yakov Zhdanov  wrote:

> If user has Ignite deployment and does not want Ignite to automatically
> change this property and does not want to set it to false. Which means user
> wants to have completely default behavior as we have now.
>
> --Yakov
>

Re: Support for packed int and long primitives in raw binary API

[Alexei Scherbakov]

Dmitriy,

Not arrays, just primitives.

Using special binary representation, ints and longs can be represented by
1-9 bytes, depending on their cardinality.

I want to add such implementation in raw binary API to help implementing
custom serializers.



2017-09-29 15:12 GMT+03:00 Dmitriy Setrakyan :

> Alexey, are you talking about arrays of ints and longs?
>
> On Fri, Sep 29, 2017 at 3:29 AM, Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
> > Guys,
> >
> > I notices we do not have support for packed ints and longs in raw binary
> > API [1] [2]
> >
> > Such methods are essential for implementing efficient custom compression
> > schemes.
> >
> > Their addition can simplify implementing custom serializers for the cases
> > then default binary marshaller is not enough, without additional library
> > dependencies.
> >
> > Proposed API extension for rawReader/rawWriter:
> >
> > org.apache.ignite.binary.BinaryRawWriter#writePackedInt
> >
> > org.apache.ignite.binary.BinaryRawWriter#writePackedLong
> >
> > org.apache.ignite.binary.BinaryRawReader#readPackedInt
> >
> > org.apache.ignite.binary.BinaryRawReader#readPackedLong
> >
> > JIRA ticket: [3]
> >
> > Thoughs ?
> >
> > [1] org.apache.ignite.binary.BinaryRawReader
> >
> > [2] org.apache.ignite.binary.BinaryRawWriter
> >
> > [3] https://issues.apache.org/jira/browse/IGNITE-6426
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
> >
>



-- 

Best regards,
Alexei Scherbakov

[jira] [Created] (IGNITE-6533) Jdbc Client friver connection creation could hang if client node can't start in parallel

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-6533:
-

 Summary: Jdbc Client friver connection creation could hang if 
client node can't start in parallel
 Key: IGNITE-6533
 URL: https://issues.apache.org/jira/browse/IGNITE-6533
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Evgenii Zhuravlev


1. Start client node with
2. At the same time create connection with the same configuration in JDBC 
Client driver
3. If client node won't start, jdbc connection will hang



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

[jira] [Created] (IGNITE-6534) Configure NotNull fields with annotations

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6534:
--

 Summary: Configure NotNull fields with annotations
 Key: IGNITE-6534
 URL: https://issues.apache.org/jira/browse/IGNITE-6534
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.3
Reporter: Pavel Tupitsyn


IGNITE-6509 introduces a way to configure non-null QueryEntity fields.

Implement {{@QuerySqlField.notNull}} property to allow same thing via 
annotations.



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

Re: Future of Ignite transactions

[Vladimir Ozerov]

You can mix both "optimistic" and "pessimistic" reads in a single
transaction. This is one of the main points of proposed API. Normally users
do not define blocking behavior on TX level. They do that on per-operation
level.

On Fri, Sep 29, 2017 at 3:30 PM, Dmitriy Setrakyan 
wrote:

> On Thu, Sep 28, 2017 at 10:30 PM, Vladimir Ozerov 
> wrote:
>
> > Dima,
> >
> > IgniteCache.withReadForUpdate() :-)
> >
>
> And how is it better than a pessimistic transaction with read?
>

Re: Future of Ignite transactions

[Dmitriy Setrakyan]

On Fri, Sep 29, 2017 at 5:45 AM, Vladimir Ozerov 
wrote:

> You can mix both "optimistic" and "pessimistic" reads in a single
> transaction. This is one of the main points of proposed API. Normally users
> do not define blocking behavior on TX level. They do that on per-operation
> level.
>

In that case, why do you suggest the "with" API which will set this flag
for all operations. Why not just add "getWithLock()" method? Also, will
this method work on non-transactional caches?


>
> On Fri, Sep 29, 2017 at 3:30 PM, Dmitriy Setrakyan 
> wrote:
>
> > On Thu, Sep 28, 2017 at 10:30 PM, Vladimir Ozerov 
> > wrote:
> >
> > > Dima,
> > >
> > > IgniteCache.withReadForUpdate() :-)
> > >
> >
> > And how is it better than a pessimistic transaction with read?
> >
>

Re: Future of Ignite transactions

[Vladimir Ozerov]

Dima,

My point was that we have a number of read-only methods and I do not want
to pollute base cache API with their counterparts (get, getAll, getEntry,
getEntries). Another point is that "pessimistic" reads is relatively rare
use case comparing to "optimistic". This is why "with" approach looks
better to me.

Blocking reads doesn't make sense outside of explicit transaction.

On Fri, Sep 29, 2017 at 3:47 PM, Dmitriy Setrakyan 
wrote:

> On Fri, Sep 29, 2017 at 5:45 AM, Vladimir Ozerov 
> wrote:
>
> > You can mix both "optimistic" and "pessimistic" reads in a single
> > transaction. This is one of the main points of proposed API. Normally
> users
> > do not define blocking behavior on TX level. They do that on
> per-operation
> > level.
> >
>
> In that case, why do you suggest the "with" API which will set this flag
> for all operations. Why not just add "getWithLock()" method? Also, will
> this method work on non-transactional caches?
>
>
> >
> > On Fri, Sep 29, 2017 at 3:30 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Thu, Sep 28, 2017 at 10:30 PM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > wrote:
> > >
> > > > Dima,
> > > >
> > > > IgniteCache.withReadForUpdate() :-)
> > > >
> > >
> > > And how is it better than a pessimistic transaction with read?
> > >
> >
>

Re: Future of Ignite transactions

[Dmitriy Setrakyan]

I still have a feeling that we are fixing something that was not broken. I
have never heard from any user that they need to do both, blocking and
non-blocking reads in the same transaction.

The only requests I heard so far are:
- snapshot isolation
- read-only transactions

D.

On Fri, Sep 29, 2017 at 6:00 AM, Vladimir Ozerov 
wrote:

> Dima,
>
> My point was that we have a number of read-only methods and I do not want
> to pollute base cache API with their counterparts (get, getAll, getEntry,
> getEntries). Another point is that "pessimistic" reads is relatively rare
> use case comparing to "optimistic". This is why "with" approach looks
> better to me.
>
> Blocking reads doesn't make sense outside of explicit transaction.
>
> On Fri, Sep 29, 2017 at 3:47 PM, Dmitriy Setrakyan 
> wrote:
>
> > On Fri, Sep 29, 2017 at 5:45 AM, Vladimir Ozerov 
> > wrote:
> >
> > > You can mix both "optimistic" and "pessimistic" reads in a single
> > > transaction. This is one of the main points of proposed API. Normally
> > users
> > > do not define blocking behavior on TX level. They do that on
> > per-operation
> > > level.
> > >
> >
> > In that case, why do you suggest the "with" API which will set this flag
> > for all operations. Why not just add "getWithLock()" method? Also, will
> > this method work on non-transactional caches?
> >
> >
> > >
> > > On Fri, Sep 29, 2017 at 3:30 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > On Thu, Sep 28, 2017 at 10:30 PM, Vladimir Ozerov <
> > voze...@gridgain.com>
> > > > wrote:
> > > >
> > > > > Dima,
> > > > >
> > > > > IgniteCache.withReadForUpdate() :-)
> > > > >
> > > >
> > > > And how is it better than a pessimistic transaction with read?
> > > >
> > >
> >
>

[GitHub] ignite pull request #2779: IGNITE-6437: DataStructure can not be obtained on...

[zstan]

GitHub user zstan opened a pull request:

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

IGNITE-6437: DataStructure can not be obtained on client if it is cre…

…ated on server node

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

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

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

https://github.com/apache/ignite/pull/2779.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 #2779


commit b67d1350f99208a009cf043732f1b5b01c990538
Author: Evgeny Stanilovskiy 
Date:   2017-09-29T13:05:51Z

IGNITE-6437: DataStructure can not be obtained on client if it is created 
on server node




---

Re: Future of Ignite transactions

[Vladimir Ozerov]

Dima,

I doubt you ever heard from users "we need snapshot isolation" because this
is implementation detail, rather than public behavior :-)
I already explained what we are fixing - broken TX API. 6 possible modes, 5
real modes, 2 broken modes (OPT+RC, OPT+RR), and only *two (!!!)* modes
which are really used in practice (PES+RR, OPT+SER). Do you still think it
is not broken?

On Fri, Sep 29, 2017 at 4:05 PM, Dmitriy Setrakyan 
wrote:

> I still have a feeling that we are fixing something that was not broken. I
> have never heard from any user that they need to do both, blocking and
> non-blocking reads in the same transaction.
>
> The only requests I heard so far are:
> - snapshot isolation
> - read-only transactions
>
> D.
>
> On Fri, Sep 29, 2017 at 6:00 AM, Vladimir Ozerov 
> wrote:
>
> > Dima,
> >
> > My point was that we have a number of read-only methods and I do not want
> > to pollute base cache API with their counterparts (get, getAll, getEntry,
> > getEntries). Another point is that "pessimistic" reads is relatively rare
> > use case comparing to "optimistic". This is why "with" approach looks
> > better to me.
> >
> > Blocking reads doesn't make sense outside of explicit transaction.
> >
> > On Fri, Sep 29, 2017 at 3:47 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Fri, Sep 29, 2017 at 5:45 AM, Vladimir Ozerov  >
> > > wrote:
> > >
> > > > You can mix both "optimistic" and "pessimistic" reads in a single
> > > > transaction. This is one of the main points of proposed API. Normally
> > > users
> > > > do not define blocking behavior on TX level. They do that on
> > > per-operation
> > > > level.
> > > >
> > >
> > > In that case, why do you suggest the "with" API which will set this
> flag
> > > for all operations. Why not just add "getWithLock()" method? Also, will
> > > this method work on non-transactional caches?
> > >
> > >
> > > >
> > > > On Fri, Sep 29, 2017 at 3:30 PM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org>
> > > > wrote:
> > > >
> > > > > On Thu, Sep 28, 2017 at 10:30 PM, Vladimir Ozerov <
> > > voze...@gridgain.com>
> > > > > wrote:
> > > > >
> > > > > > Dima,
> > > > > >
> > > > > > IgniteCache.withReadForUpdate() :-)
> > > > > >
> > > > >
> > > > > And how is it better than a pessimistic transaction with read?
> > > > >
> > > >
> > >
> >
>

Re: Persistence per memory policy configuration

[Ivan Rakov]

Guys,

I've attached new configuration design draft to the ticket description: 
https://issues.apache.org/jira/browse/IGNITE-6030
Please, take a look. Right now is the best time to change name of any 
property.


And question about metrics: are we going to rename MemoryMetrics and 
PersistenceMetrics respectively (along with their MBeans)?
It's not a problem to implement it at all. The only thing that concerns 
me is that we have to keep deprecated old classes in the codebase. 
Perhaps, MemoryMetrics/PersistenceMetrics are intuitive enough.


On 29.09.2017 3:16, Dmitriy Setrakyan wrote:

StorageRegion sounds like bad English to me.

I would go with DataStorageConfiguration and DataRegionConfiguration.

D.

On Thu, Sep 28, 2017 at 7:24 AM, Vladimir Ozerov 
wrote:


Guys,

But what is exact desicion? :-) I saw two final options:

1) StorageConfiguration + StorageRegionConfiguration
2) DataStorageConfiguration + DataRegionConfiguration

Which one we choose?

On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov 
wrote:


I guess it is safe to assume that at this point we came to a consensus?

Alex, I think so. Let's carve it in stone (code).

--Yakov

[GitHub] ignite pull request #2780: Ignite 6123

[oignatenko]

GitHub user oignatenko opened a pull request:

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

Ignite 6123



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

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

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

https://github.com/apache/ignite/pull/2780.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 #2780






---

[GitHub] ignite pull request #2781: IGNITE-6520: Using actual AffinityReadyFuture res...

[andrey-kuznetsov]

GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-6520: Using actual AffinityReadyFuture result.



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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-6520

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

https://github.com/apache/ignite/pull/2781.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 #2781


commit 568b002006b8d5ddf4b72a7cbebc6d394b3ac240
Author: Andrey Kuznetsov 
Date:   2017-09-29T14:46:23Z

IGNITE-6520: Using actual AffinityReadyFuture result.




---

Re: Future of Ignite transactions

[Yakov Zhdanov]

I agree with Vladimir here. I always have some awkward feelings when
explaining our optimistic transactions behavior. Let's fix it now.

--Yakov

Re: Support for packed int and long primitives in raw binary API

[Valentin Kulichenko]

Alexey,

Any reason why you propose this only for raw data? I think this should be
an option for binary marshaller (probably per type). If we also add special
methods to Binarylizable, then they should be applied to both raw and
non-raw data.

BTW, there are couple other tickets regarding this, and looks like there is
already some progress:
- https://issues.apache.org/jira/browse/IGNITE-5097
- https://issues.apache.org/jira/browse/IGNITE-6418

-Val

On Fri, Sep 29, 2017 at 5:37 AM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:

> Dmitriy,
>
> Not arrays, just primitives.
>
> Using special binary representation, ints and longs can be represented by
> 1-9 bytes, depending on their cardinality.
>
> I want to add such implementation in raw binary API to help implementing
> custom serializers.
>
>
>
> 2017-09-29 15:12 GMT+03:00 Dmitriy Setrakyan :
>
> > Alexey, are you talking about arrays of ints and longs?
> >
> > On Fri, Sep 29, 2017 at 3:29 AM, Alexei Scherbakov <
> > alexey.scherbak...@gmail.com> wrote:
> >
> > > Guys,
> > >
> > > I notices we do not have support for packed ints and longs in raw
> binary
> > > API [1] [2]
> > >
> > > Such methods are essential for implementing efficient custom
> compression
> > > schemes.
> > >
> > > Their addition can simplify implementing custom serializers for the
> cases
> > > then default binary marshaller is not enough, without additional
> library
> > > dependencies.
> > >
> > > Proposed API extension for rawReader/rawWriter:
> > >
> > > org.apache.ignite.binary.BinaryRawWriter#writePackedInt
> > >
> > > org.apache.ignite.binary.BinaryRawWriter#writePackedLong
> > >
> > > org.apache.ignite.binary.BinaryRawReader#readPackedInt
> > >
> > > org.apache.ignite.binary.BinaryRawReader#readPackedLong
> > >
> > > JIRA ticket: [3]
> > >
> > > Thoughs ?
> > >
> > > [1] org.apache.ignite.binary.BinaryRawReader
> > >
> > > [2] org.apache.ignite.binary.BinaryRawWriter
> > >
> > > [3] https://issues.apache.org/jira/browse/IGNITE-6426
> > >
> > > --
> > >
> > > Best regards,
> > > Alexei Scherbakov
> > >
> >
>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>

Re: [DISCUSS] Ignite Update Checker

[Denis Magda]

That’s definitely worthwhile checking. Prachi, as the one who embedded the 
screencast, would you check the theory?

—
Denis
> On Sep 28, 2017, at 11:50 PM, Alexey Kuznetsov  wrote:
> 
> Cos, Denis.
> 
> I think it is because we have embedded videos (on YouTube).
> Mauricio or Denis, please check my idea.
> 
> On Fri, Sep 29, 2017 at 8:02 AM, Konstantin Boudnik  > wrote:
> Sorry guys - I neglected the fact that our lists don't permit
> attachments. I have put the screenshot to an external server [1]
> 
> [1] https://imgur.com/a/p9FJ9 
> 
> Thank you!
> --
>   With regards,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
> 
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
> 
> 
> On Thu, Sep 28, 2017 at 1:37 PM, Denis Magda  > wrote:
> > Cos,
> >
> > The screenshot was not attached. Could you share it some other way (google 
> > drive, etc.)? I’ve never seen any commercial on the site.
> >
> > —
> > Denis
> >
> >> On Sep 28, 2017, at 7:23 AM, Konstantin Boudnik  >> > wrote:
> >>
> >> I don't see an issue with node version either.
> >>
> >> Just one more, and it might be slightly irrelevant, issue though... I 
> >> looked at the Ignite's site and found the following ads and trackers (that 
> >> are indeed getting disabled by my browser).
> >> Why are googleads or doubleclick are permitted?
> >>
> >>
> >>
> >> Thanks,
> >>   Cos
> >>
> >>
> >> --
> >>   With regards,
> >> Konstantin (Cos) Boudnik
> >> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
> >>
> >> Disclaimer: Opinions expressed in this email are those of the author, and 
> >> do not necessarily represent the views of any company the author might be 
> >> affiliated with at the moment of writing.
> >>
> >> On Tue, Sep 26, 2017 at 3:21 PM, Dmitriy Setrakyan  >>   >> >> wrote:
> >> On Tue, Sep 26, 2017 at 6:20 AM, Vladimir Ozerov  >>   >> >>
> >> wrote:
> >>
> >> > Folks,
> >> >
> >> > Can we add version of current node to web request? This way we will 
> >> > better
> >> > understand version distribution, what might help us with certain API
> >> > update/deprecate decisions
> >> > E.g. http://ignite.apache.org/latest.cgi&ver=2.2.0 
> >> >  
> >> >  >> > >
> >>
> >>
> >> Vladimir, I personally do not see a problem with that, as sending the
> >> current version to the update checker seems very innocent to me. At the
> >> same time, it will allow us to examine the usage of each release and make
> >> decisions about dropping backward compatibility or spotting bugs for a
> >> certain release.
> >>
> >> Cos, Raul, any thoughts?
> >>
> >>
> >> >
> >> >
> >> > Vladimir.
> >> >
> >> > On Fri, Sep 8, 2017 at 7:06 AM, Dmitriy Setrakyan  >> >   >> > >>
> >> > wrote:
> >> >
> >> > > I think it is safe to assume at this point that everyone is in general
> >> > > agreement, since there are no active objections.
> >> > >
> >> > > I have filed a ticket for the 2.3 release. Let's try to make it happen:
> >> > > https://issues.apache.org/jira/browse/IGNITE-6305 
> >> > >  
> >> > >  >> > > >
> >> > >
> >> > > D.
> >> > >
> >> > > On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan <
> >> > dsetrak...@apache.org  
> >> > >>
> >> > > wrote:
> >> > >
> >> > > >
> >> > > >
> >> > > > On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani 
> >> > > > mailto:raul@evosent.com> 
> >> > > > >>
> >> > > > wrote:
> >> > > >
> >> > > >> Yeah, I guess that's doable as well and requires less management
> >> > effort
> >> > > >> than my suggestion. We could use events [1] to store payload data
> >> > (e.g.
> >> > > >> IP,
> >> > > >> version, etc.)
> >> > > >
> >> > > >
> >> > > > Yes, we could use events or some other similar API provided by GA.
> >> > > >
> >> > > >
> >> > > >> What the download page CGI developed in? PHP?
> >> > > >>
> >> > > >
> >> > > > To be honest, no clue. I guess someone in the community can figure it
> >> > > out:
> >> > > > https://svn.apache.org/repos/asf/ignite/site/trunk/download.html 
> >> > > >  
> >> > > > 

Re: welcome

[Denis Magda]

Hi Alexey, done and welcome to the Ignite community!

A piece of useful information for you.


Please subscribe to both dev and user lists:
https://ignite.apache.org/community/resources.html#mail-lists

Get familiar with Ignite development process described here:
https://cwiki.apache.org/confluence/display/IGNITE/Development+Process

Instructions on how to contribute can be found here:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Project setup in Intellij IDEA:
https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup

Once you got familiar and were able to run a few examples, you should pick
a Jira ticket you would like to start on. Send an email to the dev list sharing 
your JIRA id, so we can add you as a contributor in Jira.

These are the easy tickets to start with:
https://issues.apache.org/jira/browse/IGNITE-4549?jql=project%20%3D%20IGNITE%20AND%20labels%20in%20(newbie)%20and%20status%20%3D%20OPEN

While those are more advanced but appealing:
https://ignite.apache.org/community/contribute.html#pick-ticket

Looking forward to your contributions!

—
Denis

> On Sep 29, 2017, at 4:47 AM, Alexey Popov  wrote:
> 
> Hello Ignite Community!
> 
> My name is Alexey Popov. I want to contribute to Apache Ignite.
> My Jira ID alexey.tank2
> 
> Thanks!
> 
> 

Re: Persistence per memory policy configuration

[Denis Magda]

Ivan,

Several questions/concerns:

1. Looking at the new API I can’t grasp how to enable the persistence. First, 
how can I enable it globally if there is only one default data region defined. 
Second, how do I enable it per data region. Can’t find any related switches in 
the draft.

2. We cannot renamed anything like you’re suggesting to do for MemoryMetrics 
and their beans. We have to deprecate old and introduce new. 

3. I think we should merge Memory and Persistence Metrics into 
DataStorageMetrics for clarity.

—
Denis


> On Sep 29, 2017, at 6:29 AM, Ivan Rakov  wrote:
> 
> Guys,
> 
> I've attached new configuration design draft to the ticket description: 
> https://issues.apache.org/jira/browse/IGNITE-6030
> Please, take a look. Right now is the best time to change name of any 
> property.
> 
> And question about metrics: are we going to rename MemoryMetrics and 
> PersistenceMetrics respectively (along with their MBeans)?
> It's not a problem to implement it at all. The only thing that concerns me is 
> that we have to keep deprecated old classes in the codebase. Perhaps, 
> MemoryMetrics/PersistenceMetrics are intuitive enough.
> 
> On 29.09.2017 3:16, Dmitriy Setrakyan wrote:
>> StorageRegion sounds like bad English to me.
>> 
>> I would go with DataStorageConfiguration and DataRegionConfiguration.
>> 
>> D.
>> 
>> On Thu, Sep 28, 2017 at 7:24 AM, Vladimir Ozerov 
>> wrote:
>> 
>>> Guys,
>>> 
>>> But what is exact desicion? :-) I saw two final options:
>>> 
>>> 1) StorageConfiguration + StorageRegionConfiguration
>>> 2) DataStorageConfiguration + DataRegionConfiguration
>>> 
>>> Which one we choose?
>>> 
>>> On Thu, Sep 28, 2017 at 5:10 PM, Yakov Zhdanov 
>>> wrote:
>>> 
> I guess it is safe to assume that at this point we came to a consensus?
 Alex, I think so. Let's carve it in stone (code).
 
 --Yakov
 
> 

Apache Ignite talks in Paris the next week

[Denis Magda]

Igniters,

If you reside or stroll around Paris on next Monday or Tuesday drop by two 
locations to get more insights on how to use Ignite together with Spark and 
Hadoop. More details are here:

1. Hadoop and Spark acceleration with Ignite: 
https://ignite.apache.org/events.html#Big-Data-Developers-in-Paris-243327509 


2. Ignite and Spark for IoT: 
https://ignite.apache.org/events.html#Paris-Spark-Meetup-243673170 


Help to spread the word: 
https://twitter.com/denismagda/status/913838113645928448 


—
Denis

Re: Future of Ignite transactions

[Dmitriy Setrakyan]

On Fri, Sep 29, 2017 at 6:10 AM, Vladimir Ozerov 
wrote:

> Dima,
>
> I doubt you ever heard from users "we need snapshot isolation" because this
> is implementation detail, rather than public behavior :-)
>

Believe me, I have. People want to make sure that the data is not changed
from the call to tx.start(...). What we have, is making sure that it does
not change after it has been accessed the 1st time.

This is not an implementation detail, this is a different transaction
semantic.


> I already explained what we are fixing - broken TX API. 6 possible modes, 5
> real modes, 2 broken modes (OPT+RC, OPT+RR), and only *two (!!!)* modes
> which are really used in practice (PES+RR, OPT+SER). Do you still think it
> is not broken?
>

I have not seen any clean proposal yet. I do not want to break it even more
:)

Re: Future of Ignite transactions

[Dmitriy Setrakyan]

On Fri, Sep 29, 2017 at 8:16 AM, Yakov Zhdanov  wrote:

> I agree with Vladimir here. I always have some awkward feelings when
> explaining our optimistic transactions behavior. Let's fix it now.
>

In that case, let's try to come up with a cleaner proposal. The new design
has to make sense right away. It should not be this difficult to explain.

Re: [DISCUSS] Ignite Update Checker

[Prachi Garg]

We use the following scripts -

https://platform.twitter.com/widgets.js - used on homepage to display tweets
https://static.addtoany.com/menu/page.js - used on events page for social
media sharing
https://www.google-analytics.com/analytics.js

I also did a global search on the Ignite website, but didn't find anything
for googleads or doubleclick.

-Prachi


On Fri, Sep 29, 2017 at 11:03 AM, Denis Magda  wrote:

> That’s definitely worthwhile checking. Prachi, as the one who embedded the
> screencast, would you check the theory?
>
> —
> Denis
>
> On Sep 28, 2017, at 11:50 PM, Alexey Kuznetsov 
> wrote:
>
> Cos, Denis.
>
> I think it is because we have embedded videos (on YouTube).
> Mauricio or Denis, please check my idea.
>
> On Fri, Sep 29, 2017 at 8:02 AM, Konstantin Boudnik 
> wrote:
>
>> Sorry guys - I neglected the fact that our lists don't permit
>> attachments. I have put the screenshot to an external server [1]
>>
>> [1] https://imgur.com/a/p9FJ9
>>
>> Thank you!
>> --
>>   With regards,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Thu, Sep 28, 2017 at 1:37 PM, Denis Magda  wrote:
>> > Cos,
>> >
>> > The screenshot was not attached. Could you share it some other way
>> (google drive, etc.)? I’ve never seen any commercial on the site.
>> >
>> > —
>> > Denis
>> >
>> >> On Sep 28, 2017, at 7:23 AM, Konstantin Boudnik 
>> wrote:
>> >>
>> >> I don't see an issue with node version either.
>> >>
>> >> Just one more, and it might be slightly irrelevant, issue though... I
>> looked at the Ignite's site and found the following ads and trackers (that
>> are indeed getting disabled by my browser).
>> >> Why are googleads or doubleclick are permitted?
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>   Cos
>> >>
>> >>
>> >> --
>> >>   With regards,
>> >> Konstantin (Cos) Boudnik
>> >> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>> >>
>> >> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author might
>> be affiliated with at the moment of writing.
>> >>
>> >> On Tue, Sep 26, 2017 at 3:21 PM, Dmitriy Setrakyan <
>> dsetrak...@apache.org > wrote:
>> >> On Tue, Sep 26, 2017 at 6:20 AM, Vladimir Ozerov > >
>> >> wrote:
>> >>
>> >> > Folks,
>> >> >
>> >> > Can we add version of current node to web request? This way we will
>> better
>> >> > understand version distribution, what might help us with certain API
>> >> > update/deprecate decisions
>> >> > E.g. http://ignite.apache.org/latest.cgi&ver=2.2.0 <
>> http://ignite.apache.org/latest.cgi&ver=2.2.0>
>> >>
>> >>
>> >> Vladimir, I personally do not see a problem with that, as sending the
>> >> current version to the update checker seems very innocent to me. At the
>> >> same time, it will allow us to examine the usage of each release and
>> make
>> >> decisions about dropping backward compatibility or spotting bugs for a
>> >> certain release.
>> >>
>> >> Cos, Raul, any thoughts?
>> >>
>> >>
>> >> >
>> >> >
>> >> > Vladimir.
>> >> >
>> >> > On Fri, Sep 8, 2017 at 7:06 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org >
>> >> > wrote:
>> >> >
>> >> > > I think it is safe to assume at this point that everyone is in
>> general
>> >> > > agreement, since there are no active objections.
>> >> > >
>> >> > > I have filed a ticket for the 2.3 release. Let's try to make it
>> happen:
>> >> > > https://issues.apache.org/jira/browse/IGNITE-6305 <
>> https://issues.apache.org/jira/browse/IGNITE-6305>
>> >> > >
>> >> > > D.
>> >> > >
>> >> > > On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan <
>> >> > dsetrak...@apache.org >
>> >> > > wrote:
>> >> > >
>> >> > > >
>> >> > > >
>> >> > > > On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani <
>> raul@evosent.com >
>> >> > > > wrote:
>> >> > > >
>> >> > > >> Yeah, I guess that's doable as well and requires less management
>> >> > effort
>> >> > > >> than my suggestion. We could use events [1] to store payload
>> data
>> >> > (e.g.
>> >> > > >> IP,
>> >> > > >> version, etc.)
>> >> > > >
>> >> > > >
>> >> > > > Yes, we could use events or some other similar API provided by
>> GA.
>> >> > > >
>> >> > > >
>> >> > > >> What the download page CGI developed in? PHP?
>> >> > > >>
>> >> > > >
>> >> > > > To be honest, no clue. I guess someone in the community can
>> figure it
>> >> > > out:
>> >> > > > https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
>> 
>> >> > > >
>> >> > > >
>> >> > > >> However, I'm not sure whether storing this data in a 3rd party
>> >> > (Google)
>> >> > > is
>> >> 

Logical Cache Documented

[Denis Magda]

Igniters,

I’ve put on paper the feature from the subj:
https://apacheignite.readme.io/docs/logical-caches 


Sam, will appreciate if you read through it and confirm I explained the topic 
100% technically correct.

However, are there any negative impacts of having logical caches? This page has 
“Possible Impacts” section unfilled:
https://cwiki.apache.org/confluence/display/IGNITE/Logical+Caches 


—
Denis

Re: [DISCUSS] Ignite Update Checker

[Denis Magda]

> I also did a global search on the Ignite website, but didn't find anything 
> for googleads or doubleclick.  

Could you remove and add screencasts block temporary on your local deployment 
to see if the calls to commercial scripts reported by Cos appear in your Chrome 
dev toolkit?

—
Denis

> On Sep 29, 2017, at 3:56 PM, Prachi Garg  wrote:
> 
> We use the following scripts - 
> 
> https://platform.twitter.com/widgets.js 
>  - used on homepage to display tweets
> https://static.addtoany.com/menu/page.js 
>  - used on events page for social 
> media sharing
> https://www.google-analytics.com/analytics.js 
> 
> 
> I also did a global search on the Ignite website, but didn't find anything 
> for googleads or doubleclick.  
> 
> -Prachi
> 
> 
> On Fri, Sep 29, 2017 at 11:03 AM, Denis Magda  > wrote:
> That’s definitely worthwhile checking. Prachi, as the one who embedded the 
> screencast, would you check the theory?
> 
> —
> Denis
>> On Sep 28, 2017, at 11:50 PM, Alexey Kuznetsov > > wrote:
>> 
>> Cos, Denis.
>> 
>> I think it is because we have embedded videos (on YouTube).
>> Mauricio or Denis, please check my idea.
>> 
>> On Fri, Sep 29, 2017 at 8:02 AM, Konstantin Boudnik > > wrote:
>> Sorry guys - I neglected the fact that our lists don't permit
>> attachments. I have put the screenshot to an external server [1]
>> 
>> [1] https://imgur.com/a/p9FJ9 
>> 
>> Thank you!
>> --
>>   With regards,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>> 
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>> 
>> 
>> On Thu, Sep 28, 2017 at 1:37 PM, Denis Magda > > wrote:
>> > Cos,
>> >
>> > The screenshot was not attached. Could you share it some other way (google 
>> > drive, etc.)? I’ve never seen any commercial on the site.
>> >
>> > —
>> > Denis
>> >
>> >> On Sep 28, 2017, at 7:23 AM, Konstantin Boudnik > >> > wrote:
>> >>
>> >> I don't see an issue with node version either.
>> >>
>> >> Just one more, and it might be slightly irrelevant, issue though... I 
>> >> looked at the Ignite's site and found the following ads and trackers 
>> >> (that are indeed getting disabled by my browser).
>> >> Why are googleads or doubleclick are permitted?
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>   Cos
>> >>
>> >>
>> >> --
>> >>   With regards,
>> >> Konstantin (Cos) Boudnik
>> >> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>> >>
>> >> Disclaimer: Opinions expressed in this email are those of the author, and 
>> >> do not necessarily represent the views of any company the author might be 
>> >> affiliated with at the moment of writing.
>> >>
>> >> On Tue, Sep 26, 2017 at 3:21 PM, Dmitriy Setrakyan > >>  > >> >> wrote:
>> >> On Tue, Sep 26, 2017 at 6:20 AM, Vladimir Ozerov > >>  > >> >>
>> >> wrote:
>> >>
>> >> > Folks,
>> >> >
>> >> > Can we add version of current node to web request? This way we will 
>> >> > better
>> >> > understand version distribution, what might help us with certain API
>> >> > update/deprecate decisions
>> >> > E.g. http://ignite.apache.org/latest.cgi&ver=2.2.0 
>> >> >  
>> >> > > >> > >
>> >>
>> >>
>> >> Vladimir, I personally do not see a problem with that, as sending the
>> >> current version to the update checker seems very innocent to me. At the
>> >> same time, it will allow us to examine the usage of each release and make
>> >> decisions about dropping backward compatibility or spotting bugs for a
>> >> certain release.
>> >>
>> >> Cos, Raul, any thoughts?
>> >>
>> >>
>> >> >
>> >> >
>> >> > Vladimir.
>> >> >
>> >> > On Fri, Sep 8, 2017 at 7:06 AM, Dmitriy Setrakyan 
>> >> > mailto:dsetrak...@apache.org> 
>> >> > >>
>> >> > wrote:
>> >> >
>> >> > > I think it is safe to assume at this point that everyone is in general
>> >> > > agreement, since there are no active objections.
>> >> > >
>> >> > > I have filed a ticket for the 2.3 release. Let's try to make it 
>> >> > > happen:
>> >> > > https://issues.apache.org/jira/browse/IGNITE-6305 
>> >> > >  
>> >> > > > >> > > >
>> >> > >
>> >> > > D.
>> >> > >

Re: Logical Cache Documented

[Denis Magda]

Guys,

Another question. Does this capability enabled by default? If yes, how do we 
decide which group a cache goes to?

—
Denis

> On Sep 29, 2017, at 3:58 PM, Denis Magda  wrote:
> 
> Igniters,
> 
> I’ve put on paper the feature from the subj:
> https://apacheignite.readme.io/docs/logical-caches 
> 
> 
> Sam, will appreciate if you read through it and confirm I explained the topic 
> 100% technically correct.
> 
> However, are there any negative impacts of having logical caches? This page 
> has “Possible Impacts” section unfilled:
> https://cwiki.apache.org/confluence/display/IGNITE/Logical+Caches 
> 
> 
> —
> Denis

Re: Logical Cache Documented

[Vladimir Ozerov]

Folks,

Honesly, to me logical caches appears to be a dirty shortcut to mitigate
some inefficient internal implementation. Why can't we merge partition maps
in runtime? This should not be a problem for context-independent affinity
functions (e.g. RendezvousAffinityFunction). From user perspective logic
caches feature is:
1) Bad API. One cannot define group configuration. All you can do is to
define group name on cache lavel and hope that nobody started another cache
in the same group with different configuration before.
2) Performance impact for scans, as you have to iterate over mixed data.

Couldn't we fix partition map problem without cache groups?

On Sat, Sep 30, 2017 at 2:35 AM, Denis Magda  wrote:

> Guys,
>
> Another question. Does this capability enabled by default? If yes, how do
> we decide which group a cache goes to?
>
> —
> Denis
>
> > On Sep 29, 2017, at 3:58 PM, Denis Magda  wrote:
> >
> > Igniters,
> >
> > I’ve put on paper the feature from the subj:
> > https://apacheignite.readme.io/docs/logical-caches <
> https://apacheignite.readme.io/docs/logical-caches>
> >
> > Sam, will appreciate if you read through it and confirm I explained the
> topic 100% technically correct.
> >
> > However, are there any negative impacts of having logical caches? This
> page has “Possible Impacts” section unfilled:
> > https://cwiki.apache.org/confluence/display/IGNITE/Logical+Caches <
> https://cwiki.apache.org/confluence/display/IGNITE/Logical+Caches>
> >
> > —
> > Denis
>
>

Re: Logical Cache Documented

[Vladimir Ozerov]

And it will continue hitting us in future. For example, when data
compression is implemented, for logical caches compression rate will be
poor, as it would be impossbile to build efficient dictionaries in mixed
data pages.

On Sat, Sep 30, 2017 at 8:48 AM, Vladimir Ozerov 
wrote:

> Folks,
>
> Honesly, to me logical caches appears to be a dirty shortcut to mitigate
> some inefficient internal implementation. Why can't we merge partition maps
> in runtime? This should not be a problem for context-independent affinity
> functions (e.g. RendezvousAffinityFunction). From user perspective logic
> caches feature is:
> 1) Bad API. One cannot define group configuration. All you can do is to
> define group name on cache lavel and hope that nobody started another cache
> in the same group with different configuration before.
> 2) Performance impact for scans, as you have to iterate over mixed data.
>
> Couldn't we fix partition map problem without cache groups?
>
> On Sat, Sep 30, 2017 at 2:35 AM, Denis Magda  wrote:
>
>> Guys,
>>
>> Another question. Does this capability enabled by default? If yes, how do
>> we decide which group a cache goes to?
>>
>> —
>> Denis
>>
>> > On Sep 29, 2017, at 3:58 PM, Denis Magda  wrote:
>> >
>> > Igniters,
>> >
>> > I’ve put on paper the feature from the subj:
>> > https://apacheignite.readme.io/docs/logical-caches <
>> https://apacheignite.readme.io/docs/logical-caches>
>> >
>> > Sam, will appreciate if you read through it and confirm I explained the
>> topic 100% technically correct.
>> >
>> > However, are there any negative impacts of having logical caches? This
>> page has “Possible Impacts” section unfilled:
>> > https://cwiki.apache.org/confluence/display/IGNITE/Logical+Caches <
>> https://cwiki.apache.org/confluence/display/IGNITE/Logical+Caches>
>> >
>> > —
>> > Denis
>>
>>
>