[GitHub] ignite pull request #1355: IGNITE-4440

[prokofyev]

GitHub user prokofyev opened a pull request:

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

IGNITE-4440

Added bcastCall() method to ScalarProjectionPimp scalar class.

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

$ git pull https://github.com/prokofyev/ignite ignite-4440

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

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


commit eb4a6aa22e075800d0ca449815e1bbbcddab1936
Author: Alexander Prokofyev 
Date:   2016-12-16T07:32:55Z

IGNITE-4440




---
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-4440) scalar misses bcastCall() in ScalarProjectionPimp class

[Alexander Prokofyev (JIRA)]

Alexander Prokofyev created IGNITE-4440:
---

 Summary: scalar misses bcastCall() in ScalarProjectionPimp class
 Key: IGNITE-4440
 URL: https://issues.apache.org/jira/browse/IGNITE-4440
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.8
Reporter: Alexander Prokofyev
Priority: Minor


It would be nice if ScalarProjectionPimp will add also bcastCall() method to 
ClusterGroup class like it already does with 
{code}
def bcastRun(@Nullable r: Run, @Nullable p: NF) {
value.ignite().compute(forPredicate(p)).broadcast(toRunnable(r))
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT] [VOTE] Apche Ignite PMC Chair Election

[Dmitriy Setrakyan]

Time to do the final tally.

Vladimir Ozerov, binding: 0, non-binding: 1
Konstantin Boudnik, binding: 3, non-binding: 1
Valentin Kulichenko, binding: 0, non-binding: 0
Denis Magda, binding: 7, non-binding: 1
Branko Čibej - withdrawn his candidacy

Denis Magda has been elected as the new Apache Ignite PMC chair.

Denis, congratulations! I am sure you will make a great PMC chair. Please
get familiar with PMC chair duties here:
http://apache.org/dev/pmc.html#chair

I will send an official board resolution tomorrow.

D.

On Sat, Dec 10, 2016 at 12:24 PM, Dmitriy Setrakyan 
wrote:

> According to the discussion on the dev list [1], the following candidates
> were proposed for the Apache Ignite PMC Chair position:
>
>  Vladimir Ozerov
>  Konstantin Boudnik
>  Valentin Kulichenko
>  Denis Magda
>  Branko Čibej
>
> The vote is taking place on the dev list, however only votes from Apache
> Ignite PMC members will be considered as binding.
>
> *Note that this is not +1 or -1 vote. Please reply to this email
> specifying the name of your preferred candidate for the Ignite PMC chair
> position (feel free to explain why).*
>
> The vote will go for 72 hours. Candidate who gets the most amount of votes
> (not the majority) will be elected.
>
> Note, that I specifically removed my name from the list, because the whole
> point is to rotate a PMC chair, and not to reelect one.
>
> [1] http://apache-ignite-developers.2346864.n4.nabble.com/
> DISCUSS-PMC-Chair-rotation-time-td11941.html
>

Re: Striped pool configuration

[Denis Magda]

Yakov, thanks.

Here are some thoughts from the Son of the Earth :)

> Another reason for not switching to striped pool completely is that stripes
> are good for cache updates and single or batched get operations since they
> reduce inter-thread communication and synchronization to minimum

How did the striped pool show itself for transactional updates that involve 2 
phase commit? Any benefits or degradation?

>  however I
> think that we should run, for example, SQL queries in old fashioned pools -
> first, they can fallback to scanning random data, second, we pause cache
> updates in some partition for query execution time.


Here we should decide what’s more important for us - throughout or latency. If 
to execute SQL queries in the striped pool using multiple partitioned threads 
then, for sure, it will affect latency of other operations that are sitting in 
the queue waiting for their time to be processed but, on the other hand, the 
overall throughput of the platform should be improved because the operations 
will be less halted all the time by synchronization needs.

VoltDB decided to go for with the throughput while our current architecture is 
mostly latency based.

—
Denis

> On Dec 15, 2016, at 11:22 AM, Yakov Zhdanov  wrote:
> 
> Denis, there was no discussion on dev list. Do not worry, Son of the Earth,
> you are all right :) I thought I would send letter a bit later when I
> finish the full scope of optimizations I have in plan.
> 
> Currently, I use striped pool only for cache messages that are targeted to
> some defined partition - cache update benchmarks showed very good growth in
> throughput.
> 
> I tried to switch public and system pool to striped mode, but I get a lot
> of hangs on TC - sometimes due to issues in tests sometimes due to issues
> in Ignite. For example, under some circumstances we can synchronously wait
> in system thread for some message to come. When message handler gets to the
> same stripe Ignite hangs. I have a list of such places discovered so far.
> After I fix them I will try re-approach the pools.
> 
> Another reason for not switching to striped pool completely is that stripes
> are good for cache updates and single or batched get operations since they
> reduce inter-thread communication and synchronization to minimum, however I
> think that we should run, for example, SQL queries in old fashioned pools -
> first, they can fallback to scanning random data, second, we pause cache
> updates in some partition for query execution time. I was thinking of
> splitting CPU resources between striped pool and system pool in some ratio.
> I will follow up on this in a couple of days and will explain what has been
> done and what I want to do.
> 
> Vladimir, I hope I responded to your points.
> 
> Thanks!
> 
> --Yakov

Re: Striped pool configuration

[Dmitriy Setrakyan]

Yakov,

I think that our thread pool configuration is getting overly complex. I am
reading your reasoning for having both, old and striped thread pools, and
even I get confused, even though I have written some of this code myself.

In my view, we should hide most of such configuration intricacies from
users, and select an appropriate thread pool for each task ourselves. Will
this be possible?

