[jira] [Created] (IGNITE-13910) Do not release a segment if it is not present in FileWriteAheadLogManager#reserve
Kirill Tkalenko created IGNITE-13910: Summary: Do not release a segment if it is not present in FileWriteAheadLogManager#reserve Key: IGNITE-13910 URL: https://issues.apache.org/jira/browse/IGNITE-13910 Project: Ignite Issue Type: Bug Components: persistence Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.10 Error in *FileWriteAheadLogManager#reserve*, the segment is not released in its absence. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13909) Node.js client glob dependency is missing
Igor Sapego created IGNITE-13909:
Summary: Node.js client glob dependency is missing
Key: IGNITE-13909
URL: https://issues.apache.org/jira/browse/IGNITE-13909
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Igor Sapego
Assignee: Igor Sapego
This results in following errors:
{noformat}
Suite error: sql query test suite >
Message:
Failed: Cannot find module 'glob'
Stack:
error properties: Object({ code: 'MODULE_NOT_FOUND' })
Error: Cannot find module 'glob'
at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Function.getLogFiles
(D:\Development\git\ignite-nodejs-thin-client\spec\TestingHelper.js:478:22)
at Function.clearLogs
(D:\Development\git\ignite-nodejs-thin-client\spec\TestingHelper.js:486:39)
at Function._startNode
(D:\Development\git\ignite-nodejs-thin-client\spec\TestingHelper.js:491:23)
at Function.startTestServer
(D:\Development\git\ignite-nodejs-thin-client\spec\TestingHelper.js:350:57)
at Function.startTestServers
(D:\Development\git\ignite-nodejs-thin-client\spec\TestingHelper.js:340:33)
at Function.init
(D:\Development\git\ignite-nodejs-thin-client\spec\TestingHelper.js:211:29)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[MTCGA]: new failures in builds [5803500] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master-nightly MVCC Cache 7 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MvccCache7?branch=%3Cdefault%3E No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 02:08:39 25-12-2020
[jira] [Created] (IGNITE-13908) ODBC driver should show real nullability info
Igor Sapego created IGNITE-13908: Summary: ODBC driver should show real nullability info Key: IGNITE-13908 URL: https://issues.apache.org/jira/browse/IGNITE-13908 Project: Ignite Issue Type: Improvement Components: odbc Affects Versions: 2.9 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.10 Currently, it always return SQL_NULLABLE_UNKNOWN on request of nullability type of the column. Let's provide that information to the user of ODBC driver -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13907) CPP thin: allow user to limit number of max active connections per client
Igor Sapego created IGNITE-13907: Summary: CPP thin: allow user to limit number of max active connections per client Key: IGNITE-13907 URL: https://issues.apache.org/jira/browse/IGNITE-13907 Project: Ignite Issue Type: New Feature Components: thin client Affects Versions: 2.9 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.10 Thin clients now can establish connections with multiple servers simultaneously. It is implemented this way to make partition awareness [1] work or for fast failover if partition awareness is not used. However, sometimes it can create excessive load for cluster in use cases when there are a lot of thin clients. We should give user a possibility to limit maximum number of active connections established by a client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Limiting number of active connection for thin client
Hi Igniters, As you may know thin clients now can establish connections with multiple servers simultaneously. It is implemented this way to make partition awareness [1] work or for fast failover if partition awareness is not used. However, sometimes it can create excessive load for cluster in use cases when there are a lot of thin clients. I think, we should give user a possibility to limit maximum number of active connections established by a client. What do you think? [1] - https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients Best Regards, Igor
[jira] [Created] (IGNITE-13906) Possible deadlock between methods from GridEncryptionManager
Mirza Aliev created IGNITE-13906:
Summary: Possible deadlock between methods from
GridEncryptionManager
Key: IGNITE-13906
URL: https://issues.apache.org/jira/browse/IGNITE-13906
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Mirza Aliev
It seems that {{GridEncryptionManager}} uses {{metaStorageMux}} and
{{checkpointReadLock}} in an inconsistent way.
Sometimes, the implementation acquires the mutex fist and then
{{checkpointReadLock}}, sometimes vice versa, which may lead to a deadlock.
Let's consider the following scenario:
Thread-1: {{removeGroupKey}} acquired {{metaStorageMux}} and trying to get
{{checkpointReadLock}} (cannot proceed further because of checkpointer)
Therad-2: {{doChangeMasterKey}} acquired {{checkpointReadLock}} and trying to
get {{metaStorageMux}} (cannot proceed further due to thread-1)
Checkpointer-thread: trying to acquire the write lock (cannot get the lock due
to thread-2)
Possible solutuion: acquire {{metaStorageMux}} before {{checkpointReadLock}} in
{{doChangeMasterKey}} method
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13905) Support external cli modules by custom header in Manifest files
Kirill Gusakov created IGNITE-13905: --- Summary: Support external cli modules by custom header in Manifest files Key: IGNITE-13905 URL: https://issues.apache.org/jira/browse/IGNITE-13905 Project: Ignite Issue Type: Sub-task Reporter: Kirill Gusakov Assignee: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [ignite-python-thin-client] ivandasch commented on a change in pull request #1: IGNITE-13903 Add tox, docker-compose and travis integration, update pytest versions.
ivandasch commented on a change in pull request #1: URL: https://github.com/apache/ignite-python-thin-client/pull/1#discussion_r548627959 ## File path: docker-compose.yml ## @@ -0,0 +1,34 @@ +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. +# The ASF licenses this file to You under the Apache License, Version 2.0 +# (the "License"); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +services: + ignite: +image: apacheignite/ignite:2.9.0 Review comment: Changed to :latest This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [RESULT] [VOTE] Release Apache Ignite 2.9.1 (RC1)
Me and mainly Maxim (since I don’t have sufficient permissions) are working on it, there were a couple of mishaps with docs (due to docs were in a separate branch for 2.9) and access rights (bintray in particular) that delayed us but rest assured the release will be available ASAP. Sorry for the inconvenience, guys. > On 24 Dec 2020, at 17:11, Ilya Kasnacheev wrote: > > Hello! > > Where's the release then? Almost a week has passed but it's not available > for download on ignite.apache.org. Neither in Maven. > > Regards, > -- > Ilya Kasnacheev > > > пт, 18 дек. 2020 г. в 22:56, Yaroslav Molochkov : > >> Hello, Igniters! >> >> Apache Ignite 2.9.1 release (RC1) has been accepted. >> >> 6 "+1" votes received. >> >> Here are the votes received (in order received): >> >> - Pavel Tupitsyn (binding) >> - Ilya Kasnacheev (binding) >> - Nikolay Izhikov (binding) >> - Denis Magda (binding) >> - Alex Plehanov (binding) >> - Maxim Muzafarov (binding) >> >> Here is the link to the voting thread - >> >> http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-9-1-RC1-td50653.html >> >> Thank you! >>
[GitHub] [ignite-python-thin-client] isapego commented on a change in pull request #1: IGNITE-13903 Add tox, docker-compose and travis integration, update pytest versions.
isapego commented on a change in pull request #1: URL: https://github.com/apache/ignite-python-thin-client/pull/1#discussion_r548558576 ## File path: docker-compose.yml ## @@ -0,0 +1,34 @@ +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. +# The ASF licenses this file to You under the Apache License, Version 2.0 +# (the "License"); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +services: + ignite: +image: apacheignite/ignite:2.9.0 Review comment: Are we going to change Ignite version here every time new Ignite is released? Can we somehow avoid specifying exact version here? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (IGNITE-13904) Don't use rows buffers by redce index for simple one-way reducer
Taras Ledkov created IGNITE-13904:
-
Summary: Don't use rows buffers by redce index for simple one-way
reducer
Key: IGNITE-13904
URL: https://issues.apache.org/jira/browse/IGNITE-13904
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.9
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.10
Now the reducer's index buffer {{AbstractReducer#fetched}} is used even for
simple plain query. It is the cause of increased memory usage for plain query.
Proposed fix:
- don't use index buffer for simple reducer (for plain query).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [RESULT] [VOTE] Release Apache Ignite 2.9.1 (RC1)
Hello! Where's the release then? Almost a week has passed but it's not available for download on ignite.apache.org. Neither in Maven. Regards, -- Ilya Kasnacheev пт, 18 дек. 2020 г. в 22:56, Yaroslav Molochkov : > Hello, Igniters! > > Apache Ignite 2.9.1 release (RC1) has been accepted. > > 6 "+1" votes received. > > Here are the votes received (in order received): > >- Pavel Tupitsyn (binding) >- Ilya Kasnacheev (binding) >- Nikolay Izhikov (binding) >- Denis Magda (binding) >- Alex Plehanov (binding) >- Maxim Muzafarov (binding) > > Here is the link to the voting thread - > > http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-9-1-RC1-td50653.html > > Thank you! >
[GitHub] [ignite-python-thin-client] ivandasch opened a new pull request #1: IGNITE-13903 Add tox, docker-compose and travis integration, update pytest versions.
ivandasch opened a new pull request #1: URL: https://github.com/apache/ignite-python-thin-client/pull/1 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (IGNITE-13903) Python thin client tests automation.
Ivan Daschinskiy created IGNITE-13903: - Summary: Python thin client tests automation. Key: IGNITE-13903 URL: https://issues.apache.org/jira/browse/IGNITE-13903 Project: Ignite Issue Type: Improvement Components: python Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy It would be nice to futher improve our development process of python-thin-client 1. Add docker-compose.yml to simplify local development 2. Add tox.ini to simplify test running automation 3. Integrate travis-ci build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13902) Add IgniteClient Spring Bean wrapper
Mikhail Petrov created IGNITE-13902: --- Summary: Add IgniteClient Spring Bean wrapper Key: IGNITE-13902 URL: https://issues.apache.org/jira/browse/IGNITE-13902 Project: Ignite Issue Type: Improvement Reporter: Mikhail Petrov It's needed to add IgniteClient wrapper to provide convenient way to start thin client as Spring Bean. The same functionality is already present for the Ignite node - IgniteSpringBean. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Metastorage limitations
Hello. > If we want to make metastore more reliable we should provide some command to > remove keys from it. Ticket [1] to provide this feature created. [1] https://issues.apache.org/jira/browse/IGNITE-13901 > 22 дек. 2020 г., в 17:57, Nikolay Izhikov написал(а): > > Hello, Anton. > > Thanks for the answer! > >> Only maybe, it makes sense to remove such records (with all history) instead >> of filtering them. > > I don’t think we should do this, by default. > > Imagine scenario #1: > > 1. Update the plugin to the next bugged version. Some class that is written > to the metastore is lost. > 2. Remove the key from the metastore to fix current deployment. > 3. Deploy updated plugin > > We will lose plugin information from metastore on step #3. > > If we want to make metastore more reliable we should provide some command to > remove keys from it. > This will fix scenario #2 when we migrate from one Ignite deployment to > another and some keys become unused. > >> 22 дек. 2020 г., в 17:39, Anton Kalashnikov написал(а): >> >>> How it differs from the current implementation? >> There are no differences in implementation. But according to the original >> topic, plugins or other external things can write to metastore their own >> classes. I just said that according to current architecture it is not a good >> idea to do that because these POJO's are not from the core. >> >>> Why do you think that «good» solution should exist for this kind of issue? >> I don't think so. I just emphasize my concern about local filtering(the >> usage of system property) in this solution because it can lead to different >> behavior on different nodes. But perhaps you are right, and for such bug we >> can use a such solution. >> >>> Maybe we should make metastore fully lazy, so any stored key will not be >>> deserialized before it explicitly queried. >> I approximately meant the same. We should think about that. >> >> In conclusion(my opinions): >> >> In the current design, inside of plugins(etc.) it makes sense to use only >> primitives or POJO's from the core. (This is my answer to the original topic) >> It makes sense to think about serialization by demand inside of metastorage >> rather than in the discovery. >> I have no good solution for resolving the bug with removed classes. Perhaps, >> we can use Nikolay's fix. Only maybe, it makes sense to remove such records >> (with all history) instead of filtering them. >> >> -- >> Best regards, >> Anton Kalashnikov >> >> >> >> 22.12.2020, 14:44, "Nikolay Izhikov" : >>> Hello, Anton. >>> or use the POJO from the ignite core. >>> >>> How it differs from the current implementation? >>> As I can see you have tests only for one node but what happens if different nodes have different filters? >>> >>> The error will happen. >>> >>> Please, don’t forget that we are talking about two scenarios: >>> >>> 1. Blocker bug - we delete some class that was written to metastore from >>> the new version. >>> 2. Migration between custom Ignite distributions where one of them has a >>> custom class and the other doesn’t. >>> >>> It’s a very rare incident in my experience. >>> >>> Why do you think that «good» solution should exist for this kind of issue? >>> I don’t think we should limit internal architecture to cover these cases. >>> >>> Maybe we should make metastore fully lazy, so any stored key will not be >>> deserialized before it explicitly queried. >>> 22 дек. 2020 г., в 14:30, Anton Kalashnikov написал(а): Hello everyone, In my opinion, it is indeed better to limit storing to the metastore by primitive type(map or list are also possible) or use the POJO from the ignite core. As Kirill correctly notice, right now, it is a problem not inside of the distributed metastore but inside of discovery. In fact, we can rewrite the sending metastore data in such a way that the discovery would think that there is just a simple byte array which shouldn't be deserialized. Right now, it understands that it is a serialized java object and it tries to deserialize it after receiving it. But this way requires more investigation about possible corner cases. Nikolay, I also don't sure that your fix handles metastorage history correctly. As I can see you have tests only for one node but what happens if different nodes have different filters? or if we need to send history to the joining node but some of the keys don't pass the filter? Maybe I wrong but in the first eye, it can lead to different results/histories on different nodes which is a problem. I just briefly looked at your PR(so maybe I didn't understand something), I will try to do it more carefully at the nearest time. -- Best regards, Anton Kalashnikov 18.12.2020, 15:33, "Mekhanikov Denis" : > Nikolay, > > Thanks
[jira] [Created] (IGNITE-13901) [IEP-39] Management API to remove metastore key.
Nikolay Izhikov created IGNITE-13901: Summary: [IEP-39] Management API to remove metastore key. Key: IGNITE-13901 URL: https://issues.apache.org/jira/browse/IGNITE-13901 Project: Ignite Issue Type: Sub-task Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Fix For: 2.9 Ignite provides many API to deploy and execute user-provided code on the server nodes inside the same JVM as the Ignite process runs. Ignite has many APIs that allocate many resources on the server nodes, also. In case of some buggy code that consumes many system resources(CPU, RAM, flood network) or heavy query the whole cluster can become unstable. We should provide to the cluster administrator the ability to stop any user deployed task. JMX beans to cancel listed tasks should be introduced: * SQL queries. In the scope of IEP-35 System view API introduced. A new API should use the same identifier that is used in corresponding System View. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13900) CPP: Fix test flaky Affinity tests
Igor Sapego created IGNITE-13900: Summary: CPP: Fix test flaky Affinity tests Key: IGNITE-13900 URL: https://issues.apache.org/jira/browse/IGNITE-13900 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.9 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.10 Some CPP affinity tests are flaky on TC. For example, IgniteAffinityMapPartitionsToNodes, IgniteAffinityCall, IgniteAffinityCallAsync. Need to fix them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
