Re: Geo spatial index

[Sergi Vladykin]

It must not be too hard to implement kd-tree over b+tree [1]. Depending on
level we have to compare either X or Y coordinate.

I think we will even have a performance boost for spatial indexes after
this change.

[1] https://en.wikipedia.org/wiki/K-d_tree

Sergi

2017-05-23 18:59 GMT+03:00 Denis Magda :

> +1
>
> This looks natural considering that we switched to the new memory
> architecture. Sergi, how difficult is to support this?
>
> —
> Denis
>
> > On May 23, 2017, at 4:25 AM, Sergi Vladykin 
> wrote:
> >
> > Guys,
> >
> > Looks like we have to move our geospatial indexes to the new approach
> with
> > BPlusTree. Right now it stores data in Java heap. This is especially
> > important because we are going to have a persistence layer donated by
> > GridGain and obviously geo spatial indexes will not work with it at all.
> >
> > Sergi
>
>

Re: Apache Zeppelin page on readme

[Denis Magda]

Roman, thanks for pointing out to this.


> On May 23, 2017, at 6:08 PM, Roman Shtykh  wrote:
> 
> Btw, some links at https://ignite.apache.org  are 
> broken. For instance, OSGI Support at 
> https://ignite.apache.org/features/datagrid.html 
> and many links at 
> https://ignite.apache.org/features/streaming.html 
> 
Prachi, would you review the pages and fix the links?

—
Denis

Re: Apache Zeppelin page on readme

[Roman Shtykh]

Hi Denis,
I was just using the drop-down to switch the versions from 
https://apacheignite-mix.readme.io/v1.7/docs and couldn't find it in the same 
subdomain. Now it's clear, thank you!

Btw, some links at https://ignite.apache.org are broken. For instance, OSGI 
Support at https://ignite.apache.org/features/datagrid.html and many links at 
https://ignite.apache.org/features/streaming.html
-- Roman



On Wednesday, May 24, 2017 12:46 AM, Denis Magda  wrote:
 

 Hi Roman,

It was moved to the another documentation domain:
https://apacheignite-tools.readme.io/docs/apache-zeppelin 


Where did you find the old reference?

—
Denis

> On May 22, 2017, at 11:40 PM, Roman Shtykh  wrote:
> 
> I noticed the latest Apache Zeppelin integration page on readme is 1.7, but 
> there are integrations for 1.8 and 1.9 too. Missing update?
> 
> https://apacheignite-mix.readme.io/v1.7/docs/apache-zeppelin
> -- Roman


   

Re: Inefficient approach to executing remote SQL queries

[Dmitriy Setrakyan]

Got it. In this case we should definitely connect concurrently, not in
parallel. I set the ticket to 2.1 release. Let's see if anyone picks it up.

On Tue, May 23, 2017 at 2:56 PM, Michael Griggs  wrote:

> The problem here is with the initial opening of connections. With a client
> who connects and disconnects quickly, and frequently, a 30-second plus
> connection time is not workable.
>
> Mike
>
> On 23 May 2017 6:51 pm, "Dmitriy Setrakyan"  wrote:
>
> > Why do we turn off the connections, once established? Why not keep them
> > open, until an endpoint explicitly closes them?
> >
> > On Tue, May 23, 2017 at 2:16 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > Michael,
> > >
> > > I see your point. I think it must not be too hard to start
> asynchronously
> > > establishing connections to all the needed nodes.
> > >
> > > I've created respective issue in Jira:
> > > https://issues.apache.org/jira/browse/IGNITE-5277
> > >
> > > Sergi
> > >
> > > 2017-05-23 11:56 GMT+03:00 Michael Griggs  >:
> > >
> > > > Hi Val
> > > >
> > > > This is precisely my point: it's only a minor optimization until the
> > > point
> > > > when establishing each connection takes 3-4 seconds, and we establish
> > 32
> > > of
> > > > them in sequence.  At that point it becomes a serious issue: the
> > customer
> > > > cannot run SQL queries from their development machines without them
> > > timing
> > > > out once out of every two or three runs.  These kind of problems
> > > undermine
> > > > confidence in Ignite.
> > > >
> > > > Mike
> > > >
> > > >
> > > > -Original Message-
> > > > From: Valentin Kulichenko [mailto:valentin.kuliche...@gmail.com]
> > > > Sent: 22 May 2017 19:15
> > > > To: dev@ignite.apache.org
> > > > Subject: Re: Inefficient approach to executing remote SQL queries
> > > >
> > > > Hi Mike,
> > > >
> > > > Generally, establishing connections in parallel could make sense, but
> > > note
> > > > that in most this would be a minor optimization, because:
> > > >
> > > >- Under load connections are established once and then reused. If
> > you
> > > >observe disconnections during application lifetime under load,
> then
> > > >probably this should be addressed first.
> > > >- Actual communication is asynchronous, we use NIO for this. If
> > > >connection already exists, sendGeneric() basically just puts a
> > message
> > > > into
> > > >a queue.
> > > >
> > > > -Val
> > > >
> > > > On Mon, May 22, 2017 at 7:04 PM, Michael Griggs <
> > > > michael.gri...@gridgain.com
> > > > > wrote:
> > > >
> > > > > Hi Igniters,
> > > > >
> > > > >
> > > > >
> > > > > Whilst diagnosing a problem with a slow query, I became aware of a
> > > > > potential issue in the Ignite codebase.  When executing a SQL query
> > > > > that is to run remotely, the IgniteH2Indexing#send() method is
> > called,
> > > > > with a Collection as one of its parameters.  This
> > > > > collection is iterated sequentially, and ctx.io().sendGeneric() is
> > > > > called synchronously for each node.  This is inefficient if
> > > > >
> > > > >
> > > > >
> > > > > a)   This is the first execution of a query, and thus TCP
> > > connections
> > > > > have to be established
> > > > >
> > > > > b)  The cost of establishing a TCP connection is high
> > > > >
> > > > >
> > > > >
> > > > > And optionally
> > > > >
> > > > >
> > > > >
> > > > > c)   There are a large number of nodes in the cluster
> > > > >
> > > > >
> > > > >
> > > > > In my current situation, developers want to run test queries from
> > > > > their code running locally, but connected via VPN to their UAT
> server
> > > > > environment.
> > > > > The
> > > > > cost of opening a TCP connection is in the multiple seconds, as you
> > > > > can see from this Ignite log file snippet:
> > > > >
> > > > > 2017-05-22 18:29:48,908 INFO [TcpCommunicationSpi] - Established
> > > > > outgoing communication connection [locAddr=/7.1.14.242:56924,
> > > > > rmtAddr=/10.132.80.3:47100]
> > > > >
> > > > > 2017-05-22 18:29:52,294 INFO [TcpCommunicationSpi] - Established
> > > > > outgoing communication connection [locAddr=/7.1.14.242:56923,
> > > > > rmtAddr=/10.132.80.30:47102]
> > > > >
> > > > > 2017-05-22 18:29:58,659 INFO [TcpCommunicationSpi] - Established
> > > > > outgoing communication connection [locAddr=/7.1.14.242:56971,
> > > > > rmtAddr=/10.132.80.23:47101]
> > > > >
> > > > > 2017-05-22 18:30:03,183 INFO [TcpCommunicationSpi] - Established
> > > > > outgoing communication connection [locAddr=/7.1.14.242:56972,
> > > > > rmtAddr=/10.132.80.21:47100]
> > > > >
> > > > > 2017-05-22 18:30:06,039 INFO [TcpCommunicationSpi] - Established
> > > > > outgoing communication connection [locAddr=/7.1.14.242:56973,
> > > > > rmtAddr=/10.132.80.21:47103]
> > > > >
> > > > > 2017-05-22 18:30:10,828 INFO [TcpCommunicationSpi] - Established
> > > > > outgoing communication 

Re: Inefficient approach to executing remote SQL queries

[Michael Griggs]

The problem here is with the initial opening of connections. With a client
who connects and disconnects quickly, and frequently, a 30-second plus
connection time is not workable.

Mike

On 23 May 2017 6:51 pm, "Dmitriy Setrakyan"  wrote:

> Why do we turn off the connections, once established? Why not keep them
> open, until an endpoint explicitly closes them?
>
> On Tue, May 23, 2017 at 2:16 AM, Sergi Vladykin 
> wrote:
>
> > Michael,
> >
> > I see your point. I think it must not be too hard to start asynchronously
> > establishing connections to all the needed nodes.
> >
> > I've created respective issue in Jira:
> > https://issues.apache.org/jira/browse/IGNITE-5277
> >
> > Sergi
> >
> > 2017-05-23 11:56 GMT+03:00 Michael Griggs :
> >
> > > Hi Val
> > >
> > > This is precisely my point: it's only a minor optimization until the
> > point
> > > when establishing each connection takes 3-4 seconds, and we establish
> 32
> > of
> > > them in sequence.  At that point it becomes a serious issue: the
> customer
> > > cannot run SQL queries from their development machines without them
> > timing
> > > out once out of every two or three runs.  These kind of problems
> > undermine
> > > confidence in Ignite.
> > >
> > > Mike
> > >
> > >
> > > -Original Message-
> > > From: Valentin Kulichenko [mailto:valentin.kuliche...@gmail.com]
> > > Sent: 22 May 2017 19:15
> > > To: dev@ignite.apache.org
> > > Subject: Re: Inefficient approach to executing remote SQL queries
> > >
> > > Hi Mike,
> > >
> > > Generally, establishing connections in parallel could make sense, but
> > note
> > > that in most this would be a minor optimization, because:
> > >
> > >- Under load connections are established once and then reused. If
> you
> > >observe disconnections during application lifetime under load, then
> > >probably this should be addressed first.
> > >- Actual communication is asynchronous, we use NIO for this. If
> > >connection already exists, sendGeneric() basically just puts a
> message
> > > into
> > >a queue.
> > >
> > > -Val
> > >
> > > On Mon, May 22, 2017 at 7:04 PM, Michael Griggs <
> > > michael.gri...@gridgain.com
> > > > wrote:
> > >
> > > > Hi Igniters,
> > > >
> > > >
> > > >
> > > > Whilst diagnosing a problem with a slow query, I became aware of a
> > > > potential issue in the Ignite codebase.  When executing a SQL query
> > > > that is to run remotely, the IgniteH2Indexing#send() method is
> called,
> > > > with a Collection as one of its parameters.  This
> > > > collection is iterated sequentially, and ctx.io().sendGeneric() is
> > > > called synchronously for each node.  This is inefficient if
> > > >
> > > >
> > > >
> > > > a)   This is the first execution of a query, and thus TCP
> > connections
> > > > have to be established
> > > >
> > > > b)  The cost of establishing a TCP connection is high
> > > >
> > > >
> > > >
> > > > And optionally
> > > >
> > > >
> > > >
> > > > c)   There are a large number of nodes in the cluster
> > > >
> > > >
> > > >
> > > > In my current situation, developers want to run test queries from
> > > > their code running locally, but connected via VPN to their UAT server
> > > > environment.
> > > > The
> > > > cost of opening a TCP connection is in the multiple seconds, as you
> > > > can see from this Ignite log file snippet:
> > > >
> > > > 2017-05-22 18:29:48,908 INFO [TcpCommunicationSpi] - Established
> > > > outgoing communication connection [locAddr=/7.1.14.242:56924,
> > > > rmtAddr=/10.132.80.3:47100]
> > > >
> > > > 2017-05-22 18:29:52,294 INFO [TcpCommunicationSpi] - Established
> > > > outgoing communication connection [locAddr=/7.1.14.242:56923,
> > > > rmtAddr=/10.132.80.30:47102]
> > > >
> > > > 2017-05-22 18:29:58,659 INFO [TcpCommunicationSpi] - Established
> > > > outgoing communication connection [locAddr=/7.1.14.242:56971,
> > > > rmtAddr=/10.132.80.23:47101]
> > > >
> > > > 2017-05-22 18:30:03,183 INFO [TcpCommunicationSpi] - Established
> > > > outgoing communication connection [locAddr=/7.1.14.242:56972,
> > > > rmtAddr=/10.132.80.21:47100]
> > > >
> > > > 2017-05-22 18:30:06,039 INFO [TcpCommunicationSpi] - Established
> > > > outgoing communication connection [locAddr=/7.1.14.242:56973,
> > > > rmtAddr=/10.132.80.21:47103]
> > > >
> > > > 2017-05-22 18:30:10,828 INFO [TcpCommunicationSpi] - Established
> > > > outgoing communication connection [locAddr=/7.1.14.242:57020,
> > > > rmtAddr=/10.132.80.20:47100]
> > > >
> > > > 2017-05-22 18:30:13,060 INFO [TcpCommunicationSpi] - Established
> > > > outgoing communication connection [locAddr=/7.1.14.242:57021,
> > > > rmtAddr=/10.132.80.29:47103]
> > > >
> > > > 2017-05-22 18:30:22,144 INFO [TcpCommunicationSpi] - Established
> > > > outgoing communication connection [locAddr=/7.1.14.242:57022,
> > > > rmtAddr=/10.132.80.22:47103]
> > > >
> > > > 2017-05-22 18:30:26,513 INFO 