D.

On Thu, Dec 15, 2016 at 12:16 PM, Yakov Zhdanov  wrote:

> >In this case users will not be able to perform synchronous cache
> operations from compute tasks, right?
>
> why? you are still free to do this.
>
> --Yakov
>

Re: Striped pool configuration

[Yakov Zhdanov]

>In this case users will not be able to perform synchronous cache
operations from compute tasks, right?

why? you are still free to do this.

--Yakov

Re: Striped pool configuration

[Vladimir Ozerov]

In this case users will not be able to perform synchronous cache operations
from compute tasks, right?

On Thu, Dec 15, 2016 at 11:05 PM, Yakov Zhdanov 
wrote:

> do you agree with the point that we need to keep pub and sys pool together
> with striped pool for now?
>
> --Yakov
>



-- 
Vladimir Ozerov
Senior Software Architect
GridGain Systems
www.gridgain.com
*+7 (960) 283 98 40*

Fwd: Striped pool configuration

[Yakov Zhdanov]

do you agree with the point that we need to keep pub and sys pool together
with striped pool for now?

--Yakov

[jira] [Created] (IGNITE-4439) Create attribute based node filter

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4439:
---

 Summary: Create attribute based node filter
 Key: IGNITE-4439
 URL: https://issues.apache.org/jira/browse/IGNITE-4439
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 1.8
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
 Fix For: 1.9


We have a {{CacheConfiguration.nodeFilter}} configuration property which takes 
a predicate that defines on which nodes cache is deployed. Therefore using it 
implies creating a new class and deploying it on all nodes.

However, in vast majority of cases users filter out nodes based on custom 
attributes, so it can be useful to provide such implementation out of the box.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Striped pool configuration

[Vladimir Ozerov]

Yakov,

Not really :-) I asked on how to better expose it's configuration to API,
not about it's internals.

On Thu, Dec 15, 2016 at 10:22 PM, Yakov Zhdanov 
wrote:

> Denis, there was no discussion on dev list. Do not worry, Son of the Earth,
> you are all right :) I thought I would send letter a bit later when I
> finish the full scope of optimizations I have in plan.
>
> Currently, I use striped pool only for cache messages that are targeted to
> some defined partition - cache update benchmarks showed very good growth in
> throughput.
>
> I tried to switch public and system pool to striped mode, but I get a lot
> of hangs on TC - sometimes due to issues in tests sometimes due to issues
> in Ignite. For example, under some circumstances we can synchronously wait
> in system thread for some message to come. When message handler gets to the
> same stripe Ignite hangs. I have a list of such places discovered so far.
> After I fix them I will try re-approach the pools.
>
> Another reason for not switching to striped pool completely is that stripes
> are good for cache updates and single or batched get operations since they
> reduce inter-thread communication and synchronization to minimum, however I
> think that we should run, for example, SQL queries in old fashioned pools -
> first, they can fallback to scanning random data, second, we pause cache
> updates in some partition for query execution time. I was thinking of
> splitting CPU resources between striped pool and system pool in some ratio.
> I will follow up on this in a couple of days and will explain what has been
> done and what I want to do.
>
> Vladimir, I hope I responded to your points.
>
> Thanks!
>
> --Yakov
>



-- 
Vladimir Ozerov
Senior Software Architect
GridGain Systems
www.gridgain.com
*+7 (960) 283 98 40*

Fwd: Striped pool configuration

[Yakov Zhdanov]

Denis, there was no discussion on dev list. Do not worry, Son of the Earth,
you are all right :) I thought I would send letter a bit later when I
finish the full scope of optimizations I have in plan.

Currently, I use striped pool only for cache messages that are targeted to
some defined partition - cache update benchmarks showed very good growth in
throughput.

I tried to switch public and system pool to striped mode, but I get a lot
of hangs on TC - sometimes due to issues in tests sometimes due to issues
in Ignite. For example, under some circumstances we can synchronously wait
in system thread for some message to come. When message handler gets to the
same stripe Ignite hangs. I have a list of such places discovered so far.
After I fix them I will try re-approach the pools.

Another reason for not switching to striped pool completely is that stripes
are good for cache updates and single or batched get operations since they
reduce inter-thread communication and synchronization to minimum, however I
think that we should run, for example, SQL queries in old fashioned pools -
first, they can fallback to scanning random data, second, we pause cache
updates in some partition for query execution time. I was thinking of
splitting CPU resources between striped pool and system pool in some ratio.
I will follow up on this in a couple of days and will explain what has been
done and what I want to do.

Vladimir, I hope I responded to your points.

Thanks!

--Yakov

Re: [VOTE] Apche Ignite PMC Chair Election

[Saikat Maitra]

Denis Magda

On Thu, Dec 15, 2016 at 6:22 PM, Anton Vinogradov 
wrote:

> Denis Magda
>
> P.s. 72 hours is not enough for such votes.
>
> On Thu, Dec 15, 2016 at 3:52 AM, Rohit Mohta 
> wrote:
>
> > Vladimir Ozerov
> >
> >
> >
> > > On Dec 14, 2016, at 11:38, Dmitriy Setrakyan 
> > wrote:
> > >
> > > I will be closing the vote today, so please get your votes in.
> > >
> > > On Sat, Dec 10, 2016 at 12:24 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > >> According to the discussion on the dev list [1], the following
> > candidates
> > >> were proposed for the Apache Ignite PMC Chair position:
> > >>
> > >> Vladimir Ozerov
> > >> Konstantin Boudnik
> > >> Valentin Kulichenko
> > >> Denis Magda
> > >> Branko Čibej
> > >>
> > >> The vote is taking place on the dev list, however only votes from
> Apache
> > >> Ignite PMC members will be considered as binding.
> > >>
> > >> *Note that this is not +1 or -1 vote. Please reply to this email
> > >> specifying the name of your preferred candidate for the Ignite PMC
> chair
> > >> position (feel free to explain why).*
> > >>
> > >> The vote will go for 72 hours. Candidate who gets the most amount of
> > votes
> > >> (not the majority) will be elected.
> > >>
> > >> Note, that I specifically removed my name from the list, because the
> > whole
> > >> point is to rotate a PMC chair, and not to reelect one.
> > >>
> > >> [1] http://apache-ignite-developers.2346864.n4.nabble.com/
> > >> DISCUSS-PMC-Chair-rotation-time-td11941.html
> > >>
> >
>

