Why GridCacheEvictionManager always use cfg.getEvictionPolicy/cfg.getEvictionPolicyFactory even there is NearEvictionPolicy configured?
As the method
*org.apache.ignite.internal.processors.cache.GridCacheAdapter#isNear* always
returns false, it will make the near cache eviction policy don't take
effect. Here is the code from
*org.apache.ignite.internal.processors.cache.GridCacheEvictionManager#start0*.
is this an expected behavior ?
==
CacheConfiguration cfg = cctx.config();
if (cctx.isNear()) {
plc = (cfg.getNearConfiguration().getNearEvictionPolicyFactory()
!= null) ?
(EvictionPolicy)cfg.getNearConfiguration().getNearEvictionPolicyFactory().create()
:
cfg.getNearConfiguration().getNearEvictionPolicy();
}
else if (cfg.getEvictionPolicyFactory() != null)
plc = (EvictionPolicy)cfg.getEvictionPolicyFactory().create();
else
plc = cfg.getEvictionPolicy();
plcEnabled = plc != null;
filter = cfg.getEvictionFilter();
==
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-8932) Docker image: doesn't handle SIGTERM
Ivan Yani created IGNITE-8932: - Summary: Docker image: doesn't handle SIGTERM Key: IGNITE-8932 URL: https://issues.apache.org/jira/browse/IGNITE-8932 Project: Ignite Issue Type: Bug Reporter: Ivan Yani So there's this "pid 1" issue with ignite image published on docker hub. The problem manifests in not being able to send SIGTERM to ignite java process. The reason of this issue is that the signal is sent to the shell script which start ignite, not ignite itself. To fix the issue you need to use "exec" in bash script to replace bash process with java process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4306: IGNITE-8931 Spring Framework versions upgraded
GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/4306 IGNITE-8931 Spring Framework versions upgraded You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-8931 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4306.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 #4306 commit ea43e546a75008e78fcb16457a75e22b72593c35 Author: Andrey Gura Date: 2018-07-04T19:36:38Z IGNITE-8931 Spring Framework versions upgraded ---
[GitHub] ignite pull request #4305: IGNITE-8929 WAL should not disable for the group ...
GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/4305 IGNITE-8929 WAL should not disable for the group if none a partition is not assigned to a local node You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8929 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4305.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 #4305 commit d5eb407ef2156420840f469a29517fa2ff213999 Author: Dmitriy Govorukhin Date: 2018-07-04T19:15:25Z IGNITE-8929 test reproducer + simple fix ---
Re: Ignite 2.6 emergency release suggestion
Igniters, I've moved IGNITE-8780 [1] issue to the next release. It can't be merged to AI 2.6 because it has many other dependent commits. [1] https://issues.apache.org/jira/browse/IGNITE-8780 On Wed, Jul 4, 2018 at 6:05 PM Ivan Rakov wrote: > > Andrey, thanks! > > I've cherry-picked the fixes to ignite-2.6 branch. > > Best Regards, > Ivan Rakov > > On 04.07.2018 16:26, Andrey Gura wrote: > > Ivan, > > > > I agree to include this fixes into AI 2.6 release. Please, feel free to > > merge. > > On Wed, Jul 4, 2018 at 4:08 PM Ivan Rakov wrote: > >> Igniters, > >> > >> Do we still have chance to extend 2.6 scope? > >> > >> I propose to include two more tickets into 2.6: > >> https://issues.apache.org/jira/browse/IGNITE-8769 > >> https://issues.apache.org/jira/browse/IGNITE-8910 > >> > >> We had data races in our free lists implementation. Fixes prevent > >> possibility of AssertionError during cache operation, which may lead to > >> hangs and data inconsistency. > >> > >> Best Regards, > >> Ivan Rakov > >> > >> > >> On 27.06.2018 18:56, Dmitry Pavlov wrote: > >>> Nikolay, thank you for such fast reaction. Tests are passing now. > >>> > >>> ср, 27 июн. 2018 г. в 17:28, Nikolay Izhikov : > >>> > Hello, Dmitriy. > > I fixed this issue, already. > Please, check it. > > В Ср, 27/06/2018 в 16:55 +0300, Dmitry Pavlov пишет: > > Hi Denis, > > > > currently anyway we have TC issue came from spark version migrations. > > > > I also currently experiencing challenges with my local environment > > setup. > > So I guess we have day or two to wait this fix. > > > > Sincerely. > > Dmitriy Pavlov > > > > ср, 27 июн. 2018 г. в 16:05, Denis Magda : > > > >> May I ask when? The current status of the ticket is not clear. > >> > >> -- > >> Denis > >> > >> On Wed, Jun 27, 2018 at 7:27 AM Spider (Alexey) < > spiderru5...@gmail.com> > >> wrote: > >> > >>> Yes, it will be in the release 2.6 > >>> > 27 июня 2018 г., в 14:15, Dmitry Pavlov > >>> написал(а): > Hi Igniters, > > I've returned https://issues.apache.org/jira/browse/IGNITE-8780 > to the > scope because it was initially discussed to be in this reselase. > > Alexey Stelmak, could you please confirm fix could be ready soon? > > Also I've cherry-picked javadoc fix. > > Sincerely, > Dmitriy Pavlov > > вт, 26 июн. 2018 г. в 20:33, Denis Magda : >
[jira] [Created] (IGNITE-8930) ODBC: Cursors are not closed when used through Go
Igor Sapego created IGNITE-8930:
---
Summary: ODBC: Cursors are not closed when used through Go
Key: IGNITE-8930
URL: https://issues.apache.org/jira/browse/IGNITE-8930
Project: Ignite
Issue Type: Bug
Components: odbc
Affects Versions: 2.5
Reporter: Igor Sapego
Fix For: 2.7
Client used: https://github.com/alexbrainman/odbc
Example app for reproducing:
[https://github.com/nombiezinja/ignite-cursor-example]
After several execution of statements user begins to get the following error:
{noformat}
2018/06/29 20:46:06 SQLExecute: {HY000} Too many open cursors (either close
other open cursors or increase the limit through
ClientConnectorConfiguration.maxOpenCursorsPerConnection) [maximum=128,
current=128]{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4088: ignite-7163 Validate connection from a pre-previo...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4088 ---
[GitHub] ignite pull request #4192: IGNITE-8182: TC.
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4192 ---
Re: Ignite 2.6 emergency release suggestion
Andrey, thanks! I've cherry-picked the fixes to ignite-2.6 branch. Best Regards, Ivan Rakov On 04.07.2018 16:26, Andrey Gura wrote: Ivan, I agree to include this fixes into AI 2.6 release. Please, feel free to merge. On Wed, Jul 4, 2018 at 4:08 PM Ivan Rakov wrote: Igniters, Do we still have chance to extend 2.6 scope? I propose to include two more tickets into 2.6: https://issues.apache.org/jira/browse/IGNITE-8769 https://issues.apache.org/jira/browse/IGNITE-8910 We had data races in our free lists implementation. Fixes prevent possibility of AssertionError during cache operation, which may lead to hangs and data inconsistency. Best Regards, Ivan Rakov On 27.06.2018 18:56, Dmitry Pavlov wrote: Nikolay, thank you for such fast reaction. Tests are passing now. ср, 27 июн. 2018 г. в 17:28, Nikolay Izhikov : Hello, Dmitriy. I fixed this issue, already. Please, check it. В Ср, 27/06/2018 в 16:55 +0300, Dmitry Pavlov пишет: Hi Denis, currently anyway we have TC issue came from spark version migrations. I also currently experiencing challenges with my local environment setup. So I guess we have day or two to wait this fix. Sincerely. Dmitriy Pavlov ср, 27 июн. 2018 г. в 16:05, Denis Magda : May I ask when? The current status of the ticket is not clear. -- Denis On Wed, Jun 27, 2018 at 7:27 AM Spider (Alexey) < spiderru5...@gmail.com> wrote: Yes, it will be in the release 2.6 27 июня 2018 г., в 14:15, Dmitry Pavlov написал(а): Hi Igniters, I've returned https://issues.apache.org/jira/browse/IGNITE-8780 to the scope because it was initially discussed to be in this reselase. Alexey Stelmak, could you please confirm fix could be ready soon? Also I've cherry-picked javadoc fix. Sincerely, Dmitriy Pavlov вт, 26 июн. 2018 г. в 20:33, Denis Magda :
[jira] [Created] (IGNITE-8929) WAL should not disable for the group if none a partition is not assigned to a local node.
Dmitriy Govorukhin created IGNITE-8929: -- Summary: WAL should not disable for the group if none a partition is not assigned to a local node. Key: IGNITE-8929 URL: https://issues.apache.org/jira/browse/IGNITE-8929 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8928) Hanging SQL queries with LOST partitions
Dmitriy Gladkikh created IGNITE-8928: Summary: Hanging SQL queries with LOST partitions Key: IGNITE-8928 URL: https://issues.apache.org/jira/browse/IGNITE-8928 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.5 Reporter: Dmitriy Gladkikh If there are partitions in the LOST state, SQL requests hang. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4301: IGNITE-8925
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4301 ---
[jira] [Created] (IGNITE-8927) Hangs when executing an SQL query when there are LOST partitions
Dmitriy Gladkikh created IGNITE-8927: Summary: Hangs when executing an SQL query when there are LOST partitions Key: IGNITE-8927 URL: https://issues.apache.org/jira/browse/IGNITE-8927 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.5 Reporter: Dmitriy Gladkikh If there are partitions in the LOST state, SQL query hang. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts
Hi, I’ve updated the proposed documentation update with a description of metricsUpdateFrequency and a detailed description of failureDetectionTimeout and clientFailureDetectionTimeout relations. The draft is attached to https://issues.apache.org/jira/browse/IGNITE-7704. It seems that relation between failureDetectionTimeout and clientFailureDetectionTimeout is currently too tricky and should also be changed in future. The problem is that in a server-client connection the server will use clientFailureDetectionTimeout but client will use failureDetectionTimeout. In other words, clients ignore clientFailureDetectionTimeout and just use failureDetectionTimeout. Because of that, one has to provide different values of failureDetectionTimeout in server and client configs which seems confusing and inconvenient. So I’d like to add one more point to my earlier proposal: 5. Always use clientFailureDetectionTimeout on clients instead of failureDetectionTimeout *What*: change code to use clientFailureDetectionTimeout on clients *When*: update code and readme.io docs in 2.7 Thanks, Stan From: Valentin Kulichenko Sent: 30 мая 2018 г. 19:09 To: dev@ignite.apache.org Subject: Re: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts Stan, Looks like you suggest to only change the default. If so, it's OK. But let's not change the behavior of these timeouts for the case they are explicitly set in config. Thanks, Val On Wed, May 30, 2018 at 1:06 AM, Stanislav Lukyanov wrote: > On networkTimeout: no, we don’t have anything like that in > TcpCommunicationSpi. > > On socketWriteTimeout: > First, its semantic is very close to TcpDicsoverySpi.socketTimeout (with > the exception that communication uses NIO), and the latter defaults to > failureDetectionTimeout, > so I think it would help to avoid confusion. > Second, I think we can’t deprecate something without an alternative that > would work for most users. > On the other hand, if we do default socketWriteTimeout to > failureDetectionTimeout then we reach a pretty decent API state > where one only needs two properties in IgniteConfiguration neither of > which we’re considering for deprecation and removal in 3.0. > > Stan > > From: Valentin Kulichenko > Sent: 29 мая 2018 г. 22:17 > To: dev@ignite.apache.org > Subject: Re: IgniteConfiguration, TcpDiscoverySpi, > TcpCommunicationSpitimeouts > > Stan, > > OK, I got confused a little :) > > I do agree that TcpDiscoverySpi.networkTimeout should inherit from > IgniteConfiguration.networkTImeout if not set explicitly. Do we have the > same setting for TcpCommunicationSpi, BTW? If yes, behavior should be > consistent. > > As for TcpCommunicationSpi.socketWriteTimeout, I'm not sure why you want > to > change its behavior. Can we just deprecate it and eventually remove, just > as we plan to do for all timeouts from #2? > > -Val > > On Tue, May 29, 2018 at 3:50 AM, Stanislav Lukyanov < > stanlukya...@gmail.com> > wrote: > > > Val, > > > > Which timeouts do you mean? > > > > In #2 I don’t propose to change behavior. > > > > I propose to change behavior for a couple of settings in #3 though. > > I believe the correct approach here would be to target the behavior > change > > for 2.6, > > but keep in mind that we’ll need to carefully analyze the impact before > > actually making the changes. > > > > Thanks, > > Stan > > > > From: Valentin Kulichenko > > Sent: 29 мая 2018 г. 0:57 > > To: dev@ignite.apache.org > > Subject: Re: IgniteConfiguration, TcpDiscoverySpi, > > TcpCommunicationSpitimeouts > > > > Hi Stan, > > > > I'm 100% for this activity, however I don't think we should change the > > behavior of timeouts you listed in #2 - this can lead to unexpected > > behavior for users who already use them. I would just deprecate them and > > eventually remove. > > > > -Val > > > > On Mon, May 28, 2018 at 1:29 PM, Stanislav Lukyanov < > > stanlukya...@gmail.com> > > wrote: > > > > > Hi folks, > > > > > > It looks like we stopped half-way with this activity. I’d like to pick > it > > > up. > > > > > > All seem to agree that we should simplify the timeout settings. > > > Here are the specific actions I’d like to propose: > > > > > > 1. Promote the use of global timeouts as the best practice > > > *What*: update the docs to encourage users to rely on the following > > > timeouts for their “network stability” settings > > > IgniteConfiguration.failureDetectionTimeout > > > IgniteConfiguration.clientFailureDetectionTimeout > > > IgniteConfiguration.networkTimeout > > > *When*: update readme.io docs for 2.5 and Javadoc for 2.6 > > > > > > 2. Discourage the use of finer timeouts > > > *What*: > > > - update the docs to discourage users to use the following timeouts and > > > announce their upcoming deprecation and removal > > > TcpDiscoverySpi.socketTimeout > > > TcpDiscoverySpi.ackTimeout > > > TcpDiscoverySpi.maxAckTimeout > > > TcpDiscoverySpi.reconnectCount > > > TcpCommunicationSpi.connectTimeout > > >
[jira] [Created] (IGNITE-8926) Deadlock in meta data registration
Mikhail Cherkasov created IGNITE-8926: - Summary: Deadlock in meta data registration Key: IGNITE-8926 URL: https://issues.apache.org/jira/browse/IGNITE-8926 Project: Ignite Issue Type: Bug Components: general Reporter: Mikhail Cherkasov Assignee: Ilya Lantukh Attachments: 11948_WorkdayFabricManager.jstack Please file the attached jstack file with a deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Ignite 2.6 emergency release suggestion
Ivan, I agree to include this fixes into AI 2.6 release. Please, feel free to merge. On Wed, Jul 4, 2018 at 4:08 PM Ivan Rakov wrote: > > Igniters, > > Do we still have chance to extend 2.6 scope? > > I propose to include two more tickets into 2.6: > https://issues.apache.org/jira/browse/IGNITE-8769 > https://issues.apache.org/jira/browse/IGNITE-8910 > > We had data races in our free lists implementation. Fixes prevent > possibility of AssertionError during cache operation, which may lead to > hangs and data inconsistency. > > Best Regards, > Ivan Rakov > > > On 27.06.2018 18:56, Dmitry Pavlov wrote: > > Nikolay, thank you for such fast reaction. Tests are passing now. > > > > ср, 27 июн. 2018 г. в 17:28, Nikolay Izhikov : > > > >> Hello, Dmitriy. > >> > >> I fixed this issue, already. > >> Please, check it. > >> > >> В Ср, 27/06/2018 в 16:55 +0300, Dmitry Pavlov пишет: > >>> Hi Denis, > >>> > >>> currently anyway we have TC issue came from spark version migrations. > >>> > >>> I also currently experiencing challenges with my local environment setup. > >>> So I guess we have day or two to wait this fix. > >>> > >>> Sincerely. > >>> Dmitriy Pavlov > >>> > >>> ср, 27 июн. 2018 г. в 16:05, Denis Magda : > >>> > May I ask when? The current status of the ticket is not clear. > > -- > Denis > > On Wed, Jun 27, 2018 at 7:27 AM Spider (Alexey) < > >> spiderru5...@gmail.com> > wrote: > > > Yes, it will be in the release 2.6 > > > >> 27 июня 2018 г., в 14:15, Dmitry Pavlov > > написал(а): > >> Hi Igniters, > >> > >> I've returned https://issues.apache.org/jira/browse/IGNITE-8780 > >> to the > >> scope because it was initially discussed to be in this reselase. > >> > >> Alexey Stelmak, could you please confirm fix could be ready soon? > >> > >> Also I've cherry-picked javadoc fix. > >> > >> Sincerely, > >> Dmitriy Pavlov > >> > >> вт, 26 июн. 2018 г. в 20:33, Denis Magda : > > >
Re: Ignite 2.6 emergency release suggestion
Igniters, Do we still have chance to extend 2.6 scope? I propose to include two more tickets into 2.6: https://issues.apache.org/jira/browse/IGNITE-8769 https://issues.apache.org/jira/browse/IGNITE-8910 We had data races in our free lists implementation. Fixes prevent possibility of AssertionError during cache operation, which may lead to hangs and data inconsistency. Best Regards, Ivan Rakov On 27.06.2018 18:56, Dmitry Pavlov wrote: Nikolay, thank you for such fast reaction. Tests are passing now. ср, 27 июн. 2018 г. в 17:28, Nikolay Izhikov : Hello, Dmitriy. I fixed this issue, already. Please, check it. В Ср, 27/06/2018 в 16:55 +0300, Dmitry Pavlov пишет: Hi Denis, currently anyway we have TC issue came from spark version migrations. I also currently experiencing challenges with my local environment setup. So I guess we have day or two to wait this fix. Sincerely. Dmitriy Pavlov ср, 27 июн. 2018 г. в 16:05, Denis Magda : May I ask when? The current status of the ticket is not clear. -- Denis On Wed, Jun 27, 2018 at 7:27 AM Spider (Alexey) < spiderru5...@gmail.com> wrote: Yes, it will be in the release 2.6 27 июня 2018 г., в 14:15, Dmitry Pavlov написал(а): Hi Igniters, I've returned https://issues.apache.org/jira/browse/IGNITE-8780 to the scope because it was initially discussed to be in this reselase. Alexey Stelmak, could you please confirm fix could be ready soon? Also I've cherry-picked javadoc fix. Sincerely, Dmitriy Pavlov вт, 26 июн. 2018 г. в 20:33, Denis Magda :
[GitHub] ignite pull request #4304: IGNITE-8801 Change default behaviour of atomic op...
GitHub user SomeFire opened a pull request: https://github.com/apache/ignite/pull/4304 IGNITE-8801 Change default behaviour of atomic operations inside txs You can merge this pull request into a Git repository by running: $ git pull https://github.com/SomeFire/ignite ignite-8801 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4304.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 #4304 commit 2437cc03edaf183f73a646fc682da515ec4867c5 Author: Dmitrii Ryabov Date: 2018-07-04T09:35:18Z IGNITE-8801 Change default behaviour of atomic operations inside transactions ---
[GitHub] ignite pull request #4303: IGNITE-8715
GitHub user xtern opened a pull request: https://github.com/apache/ignite/pull/4303 IGNITE-8715 You can merge this pull request into a Git repository by running: $ git pull https://github.com/xtern/ignite IGNITE-8715 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4303.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 #4303 commit c8518bf8b541d340ad51eb047e91f2e47a9f75eb Author: pereslegin-pa Date: 2018-07-04T12:17:42Z IGNITE-8715 Cleanup closeables (tck fix). ---
[GitHub] ignite pull request #4082: IGNITE-8628: Expose list of SQL (ODBC\JDBC\Thin) ...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4082 ---
[GitHub] ignite pull request #4302: IGNITE-8904 Check rebalance config on consistency
GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/4302 IGNITE-8904 Check rebalance config on consistency You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8904 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4302.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 #4302 commit 8d3cf1949060535cb11d2022b4959fc8b08b8dde Author: Pavel Kovalenko Date: 2018-07-04T11:09:44Z IGNITE-8904 WIP commit 4a9cf96cc51c7f6f3975c99a2910554fa233d868 Author: Pavel Kovalenko Date: 2018-07-04T12:07:26Z IGNITE-8904 Check rebalance thread pool size on node join. ---
[GitHub] ignite pull request #4301: IGNITE-8925
GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/4301 IGNITE-8925 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8925 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4301.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 #4301 commit 0a829af33a93fe74521dc76a300eac096a08e4f4 Author: devozerov Date: 2018-07-04T12:01:38Z Fixed. ---
[jira] [Created] (IGNITE-8925) SQL: Limit default number of threads for CREATE INDEX to 4
Vladimir Ozerov created IGNITE-8925:
---
Summary: SQL: Limit default number of threads for CREATE INDEX to 4
Key: IGNITE-8925
URL: https://issues.apache.org/jira/browse/IGNITE-8925
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.7
Currently we allocate {{CPUs / 4}} cores for index creation. On powerful
machines we may allocate too much threads, so that "Maximum number of retries"
error start to appear in {{BPlusTree}}.
We need to limit default number of allocated cores to 4, because:
- Our original benchmarks shown that >4 cores do not give significant boost
(due to retries and page splits)
- Avoid "too much retries" error
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4294: Ignite 8910
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4294 ---
[GitHub] ignite pull request #4300: Ignite 8776:Eviction policy MBeans are never regi...
GitHub user kcmvp opened a pull request: https://github.com/apache/ignite/pull/4300 Ignite 8776:Eviction policy MBeans are never registered if evictionPolicyFactory is used Please help to review it. Thanks You can merge this pull request into a Git repository by running: $ git pull https://github.com/kcmvp/ignite IGNITE-8776 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4300.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 #4300 commit d3de59c191cc973190f902a0fe9d74f842dedfc5 Author: kcmvp Date: 2018-07-04T10:47:51Z IGNITE-8776 Eviction policy MBeans are never registered if evictionPolicyFactory is used commit 56de13eaaab93294331bfc8078710e4bb0909623 Author: kcmvp Date: 2018-07-04T10:50:38Z Merge branch 'master' into IGNITE-8776 ---
[GitHub] ignite pull request #4299: Ignite 2.4.6.b1
GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/4299 Ignite 2.4.6.b1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2.4.6.b1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4299.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 #4299 commit d53504adb1d4276f79ede2401e2d1512fe0287ec Author: devozerov Date: 2018-02-22T07:07:19Z IGNITE-7253: JDBC thin streaming: fixed default local buffer size, improved error messages in case of unsupported SQL statements. commit debc906a25d3e2d65db58e16307fae6f08460eeb Author: devozerov Date: 2018-02-27T09:13:52Z Revert "IGNITE-7253: JDBC thin streaming: fixed default local buffer size, improved error messages in case of unsupported SQL statements." This reverts commit d53504adb1d4276f79ede2401e2d1512fe0287ec. commit d8cf9e042c0e9afe65508c006d9d1c39779d78b9 Author: devozerov Date: 2018-02-27T09:14:21Z Revert "IGNITE-7253: Streaming mode for JDBC thin driver. This closes #3499." This reverts commit bc331f9de716c30d6f733e28821ab44da7ed0cf7. commit 975a7cdb68cb89da74ec78c3cf23f644050918ff Author: devozerov Date: 2018-02-27T09:49:44Z Merge branch 'ignite-2.4' into ignite-2.4.3 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/FsyncModeFileWriteAheadLogManager.java # parent/pom.xml commit 74a54d23913bd7195c525d8e222b4e4047515843 Author: Ilya Lantukh Date: 2018-02-28T07:08:54Z IGNITE-7836 Fixed handling of state change message when forceReassignment is false commit 2a70ede048f59753061973495f83927f47452d66 Author: Andrey Novikov Date: 2018-01-19T03:05:03Z IGNITE-6920 Web Console: Create default account for direct-install package. (cherry picked from commit e5005d9) commit 2f1ea2cdb76863008d4514f26845457bdeb7d6ed Author: Andrey Novikov Date: 2018-01-19T04:35:30Z IGNITE-6920 Minor fix. (cherry picked from commit 9cc7cbf) commit 62652f3fb1563ba149dcbccb80928d50b822ff36 Author: alexdel Date: 2018-01-25T08:49:28Z IGNITE-7064 Web Console: Implemented basic E2E tests. (cherry picked from commit ce96e4f) commit 06e891f1161af598e0aa4665f7a6047637d1c476 Author: Dmitriy Shabalin Date: 2018-01-25T09:51:44Z IGNITE-7522 Web Console: Fixed cluster selector state after cluster restart. (cherry picked from commit ac3cfb8) commit 291cb2c88118ccffebcf3383db629647faec1eee Author: Dmitriy Shabalin Date: 2018-01-25T10:33:13Z IGNITE-7529 Web Console: Refactor UIGrid column filters. (cherry picked from commit 08658ea) commit 443eafc718685e66c9a60058bd0ab56d88f9f0a6 Author: alexdel Date: 2018-01-25T14:38:36Z IGNITE-7064 Web Console: Minor test fix. (cherry picked from commit 4b6d9ad) commit 6f1df5c40100363b5922734223a774ff1d6a008e Author: Ilya Borisov Date: 2018-01-26T09:07:47Z IGNITE-7031 Web Console: Refactored confirmation cancellation logic. (cherry picked from commit 92ae3fe) commit 16982825fb06ff2724ba4583781cc15443c4f46d Author: Alexey Kuznetsov Date: 2018-02-02T10:07:57Z IGNITE-7610 Web Console: Profile page refactored to component. (cherry picked from commit 958975e) commit 9c6a52250e058c4546aef0d0ecee977c07076a1a Author: Alexey Kuznetsov Date: 2018-02-02T10:09:37Z IGNITE-7612 Web Console: Refactored mongoose schemas to separate module. (cherry picked from commit 71db707) commit 89e15830dedcb46f24d9cc9b922ba3b013331a18 Author: Vasiliy Sisko Date: 2018-02-12T10:22:10Z Web Agent: Fixed wrong config of IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE in demo startup. (cherry picked from commit 1a6e544) commit 18966673570425192e1b89fbb2c63d164b47eaca Author: Vasiliy Sisko Date: 2018-02-12T13:24:30Z IGNITE-7578 Actualized client connector configuration. (cherry picked from commit 819d746) commit 237063efa35c54bb9e9800ecf63ea223ec20a9ef Author: alexdel Date: 2018-02-19T04:25:24Z IGNITE-7650 Extracted signin/signup form to separate page, improved landing page. (cherry picked from commit 1925674) commit 679aeca7a3ff60a9dd478966d3949107d302d5db Author: Andrey Novikov Date: 2018-02-19T07:56:07Z IGNITE-7650 Fixed headers. (cherry picked from commit 67922b3) commit 5d5a6a05ec49f895e8a5edd505e496dcfe58a208 Author: Vasiliy Sisko Date: 2018-02-21T04:21:02Z IGNITE-6094 Web Agent: Enabled persistent in demo mode. (cherry picked from commit 3c35900) commit e35d8cfb06f52765959fc2e1883bf70fe0259f45 Author: Alexander Kalinin Date: 2018-02-21T07:03:20Z IGNITE-7320 Web Console - Fixed table headers for Safari. (cherry
[GitHub] ignite pull request #4297: IGNITE-8669: Added Evaluator and Binary Classific...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4297 ---
Re: [ML] Tuning the hyper-parameters of an estimator/evaluator
Hi, Alexey. Yes, I think we need it. And if you are ready for this task I created it for you: https://issues.apache.org/jira/browse/IGNITE-8924 Regards, Yury -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-8924) [ML] Parameter Grid for tuning hyper-parameters in Cross-Validation process
Yury Babak created IGNITE-8924: -- Summary: [ML] Parameter Grid for tuning hyper-parameters in Cross-Validation process Key: IGNITE-8924 URL: https://issues.apache.org/jira/browse/IGNITE-8924 Project: Ignite Issue Type: New Feature Components: ml Reporter: Yury Babak Assignee: Aleksey Zinoviev Fix For: 2.7 We want to have an analogue of Parameter Grid from scikit-learn to tune hyper-parameters in Cross-Validation process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Optimistic mode with serializable vs read_committed
All optimistic transactions on prepare phase (step 11) create tx instance GridDhtTxLocal. Try to lock keys on this step and if succeed then prepare phase is continued. On this step transaction context got created and keys are put into it for futher committing. Additionally, cluster version is cheked against initial one. But I wonder why serialization and read committed modes differs in this. Mistake ? вт, 3 июл. 2018 г. в 22:10, John Wilson : > Hi, > > I was reading this documentation, > > https://www.gridgain.com/resources/blog/apache-ignite-transactions-architecture-concurrency-modes-and-isolation-levels > , > to understand the difference between Optimistic mode with Serializable vs > read_committed. The only difference I see from the explanation given is > that for Serializable isolation, the "*primary nodes manage the transaction > requests internally*" before an ACK is sent to the coordinator while for > read_committed, the ACK is sent immediately and the nodes "*manage the > transaction requests internally*" later. > > My question: > > >1. What does "*primary nodes manage the transaction requests > internally"* exactly >mean? >2. What are the specific things a node has to do to manage transaction >requests internally? > > Thanks, > John >
[GitHub] ignite pull request #4298: Diskload
GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/4298 Diskload You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite diskload Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4298.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 #4298 commit d1c945da00fb5206e15b8a4adedd81f496db5b40 Author: devozerov Date: 2018-07-04T08:20:21Z Done ---
Re: Clusterwide settings validation
Hi Nikolay No, we have been beaten by https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%22rebalanceThreadPoolSize%22 it is not checked on start Utility I mean check org.apache.ignite.configuration.IgniteConfiguration and children On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov wrote: > Hello, Andrew. > > Can you clarify your question? > > What checks do you mean, exactly? > Do you mean internal Ignite checks or user-provided checks? > > Ignite checks configuration consistency on node start [1]. > > Ignite do have consistency check for a joining node. Take a look at [2] and > all of it children. > > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825 > [2] > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153 > > В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет: >> Hello everybody >> >> Our company has lots of nodes in cluster, and we have seen some >> problems with inconsistent settings on nodes clusterwide. To help us >> with this, we made an utility to check consistency of settings on >> running cluster, but it is a hack, better ways seems to be settings >> validation by each node itself on start/joining topology/etc.. >> >> 1) Is his needed? >> 2) Have the implementation details been discussed somewhere? >> >> Cheers
Re: Clusterwide settings validation
Hello, Andrew. Can you clarify your question? What checks do you mean, exactly? Do you mean internal Ignite checks or user-provided checks? Ignite checks configuration consistency on node start [1]. Ignite do have consistency check for a joining node. Take a look at [2] and all of it children. [1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825 [2] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153 В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет: > Hello everybody > > Our company has lots of nodes in cluster, and we have seen some > problems with inconsistent settings on nodes clusterwide. To help us > with this, we made an utility to check consistency of settings on > running cluster, but it is a hack, better ways seems to be settings > validation by each node itself on start/joining topology/etc.. > > 1) Is his needed? > 2) Have the implementation details been discussed somewhere? > > Cheers signature.asc Description: This is a digitally signed message part
[ML] Tuning the hyper-parameters of an estimator/evaluator
Hi, Igniters, I suggest to add analogue of Parameter Grid from scikit-learn to tune hyper-parameters in Cross-Validation process. Currently, the Ignite ML module has only Cross-Validation support and the user needs to find the best parameters manually in a few while-cycles. Yes, I could do this task. Alex.
[GitHub] ignite pull request #4297: IGNITE-8669: Added Evaluator and Binary Classific...
GitHub user zaleslaw opened a pull request: https://github.com/apache/ignite/pull/4297 IGNITE-8669: Added Evaluator and Binary Classification Metrics You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8669 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4297.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 #4297 ---