[jira] [Created] (IGNITE-5285) Update metrics documentation

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5285:
---

 Summary: Update metrics documentation
 Key: IGNITE-5285
 URL: https://issues.apache.org/jira/browse/IGNITE-5285
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


1) Describe new metrics related to the Persistent Store.
2) Update the existing metrics: 
https://issues.apache.org/jira/browse/IGNITE-5124



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: IGNITE-5124 is ready for review

[Denis Magda]

Sergey,

Thanks, reviewed and left the notes in the upsource.

—
Denis

> On May 23, 2017, at 1:44 AM, Sergey Chugunov  
> wrote:
> 
> Hello Igniters,
> 
> I implemented UX improvements for MemoryMetrics and added/clarified some
> documentation to public API.
> 
> Please find changes under pull request here
> , for discussions feel free to
> leave comments in upsource review
> .
> 
> Thanks,
> Sergey.

[GitHub] ignite pull request #1999: IGNITE-5284

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5284



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

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

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

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


commit 99d2299d0964c163396c9335b9de098f5c533b8a
Author: devozerov 
Date:   2017-05-23T11:44:56Z

WIP.

commit 56a6bf342f3b213ec2a6ffb37657605b39a5e8fc
Author: devozerov 
Date:   2017-05-23T11:47:08Z

WIP.

commit ea983d7a5fe1bbe6aa34baed2600df61f018484f
Author: devozerov 
Date:   2017-05-23T12:01:46Z

WIP.

commit f046fe04952e78a94af97a9e361012409b6b1a7c
Author: devozerov 
Date:   2017-05-23T12:02:41Z

Done.

commit 21f94a2a2460b8b2a17bfa989f94735c6661211f
Author: devozerov 
Date:   2017-05-23T12:45:44Z

Done.

commit 650c6f537567e1008360e25b348bd5e53baed5e8
Author: devozerov 
Date:   2017-05-23T17:45:03Z

Merge branch 'master' into ignite-5282

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheProxy.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryIndexing.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryProcessor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/DmlStatementsProcessor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java

commit e126c89792259e88ead379607f7ae3c7efb6f681
Author: devozerov 
Date:   2017-05-23T18:03:04Z

WIP.

commit adc79f578e211fdeca5908ecc400d90103f63b76
Author: devozerov 
Date:   2017-05-23T18:10:52Z

WIP on removing cache name.

commit eb2b21a630e5ff25fb01da01ba848b789d00e9b8
Author: devozerov 
Date:   2017-05-23T18:24:52Z

Splitting H2 indexing.

commit 546e82d055db1e1bbd3c08945bdea916b64d0dd8
Author: devozerov 
Date:   2017-05-23T19:33:37Z

FIxed DML.

commit 607bfc25892d6dc447d6db6482aa8697972e7624
Author: devozerov 
Date:   2017-05-23T19:39:09Z

Merge branch 'ignite-5282' into ignite-5282-1

# Conflicts:
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/DmlStatementsProcessor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java

commit 8c44cec3c691f4f1b2789df319e1d5e0dcc333f1
Author: devozerov 
Date:   2017-05-23T20:33:19Z

WIP.

commit 2faca3facb56ec20cff3cb7d607939c48e18c616
Author: devozerov 
Date:   2017-05-23T20:35:37Z

Removed unused methods.

commit 2acde63c558943dd9f3dd624649b4a1469d3b105
Author: devozerov 
Date:   2017-05-23T20:36:50Z

Dangerous commit: removed cacheNameForSchemaAndTable.

commit bc5dc7880115e19b3d828d415d27e0b09a6d670b
Author: devozerov 
Date:   2017-05-23T20:37:37Z

Revert dangerous commit.

commit a0a1c4a3de4d3b2eb94fab12f04b7916df2f0fbb
Author: devozerov 
Date:   2017-05-23T20:48:22Z

Finished.

commit b7863c9c9abe846fdc84c12a563096ce2ced0d37
Author: devozerov 
Date:   2017-05-23T21:05:20Z

Merge branch 'master' into ignite-5284

# Conflicts:
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/DmlStatementsProcessor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1993: IGNITE-5282

[devozerov]

Github user devozerov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-5284) Split IgniteH2Indexing into multiple classes if possible

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5284:
---

 Summary: Split IgniteH2Indexing into multiple classes if possible
 Key: IGNITE-5284
 URL: https://issues.apache.org/jira/browse/IGNITE-5284
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.1


{{IgniteH2Indexing}} is overly complex. Let's move inner classes out of it 
where applicable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Remove/deprecate CacheConfiguration.sqlEscapeAll property

[Vladimir Ozerov]

Igniters,

We have a property "CacheConfiguration.sqlEscapeAll". When enabled, all
database objects belonging to the cache will be case-sensitive and allow
special characters. Two problems here:

1) It doesn't allow me to decouple schemas from cache easily since I it
force me to refer to cache context everywhere, exactly what I am trying to
avoid.

2) It doesn't work with DDL at all. E.g. how should I process "MyIndex" if
cache has "sqlEscapeAll=false"?
CREATE INDEX "MyIndex" ON TABLE MY_TABLE;

It appears, that we should do the following:
1) Remove/deprecate this property;
2) Add "escaped" property to QueryEntity and QueryIndex, so that decision
can be made on per-object basis, rather than on per-cache.
3) In DDL we should decide whether object name is case-sensitive based on
quotes around it's name:

CREATE INDEX MyIndex;   // Insensitive
CREATE INDEX "MyIndex"; // Sensitive

E.g. this is precisely how Oracle and probably other databases work.

Thoughts?

Re: Session Replication Update on spring boot platform

[Rishi Yagnik]

Hello Val,

we are in the middle of the sprint so cant hijack any of our environment
but would keep you posted with the timelines.

Thank you for all your help,
Rishi

On Tue, May 23, 2017 at 2:37 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Rishi,
>
> It was working for me in cluster environment after the fix [1] we
> discussed in previous thread [2]. The fix was included in Ignite 2.0.
>
> Can you please reattach the latest version of your app based on Ignite 2.0
> and give a detailed step by step instruction on how to reproduce the issue
> you're having?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4948
> [2] http://apache-ignite-developers.2346864.n4.nabble.
> com/IGNITE-2741-spring-session-design-td14560.html
>
> -Val
>
> On Mon, May 22, 2017 at 8:35 PM, Rishi Yagnik 
> wrote:
>
>> Hello Val,
>>
>> As I discussed earlier, the problem arises in the cluster environment.
>>
>> we have 2 SB staleless instance backed by Ignite data store.
>>
>> The local environment is working fine and I am able to see the user
>> sessions are being stored correctly.
>>
>> I could not make session replication working with Ignite 2.0 in cluster
>> environment so my fixes are of no use.
>>
>> IMO,The web filter approach is very intrusive approach with spring
>> security and that is why I thought we need to come up with the solution
>> which sits on top of spring security.
>>
>> The possible solution could be spring session.
>>
>> The example which I posted can be tested on cluster as well. Would Ignite
>> team try out the clustering ?
>>
>> Looking for your inputs / suggestions on the issue.
>>
>> Thank you for all your help,
>> Rishi
>>
>>
>>
>>
>> On Mon, May 22, 2017 at 1:02 PM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>>> Hi Rishi,
>>>
>>> I'm not sure I understand what the issue is. Can you elaborate a bit
>>> more and provide exact examples of what is not working? What code tweaks
>>> are required and how critical are they? Also I recall that your example was
>>> working fine after the latest fixes in 1.9 (if I'm not mistaken). Did you
>>> make any changes after that?
>>>
>>> -Val
>>>
>>> On Fri, May 19, 2017 at 11:34 PM, Rishi Yagnik 
>>> wrote:
>>>
 Hello Dmitriy,

 Thank you for the response, I would await for Val's feedback.

 I would like to discuss the possible approach for implementation here,
 and
 it could be one of this -

 https://issues.apache.org/jira/browse/IGNITE-2741

 Hope we all come on to conclusion here.

 Thanks,

 On Fri, May 19, 2017 at 3:57 PM, Dmitriy Setrakyan <
 dsetrak...@apache.org>
 wrote:

 > Hi Rishi,
 >
 > I think the best way is to file a ticket in Ignite Jira with your
 > findings. This ticket does not seem tremendously difficult, so
 hopefully
 > someone from the community will pick it up. All we need to do is to
 take
 > our existing Web Session Clustering [1][2] code and port it to work
 with
 > Spring Boot.
 >
 > BTW, feel free to contribute it yourself if you have time.
 >
 > [1] https://ignite.apache.org/use-cases/caching/web-session-
 > clustering.html
 > [2] https://apacheignite-mix.readme.io/docs/web-session-clustering
 >
 > D.
 >
 > On Fri, May 19, 2017 at 11:43 AM, Rishi Yagnik 
 > wrote:
 >
 >> Hello Val,
 >>
 >> I tested out the session replication on spring boot cluster and here
 is
 >> the
 >> result.
 >>
 >> My finding were as follows with Ignite 2.0 on session replication
 and hope
 >> that helps the team –
 >>
 >>- Spring Security Filters requires context to be set with
 >> Authentication
 >>object, later on when user authentication object is set on the
 ignite
 >>filter from Ignite cache, the spring security treat that as a new
 >> session
 >>just to prevent session fixation issue.
 >>- As spring security creates a new session and since there is no
 way to
 >>tell Ignite that user session has been changed, the user session
 is no
 >> good
 >>here despite the fact that user session holds by the ignite is a
 true
 >>session for that user.
 >>- Configuring web session filter does not work OOTB in spring boot
 >>platform, it require some additional tweaking in the code to make
 it
 >> work.
 >>
 >>
 >> So in the nutshell, I would think having spring session on ignite
 platform
 >> would support full session replication with spring boot platform.
 >>
 >>
 >> Please note that we have 2 SB instances, serving request round robin
 via
 >> F5
 >> ( load balancers) supported by 2 node ignite cluster.
 >>
 >> Any suggestions on how we want to conquer the issue ?
 >>
 >> 

[GitHub] ignite pull request #1992: IGNITE-5281

[devozerov]

Github user devozerov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Inefficient approach to executing remote SQL queries

[Dmitriy Setrakyan]

Why do we turn off the connections, once established? Why not keep them
open, until an endpoint explicitly closes them?

On Tue, May 23, 2017 at 2:16 AM, Sergi Vladykin 
wrote:

> Michael,
>
> I see your point. I think it must not be too hard to start asynchronously
> establishing connections to all the needed nodes.
>
> I've created respective issue in Jira:
> https://issues.apache.org/jira/browse/IGNITE-5277
>
> Sergi
>
> 2017-05-23 11:56 GMT+03:00 Michael Griggs :
>
> > Hi Val
> >
> > This is precisely my point: it's only a minor optimization until the
> point
> > when establishing each connection takes 3-4 seconds, and we establish 32
> of
> > them in sequence.  At that point it becomes a serious issue: the customer
> > cannot run SQL queries from their development machines without them
> timing
> > out once out of every two or three runs.  These kind of problems
> undermine
> > confidence in Ignite.
> >
> > Mike
> >
> >
> > -Original Message-
> > From: Valentin Kulichenko [mailto:valentin.kuliche...@gmail.com]
> > Sent: 22 May 2017 19:15
> > To: dev@ignite.apache.org
> > Subject: Re: Inefficient approach to executing remote SQL queries
> >
> > Hi Mike,
> >
> > Generally, establishing connections in parallel could make sense, but
> note
> > that in most this would be a minor optimization, because:
> >
> >- Under load connections are established once and then reused. If you
> >observe disconnections during application lifetime under load, then
> >probably this should be addressed first.
> >- Actual communication is asynchronous, we use NIO for this. If
> >connection already exists, sendGeneric() basically just puts a message
> > into
> >a queue.
> >
> > -Val
> >
> > On Mon, May 22, 2017 at 7:04 PM, Michael Griggs <
> > michael.gri...@gridgain.com
> > > wrote:
> >
> > > Hi Igniters,
> > >
> > >
> > >
> > > Whilst diagnosing a problem with a slow query, I became aware of a
> > > potential issue in the Ignite codebase.  When executing a SQL query
> > > that is to run remotely, the IgniteH2Indexing#send() method is called,
> > > with a Collection as one of its parameters.  This
> > > collection is iterated sequentially, and ctx.io().sendGeneric() is
> > > called synchronously for each node.  This is inefficient if
> > >
> > >
> > >
> > > a)   This is the first execution of a query, and thus TCP
> connections
> > > have to be established
> > >
> > > b)  The cost of establishing a TCP connection is high
> > >
> > >
> > >
> > > And optionally
> > >
> > >
> > >
> > > c)   There are a large number of nodes in the cluster
> > >
> > >
> > >
> > > In my current situation, developers want to run test queries from
> > > their code running locally, but connected via VPN to their UAT server
> > > environment.
> > > The
> > > cost of opening a TCP connection is in the multiple seconds, as you
> > > can see from this Ignite log file snippet:
> > >
> > > 2017-05-22 18:29:48,908 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:56924,
> > > rmtAddr=/10.132.80.3:47100]
> > >
> > > 2017-05-22 18:29:52,294 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:56923,
> > > rmtAddr=/10.132.80.30:47102]
> > >
> > > 2017-05-22 18:29:58,659 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:56971,
> > > rmtAddr=/10.132.80.23:47101]
> > >
> > > 2017-05-22 18:30:03,183 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:56972,
> > > rmtAddr=/10.132.80.21:47100]
> > >
> > > 2017-05-22 18:30:06,039 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:56973,
> > > rmtAddr=/10.132.80.21:47103]
> > >
> > > 2017-05-22 18:30:10,828 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:57020,
> > > rmtAddr=/10.132.80.20:47100]
> > >
> > > 2017-05-22 18:30:13,060 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:57021,
> > > rmtAddr=/10.132.80.29:47103]
> > >
> > > 2017-05-22 18:30:22,144 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:57022,
> > > rmtAddr=/10.132.80.22:47103]
> > >
> > > 2017-05-22 18:30:26,513 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:57024,
> > > rmtAddr=/10.132.80.20:47101]
> > >
> > > 2017-05-22 18:30:28,526 INFO [TcpCommunicationSpi] - Established
> > > outgoing communication connection [locAddr=/7.1.14.242:57025,
> > > rmtAddr=/10.132.80.30:47103]
> > >
> > >
> > >
> > > Comparing the same code that is executed inside of the UAT environment
> > > (so not using the VPN):
> > >
> > > 2017-05-22 18:22:18,102 INFO [TcpCommunicationSpi] - Established
> > > outgoing 