Re: Access to apacheignite-mix.readme.io

[Igor Sapego]

Thanks, Denis, I've received and accepted it.

Best Regards,
Igor

On Thu, Dec 15, 2016 at 7:03 PM, Denis Magda  wrote:

> Hi Igor,
>
> Awesome news. I’ve sent you the invitation.
>
> —
> Denis
>
> > On Dec 15, 2016, at 5:13 AM, Igor Sapego  wrote:
> >
> > Hello, Igniters,
> >
> > I want to start working on the following ticket: [1].
> > To do so I need a write access to [2]. Can someone from community help
> me?
> >
> > [1] - https://issues.apache.org/jira/browse/IGNITE-4230
> > [2] - https://apacheignite-mix.readme.io
> >
> > Best Regards,
> > Igor
>
>

Re: Striped pool configuration

[Dmitriy Setrakyan]

Igniters,

Why not just move to striped pools and remove this confusion? At this point
we are forcing users to understand what a striped pool is, which seems
unnecessary in my view.

D.

On Thu, Dec 15, 2016 at 8:09 AM, Denis Magda  wrote:

> Vladimir,
>
> > On Dec 15, 2016, at 1:22 AM, Vladimir Ozerov 
> wrote:
> >
> > One of them is "striped pool" which can be used instead of current system
> > pool.
>
> Would you mind explaining the whole purpose of this pool and why it was
> decided to introduce it? If I missed some discussion happened on the dev
> list earlier please point out to this.
>
> —
> Denis

Re: greetings

[Denis Magda]

Hi Sergey,

Welcome to the Ignite community!

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

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

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

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

You can find interesting tickets to get started here:
https://ignite.apache.org/community/contribute.html#pick-ticket

Looking forward to your contributions!

Regards,
Denis

> On Dec 15, 2016, at 7:36 AM, Sergey Kalashnikov  wrote:
> 
> Greetings! My name is Sergey and I'd like to join and contribute to Ignite.
> 
> Best Regards,
> Sergey

[GitHub] ignite pull request #1353: IGNITE-4408: IndexingSpi supports BinaryObjects

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-4408: IndexingSpi supports BinaryObjects 

Allow BinaryObjects to be passed to IndexinSpi implementation.

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

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

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

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


commit b9f98d2db2cbfebdd353b3656a2f05de18b65bee
Author: Andrey V. Mashenkov 
Date:   2016-12-14T16:44:05Z

Fixed SpiQuery fails if GridQueryProcessor is disabled.

commit d6800754944004fdb354f6da2b31d5ea4e78d66a
Author: Andrey V. Mashenkov 
Date:   2016-12-15T14:53:10Z

Allow BinaryObjects pass to IndexingSpi.




---
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: Striped pool configuration

[Denis Magda]

Vladimir,

> On Dec 15, 2016, at 1:22 AM, Vladimir Ozerov  wrote:
> 
> One of them is "striped pool" which can be used instead of current system
> pool.

Would you mind explaining the whole purpose of this pool and why it was decided 
to introduce it? If I missed some discussion happened on the dev list earlier 
please point out to this.

—
Denis

[GitHub] ignite pull request #1351: IndexingSpi supports BinaryObjects

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
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 #1352: Igntie-4408

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Igntie-4408



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

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

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

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


commit c188c3c4a96eacb85ea8e08f0634288332432c1c
Author: Alexey Kuznetsov 
Date:   2016-09-28T01:46:23Z

IGNITE-3983 Fixed wrong cache load optimization. Test added.

commit 89c30c8b0be6915d2399be508ddcd9eb439a9aaa
Author: Alexey Kuznetsov 
Date:   2016-09-28T01:57:45Z

IGNITE-3965 @GridInternal tasks should run via standart LoadBalancingSpi. 
Added test.

commit a53c399e10926120106379d1c764edd7d3854e6a
Author: Alexey Kuznetsov 
Date:   2016-09-28T02:07:55Z

Merge ignite-1.6.9 into ignite-1.7.2.

commit ec9ddcd3d99d19403bf19e1172ede2afdab6c86f
Author: sboikov 
Date:   2016-09-28T09:05:28Z

Code style fixes.

commit 17c2fc0b69abd023b2a1e5da344e67951fd49408
Author: sboikov 
Date:   2016-09-28T09:56:17Z

ignite-2833 Need call 'touch' for cache entry if it was obtained using 
'entryEx'.

commit daf974d261efa525678d5fabc6191642c07f9ad4
Author: AKuznetsov 
Date:   2016-09-28T10:22:10Z

IGNITE-3965 Fixed issues found on review.

commit 53fbad7ddafdae7b368b0f207d06d16574978d62
Author: AKuznetsov 
Date:   2016-09-28T10:24:56Z

Merge branch ignite-1.6.9 into ignite-1.7.2.

