[GitHub] ignite pull request #1355: IGNITE-4440
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 ProkofyevDate: 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 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
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 Setrakyanwrote: > 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
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 Zhdanovwrote: > > 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
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 Zhdanovwrote: > >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
>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
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 Zhdanovwrote: > 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
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 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
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 Zhdanovwrote: > 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
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
Denis Magda On Thu, Dec 15, 2016 at 6:22 PM, Anton Vinogradovwrote: > 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
Thanks, Denis, I've received and accepted it. Best Regards, Igor On Thu, Dec 15, 2016 at 7:03 PM, Denis Magdawrote: > 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
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 Magdawrote: > 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
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 Kalashnikovwrote: > > 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
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. MashenkovDate: 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
Vladimir, > On Dec 15, 2016, at 1:22 AM, Vladimir Ozerovwrote: > > 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
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
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 KuznetsovDate: 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
Hi Igor, Awesome news. I’ve sent you the invitation. — Denis > On Dec 15, 2016, at 5:13 AM, Igor Sapegowrote: > > 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
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. MashenkovDate: 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
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
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 PaschenkoDate: 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 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
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 Setrakyanwrote: > 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
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 Kuznetsovwrote: > 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
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 GoncharukDate: 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
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
Denis Magda P.s. 72 hours is not enough for such votes. On Thu, Dec 15, 2016 at 3:52 AM, Rohit Mohtawrote: > 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
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 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
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 Vladykinwrote: > 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
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
I created issue for this: https://issues.apache.org/jira/browse/IGNITE-4436 On Thu, Dec 15, 2016 at 4:11 PM, Sergi Vladykinwrote: > 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 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 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
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
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
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 Vladykinwrote: > 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 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
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 >