Re: [VOTE] Accept Contribution of Ignite Persistent Store

[Dmitriy Setrakyan]

+1

Raul, I think everyone got confused on the process. At this point, the code
has not been merged to master, and is sitting in a separate branch. I would
recommend that we proceed with the vote. If the vote is declined, then we
will toss the branch.

I believe that once this feature is fully released, which will make Apache
Ignite into an SQL database and In-Memory data grid at the same time, the
community and user base of Apache Ignite will get a healthy boost.

D.

On Tue, May 23, 2017 at 2:53 AM, Raúl Kripalani 
wrote:

> I'm not sure what the vote is for, if the code has already been merged to
> the ASF repo — even if on a branch.
>
> I do accept the donation but I think the code should have remained outside
> the official codebase until the VOTE passed.
>
> Not sure what the rest think.
>
> On 22 May 2017 22:55, "Denis Magda"  wrote:
>
> > Igniters,
> >
> > This branch (https://github.com/apache/ignite/tree/ignite-5267) adds a
> > distributed and transactional Persistent Store to Apache Ignite project.
> > The store seamlessly integrates with Apache Ignite 2.0 page memory
> > architecture. One of the main advantages of the store is that Apache
> Ignite
> > becomes fully operational from disk (SSD or Flash) without any need to
> > preload the data in memory. Plus, with full SQL support already available
> > in Apache Ignite, this feature will allow Apache Ignite serve as a
> > distributed SQL database, both in memory or on disk, while continuing to
> > support all the existing functionality on the current API.
> > More information here:
> > - Persistent Store Overview: https://cwiki.apache.org/
> > confluence/display/IGNITE/Persistent+Store+Overview
> > - Persistent Store Internal Design: https://cwiki.apache.org/
> > confluence/display/IGNITE/Persistent+Store+Internal+Design
> > The Persistent Store was developed by GridGain outside of Apache
> community
> > because it was requested by one of GridGain’s customers. Presently,
> > GridGain looks forward to donating the Persistent Store to ASF and given
> > the size of the contribution, it is prudent to follow Apache's IP
> clearance
> > process.
> > The SGA has been submitted and acknowledged by ASF Secretary. The IP
> > clearance form can be found here: http://incubator.apache.org/
> > ip-clearance/persistent-distributed-store-ignite.html
> > This vote is to discover if the Apache Ignite PMC and community are in
> > favour of accepting this contribution.
> > This vote will be open for at least 72 hours:
> > [ ] +1, accept contribution of the Persistent Store into the project
> > [ ] 0, no opinion
> > [ ] -1, reject contribution because...
> >
> > Regards,
> > Denis
> >
> >
>

Re: IGNITE-532 ready for review

[Denis Magda]

Roman,

Would you mind reviewing the contribution?

—
Denis

> On May 23, 2017, at 8:38 AM, Kozlov Maxim  wrote:
> 
> Hi guys!
> 
> Review please - https://github.com/apache/ignite/pull/1998 
> 
> https://issues.apache.org/jira/browse/IGNITE-532 
> 
> 
> I'm add Akka Stream and Akka Actor integration, please see the solution. 
> There is a question that the guru scala would like to ask. First 
> implementation actor stream created a trait StreamAdapterTrait 
> (IgniteAkkaActorStreamer.scala), because "extends Actor with StreamAdapter[T, 
> K, V]" as "with" means that the class is using a Trait via mixin. Second 
> implementation actor stream IgniteAkkaActorStreamerJava.scala "extends 
> StreamAdapter[T, K, V] with Actor" use default abstract class StreamAdapter. 
> Which option is better?
> 
> --
> Best Regards,
> Max K.
> 
> 
> 
> 

Re: Upgrade dependency to outdated Lucene 3.5.0

[Sergey Kozlov]

Hi Andrey

I see 5.5.4 in maven repository
https://mvnrepository.com/artifact/org.apache.lucene/lucene-core/5.5.4

On Tue, May 23, 2017 at 6:48 PM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:

> Thanks. This fact was missed in migration guide.
>
> We have dependency to lucene in our osgi module, that refer to Apache
> ServiceMix :: Bundles  [1] .
> I can't see bundle for Lucene-5.5.4 in list, but there is a bundle for
> Lucene-5.5.2.
>
> Let's upgrade to Lucene-5.5.2.
>
> [1]
> https://mvnrepository.com/artifact/org.apache.
> servicemix.bundles/org.apache.servicemix.bundles.lucene
>
>
> On Tue, May 23, 2017 at 6:07 PM, 李玉珏@163 <18624049...@163.com> wrote:
>
> > Lucene6 requires JDK8 and later versions, and I think it might be
> > reasonable to update to the Lucene5.5.4 version.
> >
> >
> >
> > 在 2017/5/23 22:07, Andrey Mashenkov 写道:
> >
> >> Hi Igniters,
> >>
> >> Ignite-indexing module has outdated dependency to apache-lucene-3.5.0,
> >> however, actual version of lucene for now is 6.5.1. Here is a ticket
> [1].
> >>
> >> Store format version of 3.x is deprecated in 4.x and does not supported
> at
> >> all
> >> in higher versions, that cause difficulties to integrate with ignite on
> >> user side.
> >>
> >> Apache Lucene 6.x seems doen't support <=4.x index format,
> >> but 5.x index format can be used via additional jar with old codecs.
> >>
> >> Also, I've found GridLuceneIndex stores index in offheap via old
> approach
> >> and
> >> page memory is not supported, so it can't be persisted (looking forward
> to
> >> PDS).
> >>
> >> Seems, we will not break any compatibility if we upgrade lucene version
> in
> >> 2.1,
> >> until (or together with) Ignite full-text-search component supports page
> >> memory and PDS merged to ignite.
> >> I think we should upgrade to latest 6.x version, as it will much harder
> to
> >> do it later.
> >>
> >>
> >> Is there any cons\pros to upgrade lucene dependency up to latest 6.x
> >> version?
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-3562
> >>
> >>
> >
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Geo spatial index

[Denis Magda]

+1

This looks natural considering that we switched to the new memory architecture. 
Sergi, how difficult is to support this?

—
Denis

> On May 23, 2017, at 4:25 AM, Sergi Vladykin  wrote:
> 
> Guys,
> 
> Looks like we have to move our geospatial indexes to the new approach with
> BPlusTree. Right now it stores data in Java heap. This is especially
> important because we are going to have a persistence layer donated by
> GridGain and obviously geo spatial indexes will not work with it at all.
> 
> Sergi

Re: Upgrade dependency to outdated Lucene 3.5.0

[Andrey Mashenkov]

Thanks. This fact was missed in migration guide.

We have dependency to lucene in our osgi module, that refer to Apache
ServiceMix :: Bundles  [1] .
I can't see bundle for Lucene-5.5.4 in list, but there is a bundle for
Lucene-5.5.2.

Let's upgrade to Lucene-5.5.2.

[1]
https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.lucene


On Tue, May 23, 2017 at 6:07 PM, 李玉珏@163 <18624049...@163.com> wrote:

> Lucene6 requires JDK8 and later versions, and I think it might be
> reasonable to update to the Lucene5.5.4 version.
>
>
>
> 在 2017/5/23 22:07, Andrey Mashenkov 写道:
>
>> Hi Igniters,
>>
>> Ignite-indexing module has outdated dependency to apache-lucene-3.5.0,
>> however, actual version of lucene for now is 6.5.1. Here is a ticket [1].
>>
>> Store format version of 3.x is deprecated in 4.x and does not supported at
>> all
>> in higher versions, that cause difficulties to integrate with ignite on
>> user side.
>>
>> Apache Lucene 6.x seems doen't support <=4.x index format,
>> but 5.x index format can be used via additional jar with old codecs.
>>
>> Also, I've found GridLuceneIndex stores index in offheap via old approach
>> and
>> page memory is not supported, so it can't be persisted (looking forward to
>> PDS).
>>
>> Seems, we will not break any compatibility if we upgrade lucene version in
>> 2.1,
>> until (or together with) Ignite full-text-search component supports page
>> memory and PDS merged to ignite.
>> I think we should upgrade to latest 6.x version, as it will much harder to
>> do it later.
>>
>>
>> Is there any cons\pros to upgrade lucene dependency up to latest 6.x
>> version?
>>
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-3562
>>
>>
>
>


-- 
Best regards,
Andrey V. Mashenkov

Re: Apache Zeppelin page on readme

[Denis Magda]

Hi Roman,

It was moved to the another documentation domain:
https://apacheignite-tools.readme.io/docs/apache-zeppelin 


Where did you find the old reference?

—
Denis

> On May 22, 2017, at 11:40 PM, Roman Shtykh  wrote:
> 
> I noticed the latest Apache Zeppelin integration page on readme is 1.7, but 
> there are integrations for 1.8 and 1.9 too. Missing update?
> 
> https://apacheignite-mix.readme.io/v1.7/docs/apache-zeppelin
> -- Roman

IGNITE-532 ready for review

[Kozlov Maxim]

Hi guys!

Review please - https://github.com/apache/ignite/pull/1998 

https://issues.apache.org/jira/browse/IGNITE-532 


I'm add Akka Stream and Akka Actor integration, please see the solution. 
There is a question that the guru scala would like to ask. First implementation 
actor stream created a trait StreamAdapterTrait 
(IgniteAkkaActorStreamer.scala), because "extends Actor with StreamAdapter[T, 
K, V]" as "with" means that the class is using a Trait via mixin. Second 
implementation actor stream IgniteAkkaActorStreamerJava.scala "extends 
StreamAdapter[T, K, V] with Actor" use default abstract class StreamAdapter. 
Which option is better?

--
Best Regards,
Max K.

[GitHub] ignite pull request #1998: IGNITE-532: Implement IgniteAkkaStreamer to strea...

[dream-x]

GitHub user dream-x opened a pull request:

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

IGNITE-532: Implement IgniteAkkaStreamer to stream data from Akka actors.



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

$ git pull https://github.com/dream-x/ignite ignite-532

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

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


commit f47ab06b1ca4416eefc10ee80237898864dc67e5
Author: Max Kozlov 
Date:   2017-04-03T14:02:17Z

Init akka stream module.

commit d105635dbe0ae8617404ef82a933a181a07cad8e
Author: Max Kozlov 
Date:   2017-04-04T09:49:09Z

Add akka-actor and -stream dependency in pom.xml.

commit d44d4edaa07d11b9e69aef5e20f4e4ab1249d64e
Author: Max Kozlov 
Date:   2017-04-06T16:45:54Z

Update akka dependency.

commit c63fc6290558fb552fb84e1213d2f85c9e51ddc6
Author: Max Kozlov 
Date:   2017-04-06T16:46:19Z

wip

commit 4aafc72c70941c89da36a26d3d00e23f2f384246
Author: Max Kozlov 
Date:   2017-04-13T08:47:01Z

Add akka-stream streamer.

commit f9b35d691517822fee29dd61cc10b4b160bbd3f6
Author: Max Kozlov 
Date:   2017-04-13T08:47:15Z

Add akka-stream streamer test.

commit b79bc8dfaf9e7ef8a385ee245b09629216e10b17
Author: Max Kozlov 
Date:   2017-04-13T08:47:36Z

Delete ExampleAkkaStreamToIgniteStream.java

commit a835cee93c86ba5f9f5119621d2e5efe73423ed5
Author: Max Kozlov 
Date:   2017-04-13T09:01:56Z

Delete onComplete test.

commit 513d3c75be5ec625f1ca5b6b3d3b27ed2d75aab3
Author: Max Kozlov 
Date:   2017-04-13T10:45:51Z

wip.

commit 924c9ae96b0a91c662ad9c06bd7c919f4935faf6
Author: Max Kozlov 
Date:   2017-04-14T08:24:28Z

Change version akka to 2.5.