commit 4ff19c20b169e0373eafc8025a838db8bfc61f27
Author: sboikov 
Date:   2016-09-28T10:47:51Z

ignite-3621 Fixed 'testEvictExpired'.

commit bfe4458448a59542713830f57713b3ac2af08e2b
Author: sboikov 
Date:   2016-09-28T11:31:24Z

ignite-3621 Fixed 'testEvictExpired'.

commit d643dcf2dd2caac4c3ff04cb72f31bbfbf97339a
Author: Pavel Tupitsyn 
Date:   2016-09-28T11:34:23Z

IGNITE-3970 .NET: Fix Cyrillic 'C' letters in code - add test

commit 474ade276c4ae3e8f93cce37473d37270b4e7ad9
Author: vozerov-gridgain 
Date:   2016-09-28T11:38:04Z

IGNITE-3988: Moved failing cloud tests to ignore module.

commit ccfaaf8d060ef984678d2376b16b5a17e7c17e9d
Author: vozerov-gridgain 
Date:   2016-09-28T11:38:17Z

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

commit c7fa918c10d771efa91cde1017662c26d0a61085
Author: Pavel Tupitsyn 
Date:   2016-09-28T11:47:17Z

Merge remote-tracking branch 'remotes/community/ignite-1.6.9' into 
ignite-1.7.3

commit b9105df77cc70b532f94899c754fba47e3e05e9a
Author: vozerov-gridgain 
Date:   2016-09-28T11:53:20Z

IGNITE-3989: Moved failing JTA tests to ignore module.

commit d595345765db2151ff432beecd478ce056393593
Author: vozerov-gridgain 
Date:   2016-09-28T12:08:38Z

IGNITE-3990: Moved failing Spring tests to "ignore" module.

commit e3f13455d4273e615727d0410783e3719db98f76
Author: sboikov 
Date:   2016-09-28T09:56:17Z

ignite-2833 Need call 'touch' for cache entry if it was obtained using 
'entryEx'.

(cherry picked from commit 17c2fc0)

commit b2faa339acb2eea24e6dd5e0c21fc3d3d0592ff6
Author: sboikov 
Date:   2016-09-28T10:47:51Z

ignite-3621 Fixed 'testEvictExpired'.

(cherry picked from commit 4ff19c2)

commit 74d2fc2416b8e6bc0598152552021f984a013061
Author: sboikov 
Date:   2016-09-28T11:31:24Z

ignite-3621 Fixed 'testEvictExpired'.

(cherry picked from commit bfe4458)

commit d2563dacceea61b19bb6e083e29ebacc28fdd323
Author: vozerov-gridgain 
Date:   2016-09-28T12:51:55Z

IGNITE-3993: Added failing client tests to "ignored" test suite.

commit 33d34941390c00e8d6a2488e8f2e11e6abba8a01
Author: sboikov 
Date:   2016-09-28T12:54:52Z

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

commit 78144c4c9d6200ceef8b666a186039685f053381
Author: vozerov-gridgain 
Date:   2016-09-28T13:52:13Z

Fixed incorrect test count calculation leading to afterTestsStopped() not 
being called.

commit e3dfdecc3607b5f3183bfcb1ce36c57543a8965f
Author: Alexander Paschenko 
Date:   2016-09-28T13:46:46Z

Validate hash code presence in BinaryObject. Fixes #928

commit 53229e290f7d6aab9b504693bd2b93155ecd2bad
Author: Pavel Tupitsyn 
Date:   2016-09-28T14:07:47Z

IGNITE-3995 .NET: Introduced default non-null ASP.NET Session-State Store 
Provider cache name. This 

Re: Access to apacheignite-mix.readme.io

[Denis Magda]

Hi Igor,

Awesome news. I’ve sent you the invitation.

—
Denis

> On Dec 15, 2016, at 5:13 AM, Igor Sapego  wrote:
> 
> Hello, Igniters,
> 
> I want to start working on the following ticket: [1].
> To do so I need a write access to [2]. Can someone from community help me?
> 
> [1] - https://issues.apache.org/jira/browse/IGNITE-4230
> [2] - https://apacheignite-mix.readme.io
> 
> Best Regards,
> Igor

[GitHub] ignite pull request #1351: IndexingSpi supports BinaryObjects

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IndexingSpi supports BinaryObjects

Allow BinaryObjects to be passed to IndexinSpi implementation.


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

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

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

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


commit b9f98d2db2cbfebdd353b3656a2f05de18b65bee
Author: Andrey V. Mashenkov 
Date:   2016-12-14T16:44:05Z

Fixed SpiQuery fails if GridQueryProcessor is disabled.

commit d6800754944004fdb354f6da2b31d5ea4e78d66a
Author: Andrey V. Mashenkov 
Date:   2016-12-15T14:53:10Z

Allow BinaryObjects pass to IndexingSpi.




---
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.
---

greetings

[Sergey Kalashnikov]

Greetings! My name is Sergey and I'd like to join and contribute to Ignite.

Best Regards,
Sergey

[GitHub] ignite pull request #1350: IGNITE-4169 DML integration w/data streamer

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-4169 DML integration w/data streamer



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

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

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

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


commit 761223d285ff6faffa23b4e111ec631cd9a156c7
Author: Alexander Paschenko 
Date:   2016-12-15T15:30:12Z

IGNITE-4169 DML integration w/data streamer




---
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-4438) Remove old branch from Ignite's git repo

[Rohit Mohta (JIRA)]

Rohit Mohta created IGNITE-4438:
---

 Summary: Remove old branch from Ignite's git repo
 Key: IGNITE-4438
 URL: https://issues.apache.org/jira/browse/IGNITE-4438
 Project: Ignite
  Issue Type: Wish
 Environment: Github Repo: https://github.com/apache/ignite