commit 09d26b9972931e5595a7bb30e9796ef8816ff455
Author: Max Kozlov 
Date:   2017-04-18T14:35:18Z

Ignite streamer based on Scala Actor.

commit cc3548f429484e24a2454ec2e98961d102e3fe55
Author: Max Kozlov 
Date:   2017-04-19T13:57:29Z

Refactoring.

commit a912475488da162df8f7662489382fec90716024
Author: Max Kozlov 
Date:   2017-04-27T14:35:59Z

wip

commit 5dde548ff359f466de9df155aacc093cbfab77fd
Author: Max Kozlov 
Date:   2017-05-02T13:32:52Z

Add test akka actor streamer.

commit cb45c197d377e13f9d489bcc562615d8d7e5a3a2
Author: Max Kozlov 
Date:   2017-05-03T11:10:36Z

Refactoring scala tests.

commit b5be16c5221a91467699aec487543c676635433b
Author: Max Kozlov 
Date:   2017-05-03T11:15:14Z

Update akka to 2.5

commit ffc3c9975e6dd8fb2e881d6a0c6b3f2708208874
Author: Max Kozlov 
Date:   2017-05-03T12:33:18Z

Update pom.xml

commit 6e9203eec0096f168c89158c16659808f14cc498
Author: Max Kozlov 
Date:   2017-05-04T13:31:22Z

Refactoring.

commit 318748ab26819eab16be9a971b26386ed0244d4c
Author: Max Kozlov 
Date:   2017-05-15T09:24:46Z

Delete unused code.

commit 805490ef138bc351ac357cc80de5329115a4a5a7
Author: Max Kozlov 
Date:   2017-05-22T14:30:45Z

Remove java classes. Refactor imports.

commit ec7917681480d3b5476a141a30e86b7c89609e4f
Author: Max Kozlov 
Date:   2017-05-23T15:36:41Z

Refactoring code.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Upgrade dependency to outdated Lucene 3.5.0

[李玉珏]

Lucene6 requires JDK8 and later versions, and I think it might be 
reasonable to update to the Lucene5.5.4 version.



在 2017/5/23 22:07, Andrey Mashenkov 写道:

Hi Igniters,

Ignite-indexing module has outdated dependency to apache-lucene-3.5.0,
however, actual version of lucene for now is 6.5.1. Here is a ticket [1].

Store format version of 3.x is deprecated in 4.x and does not supported at
all
in higher versions, that cause difficulties to integrate with ignite on
user side.

Apache Lucene 6.x seems doen't support <=4.x index format,
but 5.x index format can be used via additional jar with old codecs.

Also, I've found GridLuceneIndex stores index in offheap via old approach
and
page memory is not supported, so it can't be persisted (looking forward to
PDS).

Seems, we will not break any compatibility if we upgrade lucene version in
2.1,
until (or together with) Ignite full-text-search component supports page
memory and PDS merged to ignite.
I think we should upgrade to latest 6.x version, as it will much harder to
do it later.


Is there any cons\pros to upgrade lucene dependency up to latest 6.x
version?


[1] https://issues.apache.org/jira/browse/IGNITE-3562

Upgrade dependency to outdated Lucene 3.5.0

[Andrey Mashenkov]

Hi Igniters,

Ignite-indexing module has outdated dependency to apache-lucene-3.5.0,
however, actual version of lucene for now is 6.5.1. Here is a ticket [1].

Store format version of 3.x is deprecated in 4.x and does not supported at
all
in higher versions, that cause difficulties to integrate with ignite on
user side.

Apache Lucene 6.x seems doen't support <=4.x index format,
but 5.x index format can be used via additional jar with old codecs.

Also, I've found GridLuceneIndex stores index in offheap via old approach
and
page memory is not supported, so it can't be persisted (looking forward to
PDS).

Seems, we will not break any compatibility if we upgrade lucene version in
2.1,
until (or together with) Ignite full-text-search component supports page
memory and PDS merged to ignite.
I think we should upgrade to latest 6.x version, as it will much harder to
do it later.


Is there any cons\pros to upgrade lucene dependency up to latest 6.x
version?


[1] https://issues.apache.org/jira/browse/IGNITE-3562

-- 
Best regards,
Andrey V. Mashenkov

[GitHub] ignite pull request #1997: IGNITE-4994 Restored GridH2TableSelfTest

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-4994 Restored GridH2TableSelfTest



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

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

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

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


commit d64c115f5e1a944a360e899f35a4073a44959695
Author: Alexander Paschenko 
Date:   2017-05-22T12:07:33Z

IGNITE-4994 Restored GridH2TableSelfTest




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1996: Ignite-5242

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

Ignite-5242

DROP TABLE enabled only for caches created via SQL

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

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

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

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


commit aa48bab0848e776754638bce07097b16006cd548
Author: Alexander Paschenko 
Date:   2017-04-21T16:05:06Z

IGNITE-5052 CREATE TABLE first steps

commit 7f04ca5811e4680f75996b30a73c7987eec19a25
Author: Alexander Paschenko 
Date:   2017-04-24T17:20:22Z

IGNITE-5052 CREATE TABLE parsing contd

commit 9ba38c926420b4f6d822885cb595c69de8a518c1
Author: Alexander Paschenko 
Date:   2017-04-25T14:38:57Z

Merge remote-tracking branch 'apache/ignite-2.0' into ignite-5052

commit d6cdb6ab208e24c65e2bc5d6ea8c88344b3725d6
Author: Alexander Paschenko 
Date:   2017-04-25T15:11:37Z

IGNITE-5052 CREATE TABLE parsing contd

commit 0be9b0877031bafda674949b13db6b3492bd8fe8
Author: Alexander Paschenko 
Date:   2017-04-26T08:14:29Z

IGNITE-5052 Dynamic local CREATE TABLE

commit 6569d53e91ef698c7955939cbf3681ebaf68a6c2
Author: Alexander Paschenko 
Date:   2017-04-26T18:55:23Z

IGNITE-5052 CREATE/DROP TABLE + few tests

commit a7e409b5cea3513e9dcdc242fbde057a99ad84a4
Author: Alexander Paschenko 
Date:   2017-04-27T18:01:17Z

IGNITE-5052 GridSqlCreateTable.toSql

commit 7d3325e1809fe33cb183ef8de3559ee0b2e40048
Author: Alexander Paschenko 
Date:   2017-04-28T11:46:42Z

Merge remote-tracking branch 'apache/ignite-2.0' into ignite-5052

commit b740701d61f7728c78b117bb5edbc60f0cba46e9
Author: Alexander Paschenko 
Date:   2017-04-28T11:51:51Z

Post merge fix

commit e650908cbf3358de731c7da606b22606834dfa85
Author: devozerov 
Date:   2017-05-05T11:02:43Z

Merge branch 'master' into ignite-5052

commit afda2220361158434e0b2f86f6d8f21c0342babf
Author: Alexander Paschenko 
Date:   2017-05-10T10:54:50Z

Merge branch 'master' into ignite-5052

commit dc5f68b9224adcaf1bdde2a6e2606d33a5549993
Author: Alexander Paschenko 
Date:   2017-05-10T19:03:01Z

IGNITE-5052 Review fixes

commit 888eb168685f6e63541ef7c3b096e32cae54fd4d
Author: Alexander Paschenko 
Date:   2017-05-11T11:31:15Z

IGNITE-5052 Review fixes - contd

commit 9a26a678f554c550739d06fef6ab371afb4c46f6
Author: Alexander Paschenko 
Date:   2017-05-11T11:32:51Z

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

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryIndexing.java

commit 7f377c4de364907e27d143f1ae8263dcd3125db0
Author: devozerov 
Date:   2017-05-16T08:07:22Z

Merge branch 'master' into ignite-5052

commit 41e2f64cad6dfe33c28266281229b86b413e86a2
Author: devozerov 
Date:   2017-05-16T08:56:40Z

Minors.

commit 588093fd8db6ef8aae8b6e53f289a100dbe26853
Author: Alexander Paschenko 
Date:   2017-05-16T16:16:44Z

IGNITE-5052 Review fixes.

commit e2bb7bd2ee1f4d8419f8f918d69b50f68d0c0efc
Author: Alexander Paschenko 
Date:   2017-05-16T16:16:53Z

Merge branch 'master' into ignite-5052

commit e88a287b9a6b1f1372972b5d8223d3405152fcca
Author: Alexander Paschenko 
Date:   2017-05-17T09:04:36Z

Merge branch 'master' into ignite-5052

commit eef106ff955cd24884d60536bcc97797ec613b6c
Author: Alexander Paschenko 
Date:   2017-05-17T16:09:55Z

IGNITE-5052 Review fixes.

commit f9fa7e7ee52ac9ea3510be10d865d1ecb77c3365
Author: Alexander Paschenko 
Date:   2017-05-18T10:12:20Z

Merge branch 'master' into ignite-5052

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CacheAffinitySharedManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/DynamicCacheDescriptor.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheProcessor.java
#   

[jira] [Created] (IGNITE-5283) Transaction recovery works incorrectly with cache store and writeThrough enabled

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-5283:
---

 Summary: Transaction recovery works incorrectly with cache store 
and writeThrough enabled
 Key: IGNITE-5283
 URL: https://issues.apache.org/jira/browse/IGNITE-5283
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Andrey Gura


Transaction (at least optimistic) recovery on backups works incorrectly when 
cache store and writeThrough enabled. Changes aren't propagated to DB (it's 
correct) but propagated to cache if primary node left topology.

It happens because {{IgniteTxRemoteStateAdapter.storeUsed()}} method always 
returns {{false}}. As result incorrect code branch executes in 
{{NodeFailureTimeoutObject.onTimeout0()}} method ({{salvageTx()}} method should 
be invoked).

*Steps to reproduce*:
- Start two nodes A and B with cache. Cache store and writeThrough are anbled.
- From node A start optimistic transaction which executes put/update operation 
for key. Node A should be primary for this key.
- Kill node A when {{CacheStore.sessionEnd()}} method is invoked but changes 
are not propagated to underlying database (before commit on connection).
- DB doesn't contain changes but node B contains it.

*Expected behaviour:*

All changes should be rolled back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1995: GG-12184: gridgain-pds classes are absent in grid...

[glukos]

GitHub user glukos opened a pull request:

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

GG-12184: gridgain-pds classes are absent in gridgain.classnames.prop…

Tests run for backporting GG-12184 into ignite-5267. Please, don'r merge.

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

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

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

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


commit 1c8ac5ec915867a47f3266e0ca36903f86efdee3
Author: Ivan Rakov 
Date:   2017-05-23T13:23:31Z

GG-12184: gridgain-pds classes are absent in gridgain.classnames.properties




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1912: IGNITE-5163 JDBC Driver: implement handshake for ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1993: IGNITE-5282

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5282



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

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

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

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


commit 99d2299d0964c163396c9335b9de098f5c533b8a
Author: devozerov 
Date:   2017-05-23T11:44:56Z

WIP.

commit 56a6bf342f3b213ec2a6ffb37657605b39a5e8fc
Author: devozerov 
Date:   2017-05-23T11:47:08Z

WIP.

commit ea983d7a5fe1bbe6aa34baed2600df61f018484f
Author: devozerov 
Date:   2017-05-23T12:01:46Z

WIP.

commit f046fe04952e78a94af97a9e361012409b6b1a7c
Author: devozerov 
Date:   2017-05-23T12:02:41Z

Done.

commit 21f94a2a2460b8b2a17bfa989f94735c6661211f
Author: devozerov 
Date:   2017-05-23T12:45:44Z

Done.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-5282) Pass "keepBinary" flag to SQL processor from the outside

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5282:
---

 Summary: Pass "keepBinary" flag to SQL processor from the outside
 Key: IGNITE-5282
 URL: https://issues.apache.org/jira/browse/IGNITE-5282
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.1


Currently "keepBinary" is sometimes passed from the outside, but sometimes is 
taken from cache context. We need to always take it from the outside.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1964: IGNITE 5212 Allow custom affinity for system cach...

[vldpyatkov]

Github user vldpyatkov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1936: Fixed segmented indices snapshots.

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1982: IGNITE-5252: Expose getFieldName method to SqlFie...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1915: IGNITE-5150: Allocated memory pages count is inco...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1992: IGNITE-5281

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5281



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

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

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

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


commit 99d2299d0964c163396c9335b9de098f5c533b8a
Author: devozerov 
Date:   2017-05-23T11:44:56Z

WIP.

commit 56a6bf342f3b213ec2a6ffb37657605b39a5e8fc
Author: devozerov 
Date:   2017-05-23T11:47:08Z

WIP.

commit ea983d7a5fe1bbe6aa34baed2600df61f018484f
Author: devozerov 
Date:   2017-05-23T12:01:46Z

WIP.

commit f046fe04952e78a94af97a9e361012409b6b1a7c
Author: devozerov 
Date:   2017-05-23T12:02:41Z

Done.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: TC for master is moved to Ignite 2.0 test suite

[Dmitry Pavlov]

Hi Igniters,


Please review PR with 'Binary Basic' merge into 'Basic'
https://github.com/apache/ignite/pull/1991


After PR is merged it will be possible to remove snapshot dependency from
‘Run All’ to  ‘Binary Basic’

and remove run configuration.

Best Regards,

Dmitry Pavlov

PS. TC run

http://ci.ignite.apache.org/viewLog.html?buildId=625386=buildResultsDiv=Ignite20Tests_IgniteBinaryBasic
(Without tests)

http://ci.ignite.apache.org/viewLog.html?buildId=625387=buildResultsDiv=Ignite20Tests_IgniteBasic


вт, 23 мая 2017 г. в 13:33, Dmitry Pavlov :

> Yes, we can merge 'binary basic' into 'basic' with adding following tests
> into 'basic':
> o.a.i.internal.processors.cache.IgniteMarshallerCacheClassNameConflictTest
> -testCachePutGetClassesWithNameConflict()
>
>
> o.a.i.internal.processors.cache.IgniteMarshallerCacheClientRequestsMappingOnMissTest
> -testAllNodesDieOnRequest()
> -testNoNodesDieOnRequest()
> -testOneNodeDiesOnRequest()
> -testRequestedMappingIsStoredInFS()
> -testTwoNodesDieOnRequest()
>
> it will save 37 minutes of agent time more. I'll prepare PR
>
> Best Regards,
> Dmitry Pavlov
>
>
> вт, 23 мая 2017 г. в 10:43, Vladimir Ozerov :
>
>> Pavel,
>>
>> Yes, these two:
>>
>> http://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:Ignite20Tests_IgniteBasic
>>
>> http://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:Ignite20Tests_IgniteBinaryBasic
>>
>> They both execute org.apache.ignite.testsuites.IgniteBasicTestSuite. Looks
>> like we should merge them accurately.
>>
>> On Tue, May 23, 2017 at 10:27 AM, Dmitry Pavlov 
>> wrote:
>>
>> > Hi, Vladimir,
>> >
>> > There is a chance that in
>> > http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=
>> > projectOverview
>> > some
>> > configs are for binary + simple oblect names (no package name) tests.
>> >
>> > But if there is some suspicious link that is candidate to removal,
>> please
>> > feel free to contact me.
>> >
>> > Best Regards,
>> > Dmitry Pavlov
>> >
>> > вт, 23 мая 2017 г. в 10:24, Vladimir Ozerov :
>> >
>> > > Fantastic news, thank you guys! Though, I still see "Basic" and
>> "Binary
>> > > Object Basic" suites. Should we drop one of them as well?
>> > >
>> > > On Tue, May 23, 2017 at 10:20 AM, Alexey Goncharuk <
>> > > alexey.goncha...@gmail.com> wrote:
>> > >
>> > > > Igniters,
>> > > >
>> > > > Since we removed OptimizedMarshaller in Ignite 2.0 from the
>> PublicAPI,
>> > we
>> > > > had a chance to remove several unnecessary test suites from the
>> build
>> > > plan
>> > > > from Ignite 2.0. I pushed the changes for IGNITE-4947 ticket. From
>> this
>> > > > moment you should run tests from Ignite 2.0 project, which is 14
>> test
>> > > > suites shorter than the previous plan.
>> > > >
>> > > > Kudos to Alexander Paschenko and Dmitriy Pavlov!
>> > > >
>> > > > --AG
>> > > >
>> > >
>> >
>>
>

[jira] [Created] (IGNITE-5281) Change "space" notion to "cacheName"

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5281:
---

 Summary: Change "space" notion to "cacheName"
 Key: IGNITE-5281
 URL: https://issues.apache.org/jira/browse/IGNITE-5281
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.1


Space is always equal to cache name. Let's rename all internals from "space" to 
"cacheName". No need for confusion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1991: Ignite-4947: Ignite Basic and Ignite Binary Basic...

[dspavlov]

GitHub user dspavlov opened a pull request:

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

Ignite-4947: Ignite Basic and Ignite Binary Basic suites were merged,…

… Binary Basic is now empty

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

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

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

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


commit 7b5d0283e2731291fcaed3726997e7bdd5d8789b
Author: dpavlov 
Date:   2017-05-23T11:38:29Z

Ignite-4947: Ignite Basic and Ignite Binary Basic suites were merged, 
Binary Basic is now empty




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1938: IGNITE-5215: Allow user to configure memory polic...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Geo spatial index

[Sergi Vladykin]

Guys,

Looks like we have to move our geospatial indexes to the new approach with
BPlusTree. Right now it stores data in Java heap. This is especially
important because we are going to have a persistence layer donated by
GridGain and obviously geo spatial indexes will not work with it at all.

Sergi

[GitHub] ignite pull request #1990: IGNITE-5264

[devozerov]

Github user devozerov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: SqlFields query result does not expose fields metadata.

[Sergi Vladykin]

Done.

Sergi

2017-05-23 13:48 GMT+03:00 Andrey Mashenkov :

> IGNITE-5252 [1] is ready for review.
> Sergi, would you please take a look at it?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-5252
>
> On Sat, May 20, 2017 at 7:07 PM, Andrey Mashenkov <
> andrey.mashen...@gmail.com> wrote:
>
> > Dmitry,
> >
> > Here is a link ot ticket [1]
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-5252
> >
> > On Sat, May 20, 2017 at 1:00 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> >> I cannot find a ticket for it. Has it been filed?
> >>
> >> On Fri, May 19, 2017 at 12:38 AM, Vladimir Ozerov  >
> >> wrote:
> >>
> >> > Ah, got it. Then I am ok with the change as well.
> >> >
> >> > On Fri, May 19, 2017 at 9:24 AM, Sergi Vladykin <
> >> sergi.vlady...@gmail.com>
> >> > wrote:
> >> >
> >> > > Nope, the proposal was to have a FieldsQueryCursor interface with
> >> > > getFieldName(int column) method, may be + some other methods we will
> >> add
> >> > > later. This does not require any complex code modifications or
> >> exposing
> >> > > internal APIs.
> >> > >
> >> > > I'm not against new SQL API, it is a good idea, but it should not
> >> prevent
> >> > > us from making easy fixes in existing API when we need it.
> >> > >
> >> > > Sergi
> >> > >
> >> > > 2017-05-18 23:20 GMT+03:00 Vladimir Ozerov :
> >> > >
> >> > > > Proposal is about returning GridQueryFieldMetadata from
> QueryCursor,
> >> > > which
> >> > > > is internal interface. This interface is counterintuitive and is
> not
> >> > > ready
> >> > > > to be exposed to users. For example, it has method "typeName"
> which
> >> > > > actually returns table name. And has method "fieldTypeName" which
> >> > returns
> >> > > > something like "java.lang.Object". Add "type name" concept from
> our
> >> > > > BinaryConfiguration/QueryEntity, which have different semantics,
> >> and
> >> > you
> >> > > > end up with totally confused users on what "type name" means in
> >> Ignite.
> >> > > >
> >> > > > Let's do not expose strange things to users, and accurately create
> >> new
> >> > > > clean SQL API instead. There is no strong demand for this feature.
> >> > > >
> >> > > > On Thu, May 18, 2017 at 7:39 PM, Sergi Vladykin <
> >> > > sergi.vlady...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > It should not require any internals movement, it must be an easy
> >> fix.
> >> > > > >
> >> > > > > Sergi
> >> > > > >
> >> > > > > 2017-05-18 15:36 GMT+03:00 Vladimir Ozerov <
> voze...@gridgain.com
> >> >:
> >> > > > >
> >> > > > > > With all the changes to internals we made, new API can be
> >> created
> >> > > very
> >> > > > > > quickly somewhere around AI 2.2 or AI 2.3. Currently the whole
> >> API
> >> > is
> >> > > > > > located in the wrong place, as it is bounded to cache. So the
> >> more
> >> > we
> >> > > > add
> >> > > > > > now, the more we will deprecate in several months. Remember,
> >> that
> >> > > this
> >> > > > > > feature will require not only new interface, but moving
> existing
> >> > > > > *internal*
> >> > > > > > metadata classes to public space. These classes were never
> >> designed
> >> > > to
> >> > > > be
> >> > > > > > exposed to users in the first place.
> >> > > > > >
> >> > > > > > This is why I am strongly against this change at the moment.
> No
> >> > need
> >> > > to
> >> > > > > > make already outdated and complex API even more complex
> without
> >> > > strong
> >> > > > > > demand from users.
> >> > > > > >
> >> > > > > > On Thu, May 18, 2017 at 3:29 PM, Pavel Tupitsyn <
> >> > > ptupit...@apache.org>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > I agree that this change makes sense.
> >> > > > > > > With complex queries it may be non-trivial to get the right
> >> > column
> >> > > by
> >> > > > > > index
> >> > > > > > > from results.
> >> > > > > > > With metadata user no longer needs to care about result
> column
> >> > > order,
> >> > > > > and
> >> > > > > > > refactorings are easier.
> >> > > > > > >
> >> > > > > > > Pavel
> >> > > > > > >
> >> > > > > > > On Thu, May 18, 2017 at 2:36 PM, Sergi Vladykin <
> >> > > > > > sergi.vlady...@gmail.com>
> >> > > > > > > wrote:
> >> > > > > > >
> >> > > > > > > > I believe we will not see this new SQL API soon. It is not
> >> even
> >> > > in
> >> > > > > > design
> >> > > > > > > > stage.
> >> > > > > > > >
> >> > > > > > > > The change proposed by Andrey is very simple and our users
> >> will
> >> > > > > benefit
> >> > > > > > > > from it right away.
> >> > > > > > > >
> >> > > > > > > > I see no reasons to disallow this change.
> >> > > > > > > >
> >> > > > > > > > Sergi
> >> > > > > > > >
> >> > > > > > > > 2017-05-18 12:35 GMT+03:00 Vladimir Ozerov <
> >> > voze...@gridgain.com
> >> > > >:
> >> > > > > > > >
> >> > > > > > > > > Result set metadata is exposed to JDBC and ODBC drivers
> >> > because
> >> > > > it
> >> > > > > is
> >> > > > > > > > > required by JDBC 

Re: SqlFields query result does not expose fields metadata.

[Andrey Mashenkov]

IGNITE-5252 [1] is ready for review.
Sergi, would you please take a look at it?

[1] https://issues.apache.org/jira/browse/IGNITE-5252

On Sat, May 20, 2017 at 7:07 PM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:

> Dmitry,
>
> Here is a link ot ticket [1]
>
> [1] https://issues.apache.org/jira/browse/IGNITE-5252
>
> On Sat, May 20, 2017 at 1:00 AM, Dmitriy Setrakyan 
> wrote:
>
>> I cannot find a ticket for it. Has it been filed?
>>
>> On Fri, May 19, 2017 at 12:38 AM, Vladimir Ozerov 
>> wrote:
>>
>> > Ah, got it. Then I am ok with the change as well.
>> >
>> > On Fri, May 19, 2017 at 9:24 AM, Sergi Vladykin <
>> sergi.vlady...@gmail.com>
>> > wrote:
>> >
>> > > Nope, the proposal was to have a FieldsQueryCursor interface with
>> > > getFieldName(int column) method, may be + some other methods we will
>> add
>> > > later. This does not require any complex code modifications or
>> exposing
>> > > internal APIs.
>> > >
>> > > I'm not against new SQL API, it is a good idea, but it should not
>> prevent
>> > > us from making easy fixes in existing API when we need it.
>> > >
>> > > Sergi
>> > >
>> > > 2017-05-18 23:20 GMT+03:00 Vladimir Ozerov :
>> > >
>> > > > Proposal is about returning GridQueryFieldMetadata from QueryCursor,
>> > > which
>> > > > is internal interface. This interface is counterintuitive and is not
>> > > ready
>> > > > to be exposed to users. For example, it has method "typeName" which
>> > > > actually returns table name. And has method "fieldTypeName" which
>> > returns
>> > > > something like "java.lang.Object". Add "type name" concept from our
>> > > > BinaryConfiguration/QueryEntity, which have different semantics,
>> and
>> > you
>> > > > end up with totally confused users on what "type name" means in
>> Ignite.
>> > > >
>> > > > Let's do not expose strange things to users, and accurately create
>> new
>> > > > clean SQL API instead. There is no strong demand for this feature.
>> > > >
>> > > > On Thu, May 18, 2017 at 7:39 PM, Sergi Vladykin <
>> > > sergi.vlady...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > It should not require any internals movement, it must be an easy
>> fix.
>> > > > >
>> > > > > Sergi
>> > > > >
>> > > > > 2017-05-18 15:36 GMT+03:00 Vladimir Ozerov > >:
>> > > > >
>> > > > > > With all the changes to internals we made, new API can be
>> created
>> > > very
>> > > > > > quickly somewhere around AI 2.2 or AI 2.3. Currently the whole
>> API
>> > is
>> > > > > > located in the wrong place, as it is bounded to cache. So the
>> more
>> > we
>> > > > add
>> > > > > > now, the more we will deprecate in several months. Remember,
>> that
>> > > this
>> > > > > > feature will require not only new interface, but moving existing
>> > > > > *internal*
>> > > > > > metadata classes to public space. These classes were never
>> designed
>> > > to
>> > > > be
>> > > > > > exposed to users in the first place.
>> > > > > >
>> > > > > > This is why I am strongly against this change at the moment. No
>> > need
>> > > to
>> > > > > > make already outdated and complex API even more complex without
>> > > strong
>> > > > > > demand from users.
>> > > > > >
>> > > > > > On Thu, May 18, 2017 at 3:29 PM, Pavel Tupitsyn <
>> > > ptupit...@apache.org>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > I agree that this change makes sense.
>> > > > > > > With complex queries it may be non-trivial to get the right
>> > column
>> > > by
>> > > > > > index
>> > > > > > > from results.
>> > > > > > > With metadata user no longer needs to care about result column
>> > > order,
>> > > > > and
>> > > > > > > refactorings are easier.
>> > > > > > >
>> > > > > > > Pavel
>> > > > > > >
>> > > > > > > On Thu, May 18, 2017 at 2:36 PM, Sergi Vladykin <
>> > > > > > sergi.vlady...@gmail.com>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > I believe we will not see this new SQL API soon. It is not
>> even
>> > > in
>> > > > > > design
>> > > > > > > > stage.
>> > > > > > > >
>> > > > > > > > The change proposed by Andrey is very simple and our users
>> will
>> > > > > benefit
>> > > > > > > > from it right away.
>> > > > > > > >
>> > > > > > > > I see no reasons to disallow this change.
>> > > > > > > >
>> > > > > > > > Sergi
>> > > > > > > >
>> > > > > > > > 2017-05-18 12:35 GMT+03:00 Vladimir Ozerov <
>> > voze...@gridgain.com
>> > > >:
>> > > > > > > >
>> > > > > > > > > Result set metadata is exposed to JDBC and ODBC drivers
>> > because
>> > > > it
>> > > > > is
>> > > > > > > > > required by JDBC specification and lot's external
>> > applications
>> > > > use
>> > > > > > it.
>> > > > > > > I
>> > > > > > > > do
>> > > > > > > > > not see big demand for this feature in native SQL, where
>> user
>> > > > > > normally
>> > > > > > > > > knows the model. Another point is that with changes
>> > introduced
>> > > in
>> > > > > > > recent
>> > > > > > > > > versions (DML, DDL, shared schemas), we 