Reporter: Rohit Mohta
Priority: Minor


There are numerous branches out there. Once a milestone is achieved, we should 
do some kind of cleanup to make sure we only have 3-6 branch at any given time. 
Tags can be used to record those milestones.

Advantage:
Folks submitting patch will know which branch to tag
Anyone starting with ignite, will be able to see what's going on.

Basically, better developer-experience.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: API to collect list of running SQL queries

[Alexey Kuznetsov]

Dmitriy,

Yes, that is what I'm going to do as first prototype.
But, I would prefer to discuss API with experts.

As Vladimir mentioned, there a usability use case with queries that also
could be discussed.

Sergi, could you, please, point a proper class where such API (for
collecting list of running queries) could be implemented?



On Thu, Dec 15, 2016 at 8:54 PM, Dmitriy Setrakyan 
wrote:

> Alexey,
>
> How about you only look at the client side, which obviously has the full
> query?
>
> D.
>
> On Thu, Dec 15, 2016 at 1:35 AM, Alexey Kuznetsov 
> wrote:
>
> > I like Vladimir idea.
> >
> > May be we could *compress* large strings?
> > Or may be we could have API to ask for *string with original SQL* on any
> > node?
> >
> > This *string with original SQL* only needed for special cases like
> > *monitoring utility* and *warning on long query*.
> >
> >
> > On Thu, Dec 15, 2016 at 4:11 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > I think in some cases it will not affect performance much (when query
> > > processing time is big enough), but if it is a large enough query
> (large
> > > string) which actually runs fast, this may affect throughput. I guess
> we
> > > have to measure some scenarios and evaluate the possible performance
> drop
> > > before making decisions.
> > >
> > > Sergi
> > >
> > > 2016-12-15 11:57 GMT+03:00 Vladimir Ozerov :
> > >
> > >> Sergi,
> > >>
> > >> How do you think, will it affect performance significantly if we start
> > >> passing original SQL between nodes? Not only this will help Alexey,
> but
> > >> also improve user experience, because currently long-running queries
> are
> > >> printed in transformed form, and it is pretty hard for users to
> > understand
> > >> what is going on.
> > >>
> > >> Vladimir.
> > >>
> > >> On Thu, Dec 15, 2016 at 11:28 AM, Sergi Vladykin <
> > >> sergi.vlady...@gmail.com>
> > >> wrote:
> > >>
> > >> > List of SQL queries running where? On some exact server node? The
> > >> original
> > >> > SQL query is not available there, we only have generated MAP part of
> > the
> > >> > query.
> > >> >
> > >> > Sergi
> > >> >
> > >> > 2016-12-15 6:13 GMT+03:00 Alexey Kuznetsov :
> > >> >
> > >> > > Hi!
> > >> > >
> > >> > > Do we have API to collect list of running SQL queries?
> > >> > > If not, how hard is to implement this?
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Alexey Kuznetsov
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
> >
> > --
> > Alexey Kuznetsov
> >
>



-- 
Alexey Kuznetsov

Re: API to collect list of running SQL queries

[Dmitriy Setrakyan]

Alexey,

How about you only look at the client side, which obviously has the full
query?

D.

On Thu, Dec 15, 2016 at 1:35 AM, Alexey Kuznetsov 
wrote:

> I like Vladimir idea.
>
> May be we could *compress* large strings?
> Or may be we could have API to ask for *string with original SQL* on any
> node?
>
> This *string with original SQL* only needed for special cases like
> *monitoring utility* and *warning on long query*.
>
>
> On Thu, Dec 15, 2016 at 4:11 PM, Sergi Vladykin 
> wrote:
>
> > I think in some cases it will not affect performance much (when query
> > processing time is big enough), but if it is a large enough query (large
> > string) which actually runs fast, this may affect throughput. I guess we
> > have to measure some scenarios and evaluate the possible performance drop
> > before making decisions.
> >
> > Sergi
> >
> > 2016-12-15 11:57 GMT+03:00 Vladimir Ozerov :
> >
> >> Sergi,
> >>
> >> How do you think, will it affect performance significantly if we start
> >> passing original SQL between nodes? Not only this will help Alexey, but
> >> also improve user experience, because currently long-running queries are
> >> printed in transformed form, and it is pretty hard for users to
> understand
> >> what is going on.
> >>
> >> Vladimir.
> >>
> >> On Thu, Dec 15, 2016 at 11:28 AM, Sergi Vladykin <
> >> sergi.vlady...@gmail.com>
> >> wrote:
> >>
> >> > List of SQL queries running where? On some exact server node? The
> >> original
> >> > SQL query is not available there, we only have generated MAP part of
> the
> >> > query.
> >> >
> >> > Sergi
> >> >
> >> > 2016-12-15 6:13 GMT+03:00 Alexey Kuznetsov :
> >> >
> >> > > Hi!
> >> > >
> >> > > Do we have API to collect list of running SQL queries?
> >> > > If not, how hard is to implement this?
> >> > >
> >> > >
> >> > > --
> >> > > Alexey Kuznetsov
> >> > >
> >> >
> >>
> >
> >
>
>
> --
> Alexey Kuznetsov
>

[GitHub] ignite pull request #1349: ignite 4026

[ntikhonov]

GitHub user ntikhonov opened a pull request:

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

ignite 4026



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

$ git pull https://github.com/gridgain/apache-ignite ignite-8.0.1ea7-4026

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

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


commit 4155d239d648bf51d5531bf32cd79893f548f429
Author: Alexey Goncharuk 
Date:   2016-09-14T15:07:38Z