Re: TC for master is moved to Ignite 2.0 test suite

[Dmitry Pavlov]

Yes, we can merge 'binary basic' into 'basic' with adding following tests
into 'basic':
o.a.i.internal.processors.cache.IgniteMarshallerCacheClassNameConflictTest
-testCachePutGetClassesWithNameConflict()

o.a.i.internal.processors.cache.IgniteMarshallerCacheClientRequestsMappingOnMissTest
-testAllNodesDieOnRequest()
-testNoNodesDieOnRequest()
-testOneNodeDiesOnRequest()
-testRequestedMappingIsStoredInFS()
-testTwoNodesDieOnRequest()

it will save 37 minutes of agent time more. I'll prepare PR

Best Regards,
Dmitry Pavlov


вт, 23 мая 2017 г. в 10:43, Vladimir Ozerov :

> Pavel,
>
> Yes, these two:
>
> http://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:Ignite20Tests_IgniteBasic
>
> http://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:Ignite20Tests_IgniteBinaryBasic
>
> They both execute org.apache.ignite.testsuites.IgniteBasicTestSuite. Looks
> like we should merge them accurately.
>
> On Tue, May 23, 2017 at 10:27 AM, Dmitry Pavlov 
> wrote:
>
> > Hi, Vladimir,
> >
> > There is a chance that in
> > http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=
> > projectOverview
> > some
> > configs are for binary + simple oblect names (no package name) tests.
> >
> > But if there is some suspicious link that is candidate to removal, please
> > feel free to contact me.
> >
> > Best Regards,
> > Dmitry Pavlov
> >
> > вт, 23 мая 2017 г. в 10:24, Vladimir Ozerov :
> >
> > > Fantastic news, thank you guys! Though, I still see "Basic" and "Binary
> > > Object Basic" suites. Should we drop one of them as well?
> > >
> > > On Tue, May 23, 2017 at 10:20 AM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > > > Igniters,
> > > >
> > > > Since we removed OptimizedMarshaller in Ignite 2.0 from the
> PublicAPI,
> > we
> > > > had a chance to remove several unnecessary test suites from the build
> > > plan
> > > > from Ignite 2.0. I pushed the changes for IGNITE-4947 ticket. From
> this
> > > > moment you should run tests from Ignite 2.0 project, which is 14 test
> > > > suites shorter than the previous plan.
> > > >
> > > > Kudos to Alexander Paschenko and Dmitriy Pavlov!
> > > >
> > > > --AG
> > > >
> > >
> >
>

Re: [VOTE] Accept Contribution of Ignite Persistent Store

[Raúl Kripalani]

I'm not sure what the vote is for, if the code has already been merged to
the ASF repo — even if on a branch.

I do accept the donation but I think the code should have remained outside
the official codebase until the VOTE passed.

Not sure what the rest think.

On 22 May 2017 22:55, "Denis Magda"  wrote:

> Igniters,
>
> This branch (https://github.com/apache/ignite/tree/ignite-5267) adds a
> distributed and transactional Persistent Store to Apache Ignite project.
> The store seamlessly integrates with Apache Ignite 2.0 page memory
> architecture. One of the main advantages of the store is that Apache Ignite
> becomes fully operational from disk (SSD or Flash) without any need to
> preload the data in memory. Plus, with full SQL support already available
> in Apache Ignite, this feature will allow Apache Ignite serve as a
> distributed SQL database, both in memory or on disk, while continuing to
> support all the existing functionality on the current API.
> More information here:
> - Persistent Store Overview: https://cwiki.apache.org/
> confluence/display/IGNITE/Persistent+Store+Overview
> - Persistent Store Internal Design: https://cwiki.apache.org/
> confluence/display/IGNITE/Persistent+Store+Internal+Design
> The Persistent Store was developed by GridGain outside of Apache community
> because it was requested by one of GridGain’s customers. Presently,
> GridGain looks forward to donating the Persistent Store to ASF and given
> the size of the contribution, it is prudent to follow Apache's IP clearance
> process.
> The SGA has been submitted and acknowledged by ASF Secretary. The IP
> clearance form can be found here: http://incubator.apache.org/
> ip-clearance/persistent-distributed-store-ignite.html
> This vote is to discover if the Apache Ignite PMC and community are in
> favour of accepting this contribution.
> This vote will be open for at least 72 hours:
> [ ] +1, accept contribution of the Persistent Store into the project
> [ ] 0, no opinion
> [ ] -1, reject contribution because...
>
> Regards,
> Denis
>
>

[jira] [Created] (IGNITE-5280) SparseDistributedMatrix refactorig

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5280:
--

 Summary: SparseDistributedMatrix refactorig
 Key: IGNITE-5280
 URL: https://issues.apache.org/jira/browse/IGNITE-5280
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yury Babak
Assignee: Yury Babak


We must refactor SparseDistributedMatrix for decrease communication during 
computations.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5279) DDL: Improve test coverage for objects with different cases (upper/lower)

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5279:
---

 Summary: DDL: Improve test coverage for objects with different 
cases (upper/lower)
 Key: IGNITE-5279
 URL: https://issues.apache.org/jira/browse/IGNITE-5279
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1983: Ignite 4447 2

[vadopolski]

GitHub user vadopolski reopened a pull request:

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

Ignite 4447 2

Removed IgniteCache150ClientsTest.java to IgniteCacheTestSuite.java.

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

$ git pull https://github.com/vadopolski/ignite ignite-4447-2

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

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


commit 6e5f83233b5501bdb6a3bb03eb53f3be8871f786
Author: vopolski <2w3e4r5t>
Date:   2017-04-20T15:07:48Z

updating

commit 90b44e7ec27cc953749d48a00bcbfdfc91763456
Author: vopolski <2w3e4r5t>
Date:   2017-05-22T11:57:42Z

IGNITE-4447
Removed IgniteCache150ClientsTest.java to IgniteCacheTestSuite.java.

commit 6ac4769f6cae2bffb87e19f983be90e9d014d924
Author: vopolski <2w3e4r5t>
Date:   2017-05-22T12:04:24Z

IGNITE-4447
Removed IgniteCache150ClientsTest.java to IgniteCacheTestSuite.java.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1983: Ignite 4447 2

[vadopolski]

Github user vadopolski closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Inefficient approach to executing remote SQL queries

[Sergi Vladykin]

Michael,

I see your point. I think it must not be too hard to start asynchronously
establishing connections to all the needed nodes.

I've created respective issue in Jira:
https://issues.apache.org/jira/browse/IGNITE-5277

Sergi

2017-05-23 11:56 GMT+03:00 Michael Griggs :

> Hi Val
>
> This is precisely my point: it's only a minor optimization until the point
> when establishing each connection takes 3-4 seconds, and we establish 32 of
> them in sequence.  At that point it becomes a serious issue: the customer
> cannot run SQL queries from their development machines without them timing
> out once out of every two or three runs.  These kind of problems undermine
> confidence in Ignite.
>
> Mike
>
>
> -Original Message-
> From: Valentin Kulichenko [mailto:valentin.kuliche...@gmail.com]
> Sent: 22 May 2017 19:15
> To: dev@ignite.apache.org
> Subject: Re: Inefficient approach to executing remote SQL queries
>
> Hi Mike,
>
> Generally, establishing connections in parallel could make sense, but note
> that in most this would be a minor optimization, because:
>
>- Under load connections are established once and then reused. If you
>observe disconnections during application lifetime under load, then
>probably this should be addressed first.
>- Actual communication is asynchronous, we use NIO for this. If
>connection already exists, sendGeneric() basically just puts a message
> into
>a queue.
>
> -Val
>
> On Mon, May 22, 2017 at 7:04 PM, Michael Griggs <
> michael.gri...@gridgain.com
> > wrote:
>
> > Hi Igniters,
> >
> >
> >
> > Whilst diagnosing a problem with a slow query, I became aware of a
> > potential issue in the Ignite codebase.  When executing a SQL query
> > that is to run remotely, the IgniteH2Indexing#send() method is called,
> > with a Collection as one of its parameters.  This
> > collection is iterated sequentially, and ctx.io().sendGeneric() is
> > called synchronously for each node.  This is inefficient if
> >
> >
> >
> > a)   This is the first execution of a query, and thus TCP connections
> > have to be established
> >
> > b)  The cost of establishing a TCP connection is high
> >
> >
> >
> > And optionally
> >
> >
> >
> > c)   There are a large number of nodes in the cluster
> >
> >
> >
> > In my current situation, developers want to run test queries from
> > their code running locally, but connected via VPN to their UAT server
> > environment.
> > The
> > cost of opening a TCP connection is in the multiple seconds, as you
> > can see from this Ignite log file snippet:
> >
> > 2017-05-22 18:29:48,908 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:56924,
> > rmtAddr=/10.132.80.3:47100]
> >
> > 2017-05-22 18:29:52,294 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:56923,
> > rmtAddr=/10.132.80.30:47102]
> >
> > 2017-05-22 18:29:58,659 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:56971,
> > rmtAddr=/10.132.80.23:47101]
> >
> > 2017-05-22 18:30:03,183 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:56972,
> > rmtAddr=/10.132.80.21:47100]
> >
> > 2017-05-22 18:30:06,039 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:56973,
> > rmtAddr=/10.132.80.21:47103]
> >
> > 2017-05-22 18:30:10,828 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:57020,
> > rmtAddr=/10.132.80.20:47100]
> >
> > 2017-05-22 18:30:13,060 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:57021,
> > rmtAddr=/10.132.80.29:47103]
> >
> > 2017-05-22 18:30:22,144 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:57022,
> > rmtAddr=/10.132.80.22:47103]
> >
> > 2017-05-22 18:30:26,513 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:57024,
> > rmtAddr=/10.132.80.20:47101]
> >
> > 2017-05-22 18:30:28,526 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/7.1.14.242:57025,
> > rmtAddr=/10.132.80.30:47103]
> >
> >
> >
> > Comparing the same code that is executed inside of the UAT environment
> > (so not using the VPN):
> >
> > 2017-05-22 18:22:18,102 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/10.175.11.38:53288,
> > rmtAddr=/10.175.11.58:47100]
> >
> > 2017-05-22 18:22:18,105 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/10.175.11.38:45890,
> > rmtAddr=/10.175.11.54:47101]
> >
> > 2017-05-22 18:22:18,108 INFO [TcpCommunicationSpi] - Established
> > outgoing communication connection [locAddr=/127.0.0.1:47582,
> > rmtAddr=/127.0.0.1:47100]
> >
> > 2017-05-22 18:22:18,111 INFO 

[jira] [Created] (IGNITE-5277) Asynchronously establish connection to all the needed nodes in IgniteH2Indexing.send()

[Sergi Vladykin (JIRA)]

Sergi Vladykin created IGNITE-5277:
--

 Summary: Asynchronously establish connection to all the needed 
nodes in IgniteH2Indexing.send()
 Key: IGNITE-5277
 URL: https://issues.apache.org/jira/browse/IGNITE-5277
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergi Vladykin