Restore cache states in checkpoint record.

commit 749a9024e67e6de7e4fab9b96ce638d8e6e60fd2
Author: Ilya Lantukh 
Date:   2016-09-14T16:27:03Z

Fixed eviction and test failures.

commit d3a0607bb8993d0db657dcd1c554bb0a6f5c72fb
Author: Sergi Vladykin 
Date:   2016-09-14T16:57:52Z

ignite-db-x - checkChildren

commit bcf583af770857d667582a599c56cea1277b5b5d
Author: Alexey Goncharuk 
Date:   2016-09-14T19:05:27Z

Merge branch 'db-x-free-11289' of github.com:ggprivate/ggprivate into 
ignite-gg-11427

commit af1974c5f5678e57f01ac11eb972e8a6dc392d89
Author: Alexey Goncharuk 
Date:   2016-09-14T19:05:34Z

Merge branch 'db-x-free-11289' of github.com:ggprivate/ggprivate into 
ignite-gg-11427

commit 911b6b3343f23e4d61cb872f6f8d8a40afb7cbe5
Author: Alexey Goncharuk 
Date:   2016-09-14T19:08:16Z

Fixing javadoc

commit d574038a4694d3a7273797696af4e1b712f8cfbc
Author: Alexey Goncharuk 
Date:   2016-09-15T07:12:17Z

Merge branch 'ignite-db-x' of https://github.com/gridgain/apache-ignite 
into ignite-gg-8.0.0.ea1

commit 36f4c862c905dfbd814eeab0a7182c50cc2970a0
Author: Alexey Goncharuk 
Date:   2016-09-15T07:15:58Z

Merge branch 'ignite-gg-8.0.0.ea1' of 
https://github.com/gridgain/apache-ignite into ignite-gg-11427

commit a1af356acab214f6bf10ce27228dfb2d339f1ce7
Author: Alexey Goncharuk 
Date:   2016-09-15T08:04:47Z

Code review WIP

commit aa7d28222563adbac0ddd246745e5e14e62d886e
Author: Alexey Goncharuk 
Date:   2016-09-15T08:13:38Z

EA1 - Fixed NPE

commit e9ca1474ba23457b4fc7cd0951632b64c3037987
Author: sboikov 
Date:   2016-09-15T09:40:00Z

GG-11386 Change data structure in ReuseList (merge with new FreeList)

commit 031edc84fed21d9262f9997121f75fbaabc50db8
Author: Alexey Goncharuk 
Date:   2016-09-15T12:06:06Z

EA1 - Fixes and verbose exceptions.

commit b747e9444d6e8bf43c0e9419c7f938280413f0e0
Author: Alexey Goncharuk 
Date:   2016-09-15T12:31:43Z

Merge ignite-db-x into ignite-gg-8.0.0.ea1

commit 49b72a60be52c3d89e9653bbb160560b00674f33
Author: Alexey Goncharuk 
Date:   2016-09-15T12:31:49Z

Merge ignite-db-x into ignite-gg-8.0.0.ea1

commit be990b13c8dfa05f873b6a6a408017baae38f24c
Author: EdShangGG 
Date:   2016-09-15T12:47:52Z

GG-11421 evictPage in PageMemoryImpl.Segment can fall in infinitive loop

commit 4f6da47402ecd8c53a87539126a55a5552877cc5
Author: Ilya Lantukh 
Date:   2016-09-15T14:16:22Z

Fixed GridCacheEntryMemorySizeSelfTest.

commit 8a97480637ecb76d6a03d7adce0f3069b8f69433
Author: Alexey Goncharuk 
Date:   2016-09-15T14:47:06Z

Merge ignite-gg-8.0.0.ea1 into ignite-gg-11427

commit fab881145246a85a18210a2418f17fdc22ce9fd3
Author: Ilya Lantukh 
Date:   2016-09-15T15:36:09Z

Muted test.

commit 6c8b647b76ece036350f45c505a08b9b162b0a25
Author: Ilya Lantukh 
Date:   2016-09-15T15:46:08Z

Fixed local cache size calculation.

commit a07ac3a8a447a420a32fc8c5a1d4d4fdc71313d9
Author: Alexey Goncharuk 
Date:   2016-09-15T16:00:36Z

Merge ignite-gg-8.0.0.ea1 into ignite-gg-11427

commit 00c9d150c9d80d936d5463f05a68d028c87a6632
Author: Ilya Lantukh 
Date:   2016-09-15T16:08:53Z

Removed test that is no longer relevant.

commit 346d1f2b91011e0348f119f20409590e22d36ddc
Author: Ilya Lantukh 
Date:   2016-09-15T16:17:28Z

Fixed GridCacheAtomicNearCacheSelfTest.

commit 7c24c87aa14cc53df134a24a9368fb5bb6509a17
Author: Ilya Lantukh 
Date:   2016-09-15T17:20:30Z

Added IndexingSpi#remove(...) call on removing non-existing entry to fix 
IgniteTxExceptionAbstractSelfTest.

commit eed389fea4d846ceb390e3ad43fb860034be41da
Author: Sergi Vladykin 
Date:   2016-09-15T18:36:04Z

ignite-db-x - validateTail

commit 491068f0dd47ef1545b27224ba516f61554fe1d6
Author: Sergi Vladykin 

Access to apacheignite-mix.readme.io

[Igor Sapego]

Hello, Igniters,

I want to start working on the following ticket: [1].
To do so I need a write access to [2]. Can someone from community help me?

[1] - https://issues.apache.org/jira/browse/IGNITE-4230
[2] - https://apacheignite-mix.readme.io

Best Regards,
Igor