it's only a minor optimization until the point when establishing each 
connection takes 3-4 seconds, and we establish 32 of them in sequence.  At that 
point it becomes a serious issue: the customer cannot run SQL queries from 
their development machines



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5276) JDBC: Add handler byte to protocol

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5276:
---

 Summary: JDBC: Add handler byte to protocol
 Key: IGNITE-5276
 URL: https://issues.apache.org/jira/browse/IGNITE-5276
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


We need to add special byte to distinguish between handlers. This way we will 
be able to extend protocol easily in future.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5275) Create SQL listener configuration based on OdbcConfiguration

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5275:
---

 Summary: Create SQL listener configuration based on 
OdbcConfiguration
 Key: IGNITE-5275
 URL: https://issues.apache.org/jira/browse/IGNITE-5275
 Project: Ignite
  Issue Type: Task
  Components: odbc, sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


We need to introduce new configuration API which will be applicable for both 
ODBC and JDBC drivers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5274) DLL: use schema for CREATE TABLE and DROP TABLE operations in GridQueryProcessor

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5274:
---

 Summary: DLL: use schema for CREATE TABLE and DROP TABLE 
operations in GridQueryProcessor
 Key: IGNITE-5274
 URL: https://issues.apache.org/jira/browse/IGNITE-5274
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
 Fix For: 2.1






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5273) MemoryMetrics API improvements to be ported to .NET

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-5273:
---

 Summary: MemoryMetrics API improvements to be ported to .NET
 Key: IGNITE-5273
 URL: https://issues.apache.org/jira/browse/IGNITE-5273
 Project: Ignite
  Issue Type: Task
  Components: general
Reporter: Sergey Chugunov


Improvements already made for linked ticket need to be ported on .NET side.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

RE: Inefficient approach to executing remote SQL queries

[Michael Griggs]

Hi Val

This is precisely my point: it's only a minor optimization until the point when 
establishing each connection takes 3-4 seconds, and we establish 32 of them in 
sequence.  At that point it becomes a serious issue: the customer cannot run 
SQL queries from their development machines without them timing out once out of 
every two or three runs.  These kind of problems undermine confidence in 
Ignite.  

Mike


-Original Message-
From: Valentin Kulichenko [mailto:valentin.kuliche...@gmail.com] 
Sent: 22 May 2017 19:15
To: dev@ignite.apache.org
Subject: Re: Inefficient approach to executing remote SQL queries

Hi Mike,

Generally, establishing connections in parallel could make sense, but note that 
in most this would be a minor optimization, because:

   - Under load connections are established once and then reused. If you
   observe disconnections during application lifetime under load, then
   probably this should be addressed first.
   - Actual communication is asynchronous, we use NIO for this. If
   connection already exists, sendGeneric() basically just puts a message into
   a queue.

-Val

On Mon, May 22, 2017 at 7:04 PM, Michael Griggs  wrote:

> Hi Igniters,
>
>
>
> Whilst diagnosing a problem with a slow query, I became aware of a 
> potential issue in the Ignite codebase.  When executing a SQL query 
> that is to run remotely, the IgniteH2Indexing#send() method is called, 
> with a Collection as one of its parameters.  This 
> collection is iterated sequentially, and ctx.io().sendGeneric() is 
> called synchronously for each node.  This is inefficient if
>
>
>
> a)   This is the first execution of a query, and thus TCP connections
> have to be established
>
> b)  The cost of establishing a TCP connection is high
>
>
>
> And optionally
>
>
>
> c)   There are a large number of nodes in the cluster
>
>
>
> In my current situation, developers want to run test queries from 
> their code running locally, but connected via VPN to their UAT server 
> environment.
> The
> cost of opening a TCP connection is in the multiple seconds, as you 
> can see from this Ignite log file snippet:
>
> 2017-05-22 18:29:48,908 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:56924, 
> rmtAddr=/10.132.80.3:47100]
>
> 2017-05-22 18:29:52,294 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:56923, 
> rmtAddr=/10.132.80.30:47102]
>
> 2017-05-22 18:29:58,659 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:56971, 
> rmtAddr=/10.132.80.23:47101]
>
> 2017-05-22 18:30:03,183 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:56972, 
> rmtAddr=/10.132.80.21:47100]
>
> 2017-05-22 18:30:06,039 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:56973, 
> rmtAddr=/10.132.80.21:47103]
>
> 2017-05-22 18:30:10,828 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:57020, 
> rmtAddr=/10.132.80.20:47100]
>
> 2017-05-22 18:30:13,060 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:57021, 
> rmtAddr=/10.132.80.29:47103]
>
> 2017-05-22 18:30:22,144 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:57022, 
> rmtAddr=/10.132.80.22:47103]
>
> 2017-05-22 18:30:26,513 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:57024, 
> rmtAddr=/10.132.80.20:47101]
>
> 2017-05-22 18:30:28,526 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/7.1.14.242:57025, 
> rmtAddr=/10.132.80.30:47103]
>
>
>
> Comparing the same code that is executed inside of the UAT environment 
> (so not using the VPN):
>
> 2017-05-22 18:22:18,102 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/10.175.11.38:53288, 
> rmtAddr=/10.175.11.58:47100]
>
> 2017-05-22 18:22:18,105 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/10.175.11.38:45890, 
> rmtAddr=/10.175.11.54:47101]
>
> 2017-05-22 18:22:18,108 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/127.0.0.1:47582, 
> rmtAddr=/127.0.0.1:47100]
>
> 2017-05-22 18:22:18,111 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/127.0.0.1:45240, 
> rmtAddr=/127.0.0.1:47103]
>
> 2017-05-22 18:22:18,114 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/10.175.11.38:46280, 
> rmtAddr=/10.175.11.15:47100]
>
> 2017-05-22 18:22:18,118 INFO [TcpCommunicationSpi] - Established 
> outgoing communication connection [locAddr=/10.132.80.21:51476, 
> rmtAddr=/10.132.80.29:47103]
>
> 2017-05-22 18:22:18,120 INFO [TcpCommunicationSpi] - 

IGNITE-5124 is ready for review

[Sergey Chugunov]

Hello Igniters,

I implemented UX improvements for MemoryMetrics and added/clarified some
documentation to public API.

Please find changes under pull request here
, for discussions feel free to
leave comments in upsource review
.

Thanks,
Sergey.

[GitHub] ignite pull request #1976: IGNITE-5248: Detect a 32-bit JVM using too large ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1990: IGNITE-5264

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5264



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

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

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

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


commit e04c785c3ef7426a8aa11658655dfc43511a9836
Author: devozerov 
Date:   2017-05-22T14:26:43Z

Preparing.

commit 03daf6dc305a010b4451d61e7f01a717c67fe8c5
Author: devozerov 
Date:   2017-05-23T07:29:57Z

Removed schema key.

commit a640720c6db52c4d2ea7ddf1523a97cab267fef4
Author: devozerov 
Date:   2017-05-23T08:00:08Z

Finalization.

commit 217ba052f5578b2612bd9525a1095a0bb9b06c43
Author: devozerov 
Date:   2017-05-23T08:30:30Z

WOrks fine.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] Accept Contribution of Ignite Persistent Store

[Alexey Kuznetsov]

+1

On Tue, May 23, 2017 at 3:23 PM, Sergi Vladykin 
wrote:

> +1
>
> Sergi
>
> 2017-05-23 10:20 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > +1
> >
> > On Tue, May 23, 2017 at 8:42 AM, Semyon Boikov 
> > wrote:
> >
> > > +1
> > >
> > > On Tue, May 23, 2017 at 12:55 AM, Denis Magda 
> wrote:
> > >
> > > > Igniters,
> > > >
> > > > This branch (https://github.com/apache/ignite/tree/ignite-5267)
> adds a
> > > > distributed and transactional Persistent Store to Apache Ignite
> > project.
> > > > The store seamlessly integrates with Apache Ignite 2.0 page memory
> > > > architecture. One of the main advantages of the store is that Apache
> > > Ignite
> > > > becomes fully operational from disk (SSD or Flash) without any need
> to
> > > > preload the data in memory. Plus, with full SQL support already
> > available
> > > > in Apache Ignite, this feature will allow Apache Ignite serve as a
> > > > distributed SQL database, both in memory or on disk, while continuing
> > to
> > > > support all the existing functionality on the current API.
> > > > More information here:
> > > > - Persistent Store Overview: https://cwiki.apache.org/
> > > > confluence/display/IGNITE/Persistent+Store+Overview
> > > > - Persistent Store Internal Design: https://cwiki.apache.org/
> > > > confluence/display/IGNITE/Persistent+Store+Internal+Design
> > > > The Persistent Store was developed by GridGain outside of Apache
> > > community
> > > > because it was requested by one of GridGain’s customers. Presently,
> > > > GridGain looks forward to donating the Persistent Store to ASF and
> > given
> > > > the size of the contribution, it is prudent to follow Apache's IP
> > > clearance
> > > > process.
> > > > The SGA has been submitted and acknowledged by ASF Secretary. The IP
> > > > clearance form can be found here: http://incubator.apache.org/
> > > > ip-clearance/persistent-distributed-store-ignite.html
> > > > This vote is to discover if the Apache Ignite PMC and community are
> in
> > > > favour of accepting this contribution.
> > > > This vote will be open for at least 72 hours:
> > > > [ ] +1, accept contribution of the Persistent Store into the project
> > > > [ ] 0, no opinion
> > > > [ ] -1, reject contribution because...
> > > >
> > > > Regards,
> > > > Denis
> > > >
> > > >
> > >
> >
>



-- 
Alexey Kuznetsov

Re: [VOTE] Accept Contribution of Ignite Persistent Store

[Sergi Vladykin]

+1

Sergi

2017-05-23 10:20 GMT+03:00 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> +1
>
> On Tue, May 23, 2017 at 8:42 AM, Semyon Boikov 
> wrote:
>
> > +1
> >
> > On Tue, May 23, 2017 at 12:55 AM, Denis Magda  wrote:
> >
> > > Igniters,
> > >
> > > This branch (https://github.com/apache/ignite/tree/ignite-5267) adds a
> > > distributed and transactional Persistent Store to Apache Ignite
> project.
> > > The store seamlessly integrates with Apache Ignite 2.0 page memory
> > > architecture. One of the main advantages of the store is that Apache
> > Ignite
> > > becomes fully operational from disk (SSD or Flash) without any need to
> > > preload the data in memory. Plus, with full SQL support already
> available
> > > in Apache Ignite, this feature will allow Apache Ignite serve as a
> > > distributed SQL database, both in memory or on disk, while continuing
> to
> > > support all the existing functionality on the current API.
> > > More information here:
> > > - Persistent Store Overview: https://cwiki.apache.org/
> > > confluence/display/IGNITE/Persistent+Store+Overview
> > > - Persistent Store Internal Design: https://cwiki.apache.org/
> > > confluence/display/IGNITE/Persistent+Store+Internal+Design
> > > The Persistent Store was developed by GridGain outside of Apache
> > community
> > > because it was requested by one of GridGain’s customers. Presently,
> > > GridGain looks forward to donating the Persistent Store to ASF and
> given
> > > the size of the contribution, it is prudent to follow Apache's IP
> > clearance
> > > process.
> > > The SGA has been submitted and acknowledged by ASF Secretary. The IP
> > > clearance form can be found here: http://incubator.apache.org/
> > > ip-clearance/persistent-distributed-store-ignite.html
> > > This vote is to discover if the Apache Ignite PMC and community are in
> > > favour of accepting this contribution.
> > > This vote will be open for at least 72 hours:
> > > [ ] +1, accept contribution of the Persistent Store into the project
> > > [ ] 0, no opinion
> > > [ ] -1, reject contribution because...
> > >
> > > Regards,
> > > Denis
> > >
> > >
> >
>

Re: TC for master is moved to Ignite 2.0 test suite

[Vladimir Ozerov]

Pavel,

Yes, these two:
http://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:Ignite20Tests_IgniteBasic
http://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:Ignite20Tests_IgniteBinaryBasic

They both execute org.apache.ignite.testsuites.IgniteBasicTestSuite. Looks
like we should merge them accurately.

On Tue, May 23, 2017 at 10:27 AM, Dmitry Pavlov 
wrote:

> Hi, Vladimir,
>
> There is a chance that in
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=
> projectOverview
> some
> configs are for binary + simple oblect names (no package name) tests.
>
> But if there is some suspicious link that is candidate to removal, please
> feel free to contact me.
>
> Best Regards,
> Dmitry Pavlov
>
> вт, 23 мая 2017 г. в 10:24, Vladimir Ozerov :
>
> > Fantastic news, thank you guys! Though, I still see "Basic" and "Binary
> > Object Basic" suites. Should we drop one of them as well?
> >
> > On Tue, May 23, 2017 at 10:20 AM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> > > Igniters,
> > >
> > > Since we removed OptimizedMarshaller in Ignite 2.0 from the PublicAPI,
> we
> > > had a chance to remove several unnecessary test suites from the build
> > plan
> > > from Ignite 2.0. I pushed the changes for IGNITE-4947 ticket. From this
> > > moment you should run tests from Ignite 2.0 project, which is 14 test
> > > suites shorter than the previous plan.
> > >
> > > Kudos to Alexander Paschenko and Dmitriy Pavlov!
> > >
> > > --AG
> > >
> >
>

Re: Session Replication Update on spring boot platform

[Valentin Kulichenko]

Hi Rishi,

It was working for me in cluster environment after the fix [1] we discussed
in previous thread [2]. The fix was included in Ignite 2.0.

Can you please reattach the latest version of your app based on Ignite 2.0
and give a detailed step by step instruction on how to reproduce the issue
you're having?

[1] https://issues.apache.org/jira/browse/IGNITE-4948
[2]
http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-2741-spring-session-design-td14560.html

-Val

On Mon, May 22, 2017 at 8:35 PM, Rishi Yagnik  wrote:

> Hello Val,
>
> As I discussed earlier, the problem arises in the cluster environment.
>
> we have 2 SB staleless instance backed by Ignite data store.
>
> The local environment is working fine and I am able to see the user
> sessions are being stored correctly.
>
> I could not make session replication working with Ignite 2.0 in cluster
> environment so my fixes are of no use.
>
> IMO,The web filter approach is very intrusive approach with spring
> security and that is why I thought we need to come up with the solution
> which sits on top of spring security.
>
> The possible solution could be spring session.
>
> The example which I posted can be tested on cluster as well. Would Ignite
> team try out the clustering ?
>
> Looking for your inputs / suggestions on the issue.
>
> Thank you for all your help,
> Rishi
>
>
>
>
> On Mon, May 22, 2017 at 1:02 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Hi Rishi,
>>
>> I'm not sure I understand what the issue is. Can you elaborate a bit more
>> and provide exact examples of what is not working? What code tweaks are
>> required and how critical are they? Also I recall that your example was
>> working fine after the latest fixes in 1.9 (if I'm not mistaken). Did you
>> make any changes after that?
>>
>> -Val
>>
>> On Fri, May 19, 2017 at 11:34 PM, Rishi Yagnik 
>> wrote:
>>
>>> Hello Dmitriy,
>>>
>>> Thank you for the response, I would await for Val's feedback.
>>>
>>> I would like to discuss the possible approach for implementation here,
>>> and
>>> it could be one of this -
>>>
>>> https://issues.apache.org/jira/browse/IGNITE-2741
>>>
>>> Hope we all come on to conclusion here.
>>>
>>> Thanks,
>>>
>>> On Fri, May 19, 2017 at 3:57 PM, Dmitriy Setrakyan <
>>> dsetrak...@apache.org>
>>> wrote:
>>>
>>> > Hi Rishi,
>>> >
>>> > I think the best way is to file a ticket in Ignite Jira with your
>>> > findings. This ticket does not seem tremendously difficult, so
>>> hopefully
>>> > someone from the community will pick it up. All we need to do is to
>>> take
>>> > our existing Web Session Clustering [1][2] code and port it to work
>>> with
>>> > Spring Boot.
>>> >
>>> > BTW, feel free to contribute it yourself if you have time.
>>> >
>>> > [1] https://ignite.apache.org/use-cases/caching/web-session-
>>> > clustering.html
>>> > [2] https://apacheignite-mix.readme.io/docs/web-session-clustering
>>> >
>>> > D.
>>> >
>>> > On Fri, May 19, 2017 at 11:43 AM, Rishi Yagnik 
>>> > wrote:
>>> >
>>> >> Hello Val,
>>> >>
>>> >> I tested out the session replication on spring boot cluster and here
>>> is
>>> >> the
>>> >> result.
>>> >>
>>> >> My finding were as follows with Ignite 2.0 on session replication and
>>> hope
>>> >> that helps the team –
>>> >>
>>> >>- Spring Security Filters requires context to be set with
>>> >> Authentication
>>> >>object, later on when user authentication object is set on the
>>> ignite
>>> >>filter from Ignite cache, the spring security treat that as a new
>>> >> session
>>> >>just to prevent session fixation issue.
>>> >>- As spring security creates a new session and since there is no
>>> way to
>>> >>tell Ignite that user session has been changed, the user session
>>> is no
>>> >> good
>>> >>here despite the fact that user session holds by the ignite is a
>>> true
>>> >>session for that user.
>>> >>- Configuring web session filter does not work OOTB in spring boot
>>> >>platform, it require some additional tweaking in the code to make
>>> it
>>> >> work.
>>> >>
>>> >>
>>> >> So in the nutshell, I would think having spring session on ignite
>>> platform
>>> >> would support full session replication with spring boot platform.
>>> >>
>>> >>
>>> >> Please note that we have 2 SB instances, serving request round robin
>>> via
>>> >> F5
>>> >> ( load balancers) supported by 2 node ignite cluster.
>>> >>
>>> >> Any suggestions on how we want to conquer the issue ?
>>> >>
>>> >> Thanks,
>>> >>
>>> >> --
>>> >> Rishi Yagnik
>>> >>
>>> >
>>> >
>>>
>>>
>>> --
>>> Rishi Yagnik
>>>
>>
>>
>
>
> --
> Rishi Yagnik
>

[GitHub] ignite pull request #1931: IGNITE-5175: Performance degradation using evicti...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: TC for master is moved to Ignite 2.0 test suite

[Dmitry Pavlov]

Hi, Vladimir,

There is a chance that in
http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview
some
configs are for binary + simple oblect names (no package name) tests.

But if there is some suspicious link that is candidate to removal, please
feel free to contact me.

Best Regards,
Dmitry Pavlov

вт, 23 мая 2017 г. в 10:24, Vladimir Ozerov :

> Fantastic news, thank you guys! Though, I still see "Basic" and "Binary
> Object Basic" suites. Should we drop one of them as well?
>
> On Tue, May 23, 2017 at 10:20 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > Igniters,
> >
> > Since we removed OptimizedMarshaller in Ignite 2.0 from the PublicAPI, we
> > had a chance to remove several unnecessary test suites from the build
> plan
> > from Ignite 2.0. I pushed the changes for IGNITE-4947 ticket. From this
> > moment you should run tests from Ignite 2.0 project, which is 14 test
> > suites shorter than the previous plan.
> >
> > Kudos to Alexander Paschenko and Dmitriy Pavlov!
> >
> > --AG
> >
>

Re: TC for master is moved to Ignite 2.0 test suite

[Vladimir Ozerov]

Fantastic news, thank you guys! Though, I still see "Basic" and "Binary
Object Basic" suites. Should we drop one of them as well?

On Tue, May 23, 2017 at 10:20 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Igniters,
>
> Since we removed OptimizedMarshaller in Ignite 2.0 from the PublicAPI, we
> had a chance to remove several unnecessary test suites from the build plan
> from Ignite 2.0. I pushed the changes for IGNITE-4947 ticket. From this
> moment you should run tests from Ignite 2.0 project, which is 14 test
> suites shorter than the previous plan.
>
> Kudos to Alexander Paschenko and Dmitriy Pavlov!
>
> --AG
>

Re: [VOTE] Accept Contribution of Ignite Persistent Store

[Valentin Kulichenko]

+1

On Tue, May 23, 2017 at 8:42 AM, Semyon Boikov  wrote:

> +1
>
> On Tue, May 23, 2017 at 12:55 AM, Denis Magda  wrote:
>
> > Igniters,
> >
> > This branch (https://github.com/apache/ignite/tree/ignite-5267) adds a
> > distributed and transactional Persistent Store to Apache Ignite project.
> > The store seamlessly integrates with Apache Ignite 2.0 page memory
> > architecture. One of the main advantages of the store is that Apache
> Ignite
> > becomes fully operational from disk (SSD or Flash) without any need to
> > preload the data in memory. Plus, with full SQL support already available
> > in Apache Ignite, this feature will allow Apache Ignite serve as a
> > distributed SQL database, both in memory or on disk, while continuing to
> > support all the existing functionality on the current API.
> > More information here:
> > - Persistent Store Overview: https://cwiki.apache.org/
> > confluence/display/IGNITE/Persistent+Store+Overview
> > - Persistent Store Internal Design: https://cwiki.apache.org/
> > confluence/display/IGNITE/Persistent+Store+Internal+Design
> > The Persistent Store was developed by GridGain outside of Apache
> community
> > because it was requested by one of GridGain’s customers. Presently,
> > GridGain looks forward to donating the Persistent Store to ASF and given
> > the size of the contribution, it is prudent to follow Apache's IP
> clearance
> > process.
> > The SGA has been submitted and acknowledged by ASF Secretary. The IP
> > clearance form can be found here: http://incubator.apache.org/
> > ip-clearance/persistent-distributed-store-ignite.html
> > This vote is to discover if the Apache Ignite PMC and community are in
> > favour of accepting this contribution.
> > This vote will be open for at least 72 hours:
> > [ ] +1, accept contribution of the Persistent Store into the project
> > [ ] 0, no opinion
> > [ ] -1, reject contribution because...
> >
> > Regards,
> > Denis
> >
> >
>

TC for master is moved to Ignite 2.0 test suite

[Alexey Goncharuk]

Igniters,

Since we removed OptimizedMarshaller in Ignite 2.0 from the PublicAPI, we
had a chance to remove several unnecessary test suites from the build plan
from Ignite 2.0. I pushed the changes for IGNITE-4947 ticket. From this
moment you should run tests from Ignite 2.0 project, which is 14 test
suites shorter than the previous plan.

Kudos to Alexander Paschenko and Dmitriy Pavlov!

--AG

[GitHub] ignite pull request #1986: IGNITE-4947: Create AI 2.0 TC suites

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Вадим Опольский]

Hello , Prachi!

I reviewed reference. Removing occurrence it was the right action, Thank
you!

Vadim Opolski



2017-05-23 2:19 GMT+03:00 Prachi Garg (JIRA) :

>
> [ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.
> atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
> l=16020380#comment-16020380 ]
>
> Prachi Garg commented on IGNITE-4052:
> -
>
> [~ntikhonov] I have merged the changes and also made some edits. Within
> the Json code block, the following was mentioned twice.
> "MESOS_USER" : "userA",
>  "MESOS_ROLE" :  "role1"
>
> I have removed one occurrence. Please review and confirm that it was the
> right action.
>
> > Add ability to set up users for MESOS
> > -
> >
> > Key: IGNITE-4052
> > URL: https://issues.apache.org/jira/browse/IGNITE-4052
> > Project: Ignite
> >  Issue Type: Improvement
> >  Components: general
> >Affects Versions: 1.7
> >Reporter: Nikolay Tikhonov
> >Assignee: Prachi Garg
> >Priority: Trivial
> >
> > In current implementation Ignite Mesos Framework connects to MESOS
> cluster via current user. Need to add ability to configure this parameters
> via system env properties. Also need to add properties for mesos role.
> > See org/apache/ignite/mesos/IgniteFramework.java:537
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>

[jira] [Created] (IGNITE-5272) Try get rid of custom discovery message for client cache start

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-5272:


 Summary: Try get rid of custom discovery message for client cache 
start
 Key: IGNITE-5272
 URL: https://issues.apache.org/jira/browse/IGNITE-5272
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Semen Boikov
Assignee: Semen Boikov
Priority: Critical
 Fix For: 2.1


Currently both server and client caches are started in the same way - using 
custom discovery message. Most probably for client caches we do not need strong 
ordering guarentees which discovery messages provide.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Accept Contribution of Ignite Persistent Store

[Semyon Boikov]

+1

On Tue, May 23, 2017 at 12:55 AM, Denis Magda  wrote:

> Igniters,
>
> This branch (https://github.com/apache/ignite/tree/ignite-5267) adds a
> distributed and transactional Persistent Store to Apache Ignite project.
> The store seamlessly integrates with Apache Ignite 2.0 page memory
> architecture. One of the main advantages of the store is that Apache Ignite
> becomes fully operational from disk (SSD or Flash) without any need to
> preload the data in memory. Plus, with full SQL support already available
> in Apache Ignite, this feature will allow Apache Ignite serve as a
> distributed SQL database, both in memory or on disk, while continuing to
> support all the existing functionality on the current API.
> More information here:
> - Persistent Store Overview: https://cwiki.apache.org/
> confluence/display/IGNITE/Persistent+Store+Overview
> - Persistent Store Internal Design: https://cwiki.apache.org/
> confluence/display/IGNITE/Persistent+Store+Internal+Design
> The Persistent Store was developed by GridGain outside of Apache community
> because it was requested by one of GridGain’s customers. Presently,
> GridGain looks forward to donating the Persistent Store to ASF and given
> the size of the contribution, it is prudent to follow Apache's IP clearance
> process.
> The SGA has been submitted and acknowledged by ASF Secretary. The IP
> clearance form can be found here: http://incubator.apache.org/
> ip-clearance/persistent-distributed-store-ignite.html
> This vote is to discover if the Apache Ignite PMC and community are in
> favour of accepting this contribution.
> This vote will be open for at least 72 hours:
> [ ] +1, accept contribution of the Persistent Store into the project
> [ ] 0, no opinion
> [ ] -1, reject contribution because...
>
> Regards,
> Denis
>
>

Apache Zeppelin page on readme

[Roman Shtykh]

I noticed the latest Apache Zeppelin integration page on readme is 1.7, but 
there are integrations for 1.8 and 1.9 too. Missing update?

https://apacheignite-mix.readme.io/v1.7/docs/apache-zeppelin
-- Roman