Re: [VOTE] Apche Ignite PMC Chair Election

[Anton Vinogradov]

Denis Magda

P.s. 72 hours is not enough for such votes.

On Thu, Dec 15, 2016 at 3:52 AM, Rohit Mohta  wrote:

> Vladimir Ozerov
>
>
>
> > On Dec 14, 2016, at 11:38, Dmitriy Setrakyan 
> wrote:
> >
> > I will be closing the vote today, so please get your votes in.
> >
> > On Sat, Dec 10, 2016 at 12:24 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> >> According to the discussion on the dev list [1], the following
> candidates
> >> were proposed for the Apache Ignite PMC Chair position:
> >>
> >> Vladimir Ozerov
> >> Konstantin Boudnik
> >> Valentin Kulichenko
> >> Denis Magda
> >> Branko Čibej
> >>
> >> The vote is taking place on the dev list, however only votes from Apache
> >> Ignite PMC members will be considered as binding.
> >>
> >> *Note that this is not +1 or -1 vote. Please reply to this email
> >> specifying the name of your preferred candidate for the Ignite PMC chair
> >> position (feel free to explain why).*
> >>
> >> The vote will go for 72 hours. Candidate who gets the most amount of
> votes
> >> (not the majority) will be elected.
> >>
> >> Note, that I specifically removed my name from the list, because the
> whole
> >> point is to rotate a PMC chair, and not to reelect one.
> >>
> >> [1] http://apache-ignite-developers.2346864.n4.nabble.com/
> >> DISCUSS-PMC-Chair-rotation-time-td11941.html
> >>
>

[GitHub] ignite pull request #1348: Ignite 1.8.2 hadoop

[devozerov]

Github user devozerov closed the pull request at:

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


---
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-4437) Make sure data structures do not use outTx call

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-4437:
-

 Summary: Make sure data structures do not use outTx call
 Key: IGNITE-4437
 URL: https://issues.apache.org/jira/browse/IGNITE-4437
 Project: Ignite
  Issue Type: Improvement
  Components: cache, data structures
Reporter: Alexei Scherbakov
 Fix For: 2,0


Ignite's data structures use outTx call to avoid an intersection with user 
transaction.

This is no longer necessary, because system and user transactions are now 
separated.

Need to get rid of these calls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: API to collect list of running SQL queries

[Alexey Kuznetsov]

I like Vladimir idea.

May be we could *compress* large strings?
Or may be we could have API to ask for *string with original SQL* on any
node?

This *string with original SQL* only needed for special cases like
*monitoring utility* and *warning on long query*.


On Thu, Dec 15, 2016 at 4:11 PM, Sergi Vladykin 
wrote:

> I think in some cases it will not affect performance much (when query
> processing time is big enough), but if it is a large enough query (large
> string) which actually runs fast, this may affect throughput. I guess we
> have to measure some scenarios and evaluate the possible performance drop
> before making decisions.
>
> Sergi
>
> 2016-12-15 11:57 GMT+03:00 Vladimir Ozerov :
>
>> Sergi,
>>
>> How do you think, will it affect performance significantly if we start
>> passing original SQL between nodes? Not only this will help Alexey, but
>> also improve user experience, because currently long-running queries are
>> printed in transformed form, and it is pretty hard for users to understand
>> what is going on.
>>
>> Vladimir.
>>
>> On Thu, Dec 15, 2016 at 11:28 AM, Sergi Vladykin <
>> sergi.vlady...@gmail.com>
>> wrote:
>>
>> > List of SQL queries running where? On some exact server node? The
>> original
>> > SQL query is not available there, we only have generated MAP part of the
>> > query.
>> >
>> > Sergi
>> >
>> > 2016-12-15 6:13 GMT+03:00 Alexey Kuznetsov :
>> >
>> > > Hi!
>> > >
>> > > Do we have API to collect list of running SQL queries?
>> > > If not, how hard is to implement this?
>> > >
>> > >
>> > > --
>> > > Alexey Kuznetsov
>> > >
>> >
>>
>
>


-- 
Alexey Kuznetsov

Striped pool configuration

[Vladimir Ozerov]

Folks,

As I see important performance improvements were merged to the *master *branch.
One of them is "striped pool" which can be used instead of current system
pool. I think it's configuration is not very good at the moment:

int IgniteConfiguration.setStripedPoolSize();

Problems:
1) It has non-zero default meaning that it will be used by default. It is
ok, but if user previously configured system pool size with
"IgniteConfiguration.setSystemPoolSize()", then his config will be ignored
silently. It looks wrong to me to have two configurable sizes for a single
pool.
2) What if decide to add striped pool optimization for other pools in
future, e.g. for public pool? How are we going to name configuration
properties?

I think we should do the following:
1) Remove *"int stripedPoolSize"* property.
2) Add *"boolean systemThreadPoolStriped"* property, set it to *true *by
default.
3) Rely on existing *"int systemThreadPoolSize"* property to get number of
threads.

Thoughts?

Vladimir.

Re: API to collect list of running SQL queries

[Alexey Kuznetsov]

I created issue for this: https://issues.apache.org/jira/browse/IGNITE-4436

On Thu, Dec 15, 2016 at 4:11 PM, Sergi Vladykin 
wrote:

> I think in some cases it will not affect performance much (when query
> processing time is big enough), but if it is a large enough query (large
> string) which actually runs fast, this may affect throughput. I guess we
> have to measure some scenarios and evaluate the possible performance drop
> before making decisions.
>
> Sergi
>
> 2016-12-15 11:57 GMT+03:00 Vladimir Ozerov :
>
>> Sergi,
>>
>> How do you think, will it affect performance significantly if we start
>> passing original SQL between nodes? Not only this will help Alexey, but
>> also improve user experience, because currently long-running queries are
>> printed in transformed form, and it is pretty hard for users to understand
>> what is going on.
>>
>> Vladimir.
>>
>> On Thu, Dec 15, 2016 at 11:28 AM, Sergi Vladykin <
>> sergi.vlady...@gmail.com>
>> wrote:
>>
>> > List of SQL queries running where? On some exact server node? The
>> original
>> > SQL query is not available there, we only have generated MAP part of the
>> > query.
>> >
>> > Sergi
>> >
>> > 2016-12-15 6:13 GMT+03:00 Alexey Kuznetsov :
>> >
>> > > Hi!
>> > >
>> > > Do we have API to collect list of running SQL queries?
>> > > If not, how hard is to implement this?
>> > >
>> > >
>> > > --
>> > > Alexey Kuznetsov
>> > >
>> >
>>
>
>


-- 
Alexey Kuznetsov

[jira] [Created] (IGNITE-4436) SQL: create API to collect list of running SQL queries

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-4436:


 Summary: SQL: create API to collect list of running SQL queries
 Key: IGNITE-4436
 URL: https://issues.apache.org/jira/browse/IGNITE-4436
 Project: Ignite
  Issue Type: Task
  Components: SQL
Affects Versions: 1.8
Reporter: Alexey Kuznetsov
 Fix For: 2.0


It may be very useful for monitoring tools to be able to collect list of 
currently running SQL queries with possibility to cancel them.

See discussion on dev list for more info: 
http://apache-ignite-developers.2346864.n4.nabble.com/API-to-collect-list-of-running-SQL-queries-td13031.html




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4435) Discovery data distribution process optimization

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-4435:
---

 Summary: Discovery data distribution process optimization
 Key: IGNITE-4435
 URL: https://issues.apache.org/jira/browse/IGNITE-4435
 Project: Ignite
  Issue Type: Improvement
  Components: general
Reporter: Sergey Chugunov


h2. Notes
Previously upon new node joining topology grid components on each node has been 
collecting discovery data independently from the same components on other nodes.
This lead to a situation when *TcpDiscoveryNodeAddedMessage* and 
*TcpDiscoveryNodeAddFinishedMessage* carried a lot of duplicated data wasting 
network traffic.

Refactoring done within 
[IGNITE-4157|https://issues.apache.org/jira/browse/IGNITE-4157] introduced a 
way to reduce duplication, but only *GridMarshallerMappingProcessor* component 
took advantage of it.

h2. Acceptance Criteria
*  Identify all components needed to be optimized in terms of discovery data 
collection.
* Refactor them to reduce duplication of discovery data.
* Remove *filterDuplicatedData* method as obsolete from 
*DiscoveryDataContainer* when refactoring is done.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: API to collect list of running SQL queries

[Sergi Vladykin]

I think in some cases it will not affect performance much (when query
processing time is big enough), but if it is a large enough query (large
string) which actually runs fast, this may affect throughput. I guess we
have to measure some scenarios and evaluate the possible performance drop
before making decisions.

Sergi

2016-12-15 11:57 GMT+03:00 Vladimir Ozerov :

> Sergi,
>
> How do you think, will it affect performance significantly if we start
> passing original SQL between nodes? Not only this will help Alexey, but
> also improve user experience, because currently long-running queries are
> printed in transformed form, and it is pretty hard for users to understand
> what is going on.
>
> Vladimir.
>
> On Thu, Dec 15, 2016 at 11:28 AM, Sergi Vladykin  >
> wrote:
>
> > List of SQL queries running where? On some exact server node? The
> original
> > SQL query is not available there, we only have generated MAP part of the
> > query.
> >
> > Sergi
> >
> > 2016-12-15 6:13 GMT+03:00 Alexey Kuznetsov :
> >
> > > Hi!
> > >
> > > Do we have API to collect list of running SQL queries?
> > > If not, how hard is to implement this?
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > >
> >
>

[GitHub] ignite pull request #1345: IGNITE-4277

[devozerov]

Github user devozerov closed the pull request at:

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


---
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: API to collect list of running SQL queries

[Vladimir Ozerov]

Sergi,

How do you think, will it affect performance significantly if we start
passing original SQL between nodes? Not only this will help Alexey, but
also improve user experience, because currently long-running queries are
printed in transformed form, and it is pretty hard for users to understand
what is going on.

Vladimir.

On Thu, Dec 15, 2016 at 11:28 AM, Sergi Vladykin 
wrote:

> List of SQL queries running where? On some exact server node? The original
> SQL query is not available there, we only have generated MAP part of the
> query.
>
> Sergi
>
> 2016-12-15 6:13 GMT+03:00 Alexey Kuznetsov :
>
> > Hi!
> >
> > Do we have API to collect list of running SQL queries?
> > If not, how hard is to implement this?
> >
> >
> > --
> > Alexey Kuznetsov
> >
>

[jira] [Created] (IGNITE-4434) Fix label width for text mixin

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-4434:


 Summary: Fix label width for text mixin
 Key: IGNITE-4434
 URL: https://issues.apache.org/jira/browse/IGNITE-4434
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: API to collect list of running SQL queries

[Sergi Vladykin]

List of SQL queries running where? On some exact server node? The original
SQL query is not available there, we only have generated MAP part of the
query.

Sergi

2016-12-15 6:13 GMT+03:00 Alexey Kuznetsov :

> Hi!
>
> Do we have API to collect list of running SQL queries?
> If not, how hard is to implement this?
>
>
> --
> Alexey Kuznetsov
>