[jira] [Commented] (IGNITE-10538) Make ignite-grid component for handling missing agent and cluster
[ https://issues.apache.org/jira/browse/IGNITE-10538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744750#comment-16744750 ] Alexander Kalinin commented on IGNITE-10538: [~Klaster_1] I've implemented a prototype for no-data component. Please share you thoughts upon current realisation. https://github.com/apache/ignite/pull/5844/files > Make ignite-grid component for handling missing agent and cluster > - > > Key: IGNITE-10538 > URL: https://issues.apache.org/jira/browse/IGNITE-10538 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexander Kalinin >Priority: Major > > Currently we have such an aproach: When agent or cluster is not availibe we > block the whole screen and show a modal window with instructions (like in > Notebooks screen). This approach is a bad UX case as it frustrates user with > blocking and forcing to change state. > We should implement a less obtrusive aproach by showing message in body of > ignite-grid table, allowing user to stay on current state and not blocking > the whole UI. > This component should comply for following requirements: > 1) It sholuld be universal - applicable in context of any ignite-grid table > usage. > 2) Should handle common cases like missing agent or cluster under the hood. > 3) Should have a possibility of enhancing for other special cases in > different components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-10351) Web Console: add new fields of IgniteConfiguration (sysWorkerBlockedTimeout and checkpointReadLockTimeout) to UI configurator
[ https://issues.apache.org/jira/browse/IGNITE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-10351. --- > Web Console: add new fields of IgniteConfiguration (sysWorkerBlockedTimeout > and checkpointReadLockTimeout) to UI configurator > - > > Key: IGNITE-10351 > URL: https://issues.apache.org/jira/browse/IGNITE-10351 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > > We need to add new options to UI configurator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10351) Web Console: add new fields of IgniteConfiguration (sysWorkerBlockedTimeout and checkpointReadLockTimeout) to UI configurator
[ https://issues.apache.org/jira/browse/IGNITE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744676#comment-16744676 ] Pavel Konstantinov commented on IGNITE-10351: - Tested > Web Console: add new fields of IgniteConfiguration (sysWorkerBlockedTimeout > and checkpointReadLockTimeout) to UI configurator > - > > Key: IGNITE-10351 > URL: https://issues.apache.org/jira/browse/IGNITE-10351 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > > We need to add new options to UI configurator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10960) Thin client cannot retrieve data that was inserted with the Thick Ignite client when using a composite key
[
https://issues.apache.org/jira/browse/IGNITE-10960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744662#comment-16744662
]
Roman Shtykh commented on IGNITE-10960:
---
[~mcherkas] Thanks for filing the issue. I have digged deeper and found that
that was the issue with compactFooter:
Not having {{.setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true))}} or just
{{.setBinaryConfiguration(new BinaryConfiguration()}} results at using the full
schema approach, while {{DFLT_COMPACT_FOOTER = true}} is supposed to be default
(as I understand).
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key
> --
>
> Key: IGNITE-10960
> URL: https://issues.apache.org/jira/browse/IGNITE-10960
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Mikhail Cherkasov
>Assignee: Roman Shtykh
>Priority: Blocker
> Attachments: ThinClientGets.java
>
>
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key.
>
> See the attached reproducer:
> ThinClientGets.java
>
> thickCache.put(new TestKey("a", "0"), 1);
> thickCache.get(new TestKey("a", "0")); // returns 1
> thinCache.get(new TestKey("a", "0")) // returns null
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10960) Thin client cannot retrieve data that was inserted with the Thick Ignite client when using a composite key
[
https://issues.apache.org/jira/browse/IGNITE-10960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shtykh reassigned IGNITE-10960:
-
Assignee: Roman Shtykh
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key
> --
>
> Key: IGNITE-10960
> URL: https://issues.apache.org/jira/browse/IGNITE-10960
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Mikhail Cherkasov
>Assignee: Roman Shtykh
>Priority: Blocker
> Attachments: ThinClientGets.java
>
>
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key.
>
> See the attached reproducer:
> ThinClientGets.java
>
> thickCache.put(new TestKey("a", "0"), 1);
> thickCache.get(new TestKey("a", "0")); // returns 1
> thinCache.get(new TestKey("a", "0")) // returns null
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[
https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov closed IGNITE-9845.
--
Ignite Flags: (was: Docs Required)
> Web Console: Add support of two way ssl authentication in Web Console agent
> ---
>
> Key: IGNITE-9845
> URL: https://issues.apache.org/jira/browse/IGNITE-9845
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Affects Versions: 2.6
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Selection_274.png, generate.bat, generate.sh,
> jetty-with-ssl.xml, ssl.pdf
>
>
> RestExecutor should not be shared between different users requests in case of
> two way ssl authentication:
> * For each token with ssl we need create separated RestExecutor and set up
> socketFactory and trustManager.
> * RestExecutor should be removed if token expired.
> Add program arguments for passing client certificate, client password, trust
> store, trust store password for ignite node connection and web console
> backend.
> Example on okhttp:
> [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]
> Upgrade socket-io from 1.x to 2.x.
> Add support for SSL cipher suites
> Add tests.
> ---
> *How to do local testing:*
> On Windows
> # Download Open SSL: Download Open SSL for Windows from
> [https://wiki.openssl.org/index.php/Binaries]
> # Unpack it.
> On Linux - it is usually built-in.
> Generate keys with provided script (see attached generate.bat, it could be
> easily adapted for Linux).
>
> Add to etc/hosts:
> 127.0.0.1 localhost console.test.local
>
> After that configure SSL for:
> # Web Console back-end.
> # Web Agent.
> # Cluster.
> *Configure Web Console back-end settings:*
> "ssl": true,
> "key": "some_path/server.key",
> "cert": "some_path/server.crt",
> "ca": "some_path/ca.crt",
> "keyPassphrase": "p123456",
> *Configure Web Agent parameters (see parameters descriptions):*
> -t your_token
> -s [https://console.test.local:3000|https://console.test.local:3000/] -n
> [https://console.test.local:11443|https://console.test.local:11443/]
> -nks client.jks -nkp p123456
> -nts ca.jks -ntp p123456
> -sks client.jks -skp p123456
> -sts ca.jks -stp p123456
> *Configure cluster JETTY config (see FULL config attached):*
>
> https
> default="11443"/>
> true
> true
> class="org.eclipse.jetty.server.SecureRequestCustomizer"/>
>
> class="org.eclipse.jetty.util.ssl.SslContextFactory">
> some_path/server.jks
> p123456
> some_path/ca.jks
> p123456
> true
>
> *How to start secure web console in direct install edition in Ubuntu:*
> # Download ignite web console direct install for linux ZIP archive .
> # Unpack downloaded archive to goal folder.
> # Generate SSL certificates.
> # Copy generated certificates to folder with unpacked web console direct
> install.
> # Open terminal and navigate to folder with unpacked web console direct
> install.
> # Run web console with the next command:
> {code:java}
> ignite-web-console-linux --server:port 11443 --server:ssl true
> --server:requestCert true --server:key "server.key" --server:cert
> "server.crt" --server:ca "ca.crt" --server:passphrase "p123456"{code}
> 7. Import client.p12 certificate into your browser. See attached
> screenstot in Chrome browser.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[
https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov updated IGNITE-9845:
---
Ignite Flags: Docs Required
> Web Console: Add support of two way ssl authentication in Web Console agent
> ---
>
> Key: IGNITE-9845
> URL: https://issues.apache.org/jira/browse/IGNITE-9845
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Affects Versions: 2.6
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Selection_274.png, generate.bat, generate.sh,
> jetty-with-ssl.xml, ssl.pdf
>
>
> RestExecutor should not be shared between different users requests in case of
> two way ssl authentication:
> * For each token with ssl we need create separated RestExecutor and set up
> socketFactory and trustManager.
> * RestExecutor should be removed if token expired.
> Add program arguments for passing client certificate, client password, trust
> store, trust store password for ignite node connection and web console
> backend.
> Example on okhttp:
> [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]
> Upgrade socket-io from 1.x to 2.x.
> Add support for SSL cipher suites
> Add tests.
> ---
> *How to do local testing:*
> On Windows
> # Download Open SSL: Download Open SSL for Windows from
> [https://wiki.openssl.org/index.php/Binaries]
> # Unpack it.
> On Linux - it is usually built-in.
> Generate keys with provided script (see attached generate.bat, it could be
> easily adapted for Linux).
>
> Add to etc/hosts:
> 127.0.0.1 localhost console.test.local
>
> After that configure SSL for:
> # Web Console back-end.
> # Web Agent.
> # Cluster.
> *Configure Web Console back-end settings:*
> "ssl": true,
> "key": "some_path/server.key",
> "cert": "some_path/server.crt",
> "ca": "some_path/ca.crt",
> "keyPassphrase": "p123456",
> *Configure Web Agent parameters (see parameters descriptions):*
> -t your_token
> -s [https://console.test.local:3000|https://console.test.local:3000/] -n
> [https://console.test.local:11443|https://console.test.local:11443/]
> -nks client.jks -nkp p123456
> -nts ca.jks -ntp p123456
> -sks client.jks -skp p123456
> -sts ca.jks -stp p123456
> *Configure cluster JETTY config (see FULL config attached):*
>
> https
> default="11443"/>
> true
> true
> class="org.eclipse.jetty.server.SecureRequestCustomizer"/>
>
> class="org.eclipse.jetty.util.ssl.SslContextFactory">
> some_path/server.jks
> p123456
> some_path/ca.jks
> p123456
> true
>
> *How to start secure web console in direct install edition in Ubuntu:*
> # Download ignite web console direct install for linux ZIP archive .
> # Unpack downloaded archive to goal folder.
> # Generate SSL certificates.
> # Copy generated certificates to folder with unpacked web console direct
> install.
> # Open terminal and navigate to folder with unpacked web console direct
> install.
> # Run web console with the next command:
> {code:java}
> ignite-web-console-linux --server:port 11443 --server:ssl true
> --server:requestCert true --server:key "server.key" --server:cert
> "server.crt" --server:ca "ca.crt" --server:passphrase "p123456"{code}
> 7. Import client.p12 certificate into your browser. See attached
> screenstot in Chrome browser.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[
https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744650#comment-16744650
]
Pavel Konstantinov commented on IGNITE-9845:
Successfully tested.
> Web Console: Add support of two way ssl authentication in Web Console agent
> ---
>
> Key: IGNITE-9845
> URL: https://issues.apache.org/jira/browse/IGNITE-9845
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Affects Versions: 2.6
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Selection_274.png, generate.bat, generate.sh,
> jetty-with-ssl.xml, ssl.pdf
>
>
> RestExecutor should not be shared between different users requests in case of
> two way ssl authentication:
> * For each token with ssl we need create separated RestExecutor and set up
> socketFactory and trustManager.
> * RestExecutor should be removed if token expired.
> Add program arguments for passing client certificate, client password, trust
> store, trust store password for ignite node connection and web console
> backend.
> Example on okhttp:
> [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]
> Upgrade socket-io from 1.x to 2.x.
> Add support for SSL cipher suites
> Add tests.
> ---
> *How to do local testing:*
> On Windows
> # Download Open SSL: Download Open SSL for Windows from
> [https://wiki.openssl.org/index.php/Binaries]
> # Unpack it.
> On Linux - it is usually built-in.
> Generate keys with provided script (see attached generate.bat, it could be
> easily adapted for Linux).
>
> Add to etc/hosts:
> 127.0.0.1 localhost console.test.local
>
> After that configure SSL for:
> # Web Console back-end.
> # Web Agent.
> # Cluster.
> *Configure Web Console back-end settings:*
> "ssl": true,
> "key": "some_path/server.key",
> "cert": "some_path/server.crt",
> "ca": "some_path/ca.crt",
> "keyPassphrase": "p123456",
> *Configure Web Agent parameters (see parameters descriptions):*
> -t your_token
> -s [https://console.test.local:3000|https://console.test.local:3000/] -n
> [https://console.test.local:11443|https://console.test.local:11443/]
> -nks client.jks -nkp p123456
> -nts ca.jks -ntp p123456
> -sks client.jks -skp p123456
> -sts ca.jks -stp p123456
> *Configure cluster JETTY config (see FULL config attached):*
>
> https
> default="11443"/>
> true
> true
> class="org.eclipse.jetty.server.SecureRequestCustomizer"/>
>
> class="org.eclipse.jetty.util.ssl.SslContextFactory">
> some_path/server.jks
> p123456
> some_path/ca.jks
> p123456
> true
>
> *How to start secure web console in direct install edition in Ubuntu:*
> # Download ignite web console direct install for linux ZIP archive .
> # Unpack downloaded archive to goal folder.
> # Generate SSL certificates.
> # Copy generated certificates to folder with unpacked web console direct
> install.
> # Open terminal and navigate to folder with unpacked web console direct
> install.
> # Run web console with the next command:
> {code:java}
> ignite-web-console-linux --server:port 11443 --server:ssl true
> --server:requestCert true --server:key "server.key" --server:cert
> "server.crt" --server:ca "ca.crt" --server:passphrase "p123456"{code}
> 7. Import client.p12 certificate into your browser. See attached
> screenstot in Chrome browser.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10961) Web console: add more countries
[ https://issues.apache.org/jira/browse/IGNITE-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-10961: - Assignee: Alexey Kuznetsov (was: Ilya Borisov) > Web console: add more countries > --- > > Key: IGNITE-10961 > URL: https://issues.apache.org/jira/browse/IGNITE-10961 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Countries to add: > * Taiwan > * Hong Kong > * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10961) Web console: add more countries
[ https://issues.apache.org/jira/browse/IGNITE-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-10961: - Assignee: Alexey Kuznetsov (was: Ilya Borisov) > Web console: add more countries > --- > > Key: IGNITE-10961 > URL: https://issues.apache.org/jira/browse/IGNITE-10961 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Countries to add: > * Taiwan > * Hong Kong > * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10961) Web console: add more countries
[ https://issues.apache.org/jira/browse/IGNITE-10961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-10961: - Assignee: Ilya Borisov (was: Alexey Kuznetsov) > Web console: add more countries > --- > > Key: IGNITE-10961 > URL: https://issues.apache.org/jira/browse/IGNITE-10961 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Countries to add: > * Taiwan > * Hong Kong > * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10961) Web console: add more countries
Ilya Borisov created IGNITE-10961: - Summary: Web console: add more countries Key: IGNITE-10961 URL: https://issues.apache.org/jira/browse/IGNITE-10961 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Countries to add: * Taiwan * Hong Kong * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8532) [ML] GA Grid: Implement Roulette Wheel Selection
[ https://issues.apache.org/jira/browse/IGNITE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744547#comment-16744547 ] Turik Campbell edited comment on IGNITE-8532 at 1/17/19 12:10 AM: -- Please review. NOTE: I will update Genetic Algorithm section in https://apacheignite.readme.io/v2.8/docs when they become available. was (Author: netmille): Please review. > [ML] GA Grid: Implement Roulette Wheel Selection > > > Key: IGNITE-8532 > URL: https://issues.apache.org/jira/browse/IGNITE-8532 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Turik Campbell >Assignee: Yury Babak >Priority: Minor > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Roulette Wheel Selection Method is a type of selection used for selecting > potentially useful solutions for recombination. This selection method gives > more chances of selection to the better performing chromosomes. > IE: > https://en.wikipedia.org/wiki/Fitness_proportionate_selection -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8532) [ML] GA Grid: Implement Roulette Wheel Selection
[ https://issues.apache.org/jira/browse/IGNITE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Turik Campbell reassigned IGNITE-8532: -- Assignee: Yury Babak (was: Turik Campbell) > [ML] GA Grid: Implement Roulette Wheel Selection > > > Key: IGNITE-8532 > URL: https://issues.apache.org/jira/browse/IGNITE-8532 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Turik Campbell >Assignee: Yury Babak >Priority: Minor > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Roulette Wheel Selection Method is a type of selection used for selecting > potentially useful solutions for recombination. This selection method gives > more chances of selection to the better performing chromosomes. > IE: > https://en.wikipedia.org/wiki/Fitness_proportionate_selection -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8573) Save baseline auto-adjust parameters to metastore
[ https://issues.apache.org/jira/browse/IGNITE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8573: --- Fix Version/s: 2.8 > Save baseline auto-adjust parameters to metastore > - > > Key: IGNITE-8573 > URL: https://issues.apache.org/jira/browse/IGNITE-8573 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We would introduce at IGNITE-8571 new parameters. They should be saved in the > metastore and restored from it on node/cluster restart. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10640) Create cluster-wide MetaStorage analogue
[ https://issues.apache.org/jira/browse/IGNITE-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-10640: Fix Version/s: 2.8 > Create cluster-wide MetaStorage analogue > > > Key: IGNITE-10640 > URL: https://issues.apache.org/jira/browse/IGNITE-10640 > Project: Ignite > Issue Type: New Feature >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > > Issues like IGNITE-8571 require the ability to store and update some > properties consistently on the whole cluster. It is proposed to implement > generic way of doing this. Main requirements are: > * read / write / delete; > * surviving node / cluster restart; > * consistency; > * ability to add listeners on changing properties. > First implementation is going to be based on local MetaStorage to guarantee > data persistence. Existing MetaStorage API is a subject to change as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10640) Create cluster-wide MetaStorage analogue
[ https://issues.apache.org/jira/browse/IGNITE-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744482#comment-16744482 ] Dmitriy Govorukhin commented on IGNITE-10640: - [~ibessonov] Thanks for the contribution, changes merged to master. > Create cluster-wide MetaStorage analogue > > > Key: IGNITE-10640 > URL: https://issues.apache.org/jira/browse/IGNITE-10640 > Project: Ignite > Issue Type: New Feature >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > > Issues like IGNITE-8571 require the ability to store and update some > properties consistently on the whole cluster. It is proposed to implement > generic way of doing this. Main requirements are: > * read / write / delete; > * surviving node / cluster restart; > * consistency; > * ability to add listeners on changing properties. > First implementation is going to be based on local MetaStorage to guarantee > data persistence. Existing MetaStorage API is a subject to change as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10451) .NET: Persistence does not work with custom affinity function
[
https://issues.apache.org/jira/browse/IGNITE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744418#comment-16744418
]
Pavel Tupitsyn commented on IGNITE-10451:
-
[~rpwilson] likely yes.
> .NET: Persistence does not work with custom affinity function
> -
>
> Key: IGNITE-10451
> URL: https://issues.apache.org/jira/browse/IGNITE-10451
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> To reproduce: assign custom affinity function in
> {{PersistenceTest.TestCacheDataSurvivesNodeRestart}}.
> As a result, node restart fails with the following exception:
> {code}
> Apache.Ignite.Core.Common.IgniteException : An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.IgniteException: An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1027)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:48)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: An error occurred
> during cache configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:902)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:844)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:891)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.restoreCacheConfigurations(GridCacheProcessor.java:756)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1300(GridCacheProcessor.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5456)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:412)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:724)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4473)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1047)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> ... 1 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object with given class loader:
> sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:898)
> ... 15 more
> Caused by: java.lang.IllegalArgumentException: Ignite instance name thread
> local must be set or this method should be accessed under
> org.apache.ignite.thread.IgniteThread
> at
> org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1413)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.threadLocalContext(GridBinaryMarshaller.java:398)
> at
>
[jira] [Commented] (IGNITE-10590) IgnitePersistentStoreCacheGroupsTest.testExpiryPolicy is flaky
[
https://issues.apache.org/jira/browse/IGNITE-10590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744403#comment-16744403
]
Ignite TC Bot commented on IGNITE-10590:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2813879buildTypeId=IgniteTests24Java8_RunAll]
> IgnitePersistentStoreCacheGroupsTest.testExpiryPolicy is flaky
> --
>
> Key: IGNITE-10590
> URL: https://issues.apache.org/jira/browse/IGNITE-10590
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes `expireTime` resets to 0 after node restart.
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4867852032903128088=testDetails_IgniteTests24Java8=
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10960) Thin client cannot retrieve data that was inserted with the Thick Ignite client when using a composite key
Mikhail Cherkasov created IGNITE-10960:
--
Summary: Thin client cannot retrieve data that was inserted with
the Thick Ignite client when using a composite key
Key: IGNITE-10960
URL: https://issues.apache.org/jira/browse/IGNITE-10960
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Mikhail Cherkasov
Attachments: ThinClientGets.java
Thin client cannot retrieve data that was inserted with the Thick Ignite client
when using a composite key.
See the attached reproducer:
ThinClientGets.java
thickCache.put(new TestKey("a", "0"), 1);
thickCache.get(new TestKey("a", "0")); // returns 1
thinCache.get(new TestKey("a", "0")) // returns null
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10852) [Documentation] - Add details on to public API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-10852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744347#comment-16744347 ] Prachi Garg commented on IGNITE-10852: -- Released the page - https://apacheignite.readme.io/v2.7/docs/exception-handling > [Documentation] - Add details on to public API behaviour > > > Key: IGNITE-10852 > URL: https://issues.apache.org/jira/browse/IGNITE-10852 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.4, 2.5, 2.6, 2.7 >Reporter: Alexander Gerus >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > Current public API documentation has some specification gaps. In case if > method was not successfully executed, it is not clear what should be done by > user code. > Good practice is to describe all API exceptions that can be processed by user > code and recommended actions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10852) [Documentation] - Add details on to public API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-10852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg resolved IGNITE-10852. -- Resolution: Fixed > [Documentation] - Add details on to public API behaviour > > > Key: IGNITE-10852 > URL: https://issues.apache.org/jira/browse/IGNITE-10852 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.4, 2.5, 2.6, 2.7 >Reporter: Alexander Gerus >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > Current public API documentation has some specification gaps. In case if > method was not successfully executed, it is not clear what should be done by > user code. > Good practice is to describe all API exceptions that can be processed by user > code and recommended actions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-10852) [Documentation] - Add details on to public API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-10852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg closed IGNITE-10852. > [Documentation] - Add details on to public API behaviour > > > Key: IGNITE-10852 > URL: https://issues.apache.org/jira/browse/IGNITE-10852 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.4, 2.5, 2.6, 2.7 >Reporter: Alexander Gerus >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > Current public API documentation has some specification gaps. In case if > method was not successfully executed, it is not clear what should be done by > user code. > Good practice is to describe all API exceptions that can be processed by user > code and recommended actions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10954) MVCC: Umute fixed tests.
[
https://issues.apache.org/jira/browse/IGNITE-10954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744276#comment-16744276
]
Ignite TC Bot commented on IGNITE-10954:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2816086]]
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithTxTwoNodesOneBackup - 0,0%
fails in last 555 master runs.
{color:#d04437}Cache (Restarts) 2{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2816087]]
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutTenNodesTwoBackups
- 0,0% fails in last 603 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups
- 0,0% fails in last 603 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxPutAllTenNodesTwoBackups
- 0,0% fails in last 603 master runs.
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2816090]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2816127buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Umute fixed tests.
>
>
> Key: IGNITE-10954
> URL: https://issues.apache.org/jira/browse/IGNITE-10954
> Project: Ignite
> Issue Type: Test
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Check if next tests passes on TC and unmute them,
> otherwise re-mute with correct ticket.
> IgnitePdsDataRegionMetricsTest.testUsedCheckpointBuffer
> TxRollbackAsyncWithPersistenceTest.testSynchronousRollback
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10959) Memory leaks in continuous query handlers
Denis Mekhanikov created IGNITE-10959: - Summary: Memory leaks in continuous query handlers Key: IGNITE-10959 URL: https://issues.apache.org/jira/browse/IGNITE-10959 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Fix For: 2.8 Attachments: CacheContinuousQueryMemoryUsageTest.java Continuous query handlers don't clear internal data structures after cache events are processed. A test, that reproduces the problem, is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-2907) GridServiceNotFoundException is not descriptive
[ https://issues.apache.org/jira/browse/IGNITE-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-2907: -- Assignee: (was: Vyacheslav Daradur) > GridServiceNotFoundException is not descriptive > --- > > Key: IGNITE-2907 > URL: https://issues.apache.org/jira/browse/IGNITE-2907 > Project: Ignite > Issue Type: Bug > Components: managed services >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Priority: Minor > > "Service node found" message does not make sense. > * Message should be fixed > * More details should be added (why is this situation possible, how to fix it) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-10958: -- Description: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the Maven surefire plugin to make it work with JUnit 5 [1]. Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180. [1] [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html] was: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the Maven surefire plugin to make it work with JUnit 5. Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180. [1] [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html] > Migrate from Junit 4 to 5 > - > > Key: IGNITE-10958 > URL: https://issues.apache.org/jira/browse/IGNITE-10958 > Project: Ignite > Issue Type: Task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Starting with maven-surefire-plugin version 2.22.0 there is full support for > JUnit 5 [1]. > Migration to the JUnit 5 includes multiple steps: > 1. adding new JUnit dependencies to pom files. By artifactId: > junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, > junit-platform-runner > 2. Replace all imports of old JUnit annotations by the newest: from > org.junit.Test to org.junit.jupiter.api.Test > 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore > 4. Replace concept rules by extension model where it is necessary: > ExpectedException to assertThrows > 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension > 6. Update the Maven surefire plugin to make it work with JUnit 5 [1]. > Investigation about migration to JUnit5 is provided in the ticket > IGNITE-10180. > [1] > [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-10958: -- Description: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the Maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html was: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html > Migrate from Junit 4 to 5 > - > > Key: IGNITE-10958 > URL: https://issues.apache.org/jira/browse/IGNITE-10958 > Project: Ignite > Issue Type: Task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Starting with maven-surefire-plugin version 2.22.0 there is full support for > JUnit 5 [1]. > Migration to the JUnit 5 includes multiple steps: > 1. adding new JUnit dependencies to pom files. By artifactId: > junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, > junit-platform-runner > 2. Replace all imports of old JUnit annotations by the newest: from > org.junit.Test to org.junit.jupiter.api.Test > 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore > 4. Replace concept rules by extension model where it is necessary: > ExpectedException to assertThrows > 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension > 6. Update the Maven surefire plugin to make it works with JUnit 5. > Investigation about migration to JUnit5 is provided in the ticket > IGNITE-10180. > [1] > https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache
[
https://issues.apache.org/jira/browse/IGNITE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-9739:
Fix Version/s: 2.8
> Critical exception in transaction processing in case we have nodes out of
> baseline and non-persisted cache
> --
>
> Key: IGNITE-9739
> URL: https://issues.apache.org/jira/browse/IGNITE-9739
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.8
>
>
> Activation finished
> {code:java}
> 2018-09-20 20:47:05.169 [INFO
> ][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Successfully performed final activation steps
> [nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
> {code}
> but we have nodes not in base line
> {code:java}
> 2018-09-20 20:45:36.116 [INFO
> ][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Local node is not included in Baseline Topology and will not be used for
> persistent data storage. Use control.(sh|bat) script or IgniteCluster
> interface to include the node to Baseline Topology.
> {code}
> And we have cache (869481129) in the data region with persistanceEnabled=false
> {code:java}
> 2018-09-20 20:49:01.825 [INFO
> ][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
> Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
> STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted,
> mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
> {code}
> Transaction on this cache(869481129)
> {code:java}
> 869481129{code}
> leads to critical error causing nodes by faulure handler:
> {code:java}
> 2018-09-20 20:50:24.275
> [ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235,
> msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774,
> futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821,
> nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC,
> isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365,
> order=1537511036824, nodeOrder=7], timeout=299970, reads=null,
> writes=ArrayList [
> IgniteTxEntry [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*], val=[op=CREATE,
> val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple
> [idHash=811765531, hash=1522508040,
> cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList
> {com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1583970836, hash=363194492, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList
> \{isDeleted},moduleName=union-module
> , cachedUnselectives=1, selectors=ArrayList {isDeleted},
> exceptUnselectives=false, primitiveCollection=false, isVersioned=false,
> isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false,
> isGlobal=false, maxSelective=1000],
> com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=2060926101, hash=1983794578, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList ,moduleName=union-module,
> cachedUnselectives=1, selectors=ArrayList, exceptUnselectives=false,
> primitiveCollection=false, isVersioned=false, isComposite=false,
> isSystemTypeBelongs=false, name=com.sbt.gbk.entities.DocType_DPL_code,
> isIndexedCollection=false, isGlobal=true, maxSelective=1000]
> , com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1821682714, hash=-1245813786, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList {globalId},
> moduleName=union-module, cachedUnselectives=1, selectors=ArrayList
> {globalId}, exceptUnselectives=false, primitiveCollection=false,
> isVersioned=false, isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_globalId, isIndexedCollection=false,
>
[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10958: Description: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the Maven surefire plugin to make it work with JUnit 5. Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180. [1] [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html] was: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the Maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html > Migrate from Junit 4 to 5 > - > > Key: IGNITE-10958 > URL: https://issues.apache.org/jira/browse/IGNITE-10958 > Project: Ignite > Issue Type: Task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Starting with maven-surefire-plugin version 2.22.0 there is full support for > JUnit 5 [1]. > Migration to the JUnit 5 includes multiple steps: > 1. adding new JUnit dependencies to pom files. By artifactId: > junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, > junit-platform-runner > 2. Replace all imports of old JUnit annotations by the newest: from > org.junit.Test to org.junit.jupiter.api.Test > 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore > 4. Replace concept rules by extension model where it is necessary: > ExpectedException to assertThrows > 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension > 6. Update the Maven surefire plugin to make it work with JUnit 5. > Investigation about migration to JUnit5 is provided in the ticket > IGNITE-10180. > [1] > [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-10958: -- Description: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html was: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 was in ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html > Migrate from Junit 4 to 5 > - > > Key: IGNITE-10958 > URL: https://issues.apache.org/jira/browse/IGNITE-10958 > Project: Ignite > Issue Type: Task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Starting with maven-surefire-plugin version 2.22.0 there is full support for > JUnit 5 [1]. > Migration to the JUnit 5 includes multiple steps: > 1. adding new JUnit dependencies to pom files. By artifactId: > junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, > junit-platform-runner > 2. Replace all imports of old JUnit annotations by the newest: from > org.junit.Test to org.junit.jupiter.api.Test > 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore > 4. Replace concept rules by extension model where it is necessary: > ExpectedException to assertThrows > 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension > 6. Update the maven surefire plugin to make it works with JUnit 5. > Investigation about migration to JUnit5 is provided in the ticket > IGNITE-10180. > [1] > https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-10958: -- Description: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 was in ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html was: Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 was in ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html > Migrate from Junit 4 to 5 > - > > Key: IGNITE-10958 > URL: https://issues.apache.org/jira/browse/IGNITE-10958 > Project: Ignite > Issue Type: Task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Starting with maven-surefire-plugin version 2.22.0 there is full support for > JUnit 5 [1]. > Migration to the JUnit 5 includes multiple steps: > 1. adding new JUnit dependencies to pom files. By artifactId: > junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, > junit-platform-runner > 2. Replace all imports of old JUnit annotations by the newest: from > org.junit.Test to org.junit.jupiter.api.Test > 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore > 4. Replace concept rules by extension model where it is necessary: > ExpectedException to assertThrows > 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension > 6. Update the maven surefire plugin to make it works with JUnit 5. > Investigation about migration to JUnit5 was in ticket IGNITE-10180. > [1] > https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10958) Migrate from Junit 4 to 5
Ivan Fedotov created IGNITE-10958: - Summary: Migrate from Junit 4 to 5 Key: IGNITE-10958 URL: https://issues.apache.org/jira/browse/IGNITE-10958 Project: Ignite Issue Type: Task Reporter: Ivan Fedotov Assignee: Ivan Fedotov Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 was in ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10629) Migration follow up: check for old style tests that could be slipped through in transition period
[
https://issues.apache.org/jira/browse/IGNITE-10629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16715885#comment-16715885
]
Oleg Ignatenko edited comment on IGNITE-10629 at 1/16/19 3:37 PM:
--
(i) draft inspections profile attached: [^junit_inspections.xml]
(i) appropriate cut-off date appears to be 22/Dec/18 when IGNITE-10177 was
marked resolved (merged to master). After changes made to master per this
ticket it became impossible to have working test inheriting
[GridAbstractTest|https://github.com/apache/ignite/commits/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java]
other than using JUnit 4 (JUnit 3 kind tests wouldn't execute and IDEA would
highlight respective test cases with warnings about unused methods)
was (Author: oignatenko):
(i) draft inspections profile attached: [^junit_inspections.xml]
> Migration follow up: check for old style tests that could be slipped through
> in transition period
> -
>
> Key: IGNITE-10629
> URL: https://issues.apache.org/jira/browse/IGNITE-10629
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: junit_inspections.xml
>
>
> We need to account for risk that while tests are migrating some commits may
> by mistake slip in old style test cases - that will be ignored by JUnit 4.
> In order to address possible issues of that kind, do the following a week or
> two after IGNITE-10177 is merged to master: run the IntelliJ inspection
> called "old style Junit test method in JUnit 4 class", review report and fix
> discovered problems if there are any.
> For the reference, my version of IDE explains this inspection as follows:
> {quote}Reports JUnit 3 style test methods which are located inside a class
> which does not extend the abstract JUnit 3 class TestCase and contains JUnit
> 4/JUnit 5 @Test annotated methods.{quote}
> (note concerns mentioned in this ticket were originally raised at dev list:
> [here|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-tp29608p39300.html])
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10487) SQL: Make sure that partition pruning is integrated with DML properly
[ https://issues.apache.org/jira/browse/IGNITE-10487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744146#comment-16744146 ] Taras Ledkov commented on IGNITE-10487: --- [~vozerov], please review the new tests. > SQL: Make sure that partition pruning is integrated with DML properly > - > > Key: IGNITE-10487 > URL: https://issues.apache.org/jira/browse/IGNITE-10487 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov >Priority: Major > Labels: iep-24 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > DML re-use query execution logic for UPDATE and DELETE statements. Need to > make sure that provided partition information is used properly in those > queries for standard and MVCC modes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10927:
Description:
{{JUnit3TestLegacySupport}} currently inherits deprecated
{{junit.framework.Assert}}. This was done only in order to minimize risky code
changes when tests were migrating from Junit 3, after {{GridAbstractTest}} has
dropped inheriting {{junit.framework.TestCase}}.
Now that migration is over it is less risky to cleanup project from deprecated
assert methods and drop the harmful inheritance. In order to make this smoother
and minimize amount of test changes, after inheritance is dropped,
{{JUnit3TestLegacySupport}} should be extended with a set of "temporary patch"
methods that would delegate most popular assertions used by subclasses to
respective methods of {{org.junit.Assert}}.
Mentioned temporary patch methods, in turn, should get {{@Deprecated}}
annotation and respective {{2deprecation}} noticed in javadocs that would
encourage developers to (safely and gradually) change them to direct
invocations and static imports of respective Assert methods instead of using
those inherited from superclass. These patch methods should be declared
{{protected final}} or {{protected static}}, in order to minimize their
applicability and prevent them spreading more than intended.
was:
{{JUnit3TestLegacySupport}} currently inherits deprecated
{{junit.framework.Assert}}. This was done only in order to minimize risky code
changes when tests were migrating from Junit 3, after {{GridAbstractTest}} has
dropped inheriting {{junit.framework.TestCase}}.
Now that migration is over it is less risky to cleanup project from deprecated
assert methods and drop the harmful inheritance. In order to make this smoother
and minimize amount of test changes, after inheritance is dropped,
{{JUnit3TestLegacySupport}} should be extended with a set of "temporary patch"
methods that would delegate most popular assertions used by subclasses to
respective methods of {{org.junit.Assert}}.
Mentioned temporary patch methods, in turn, should get {{@Deprecated}}
annotation and respective {{2deprecation}} noticed in javadocs that would
encourage developers to (safely and gradually) change them to direct
invocations and static imports of respective Assert methods instead of using
those inherited from superclass. These patch methods should be declared
protected final or protected static final, to minimize their applicability and
prevent them spreading more than intended.
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should get {{@Deprecated}}
> annotation and respective {{2deprecation}} noticed in javadocs that would
> encourage developers to (safely and gradually) change them to direct
> invocations and static imports of respective Assert methods instead of using
> those inherited from superclass. These patch methods should be declared
> {{protected final}} or {{protected static}}, in order to minimize their
> applicability and prevent them spreading more than intended.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache
[
https://issues.apache.org/jira/browse/IGNITE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744107#comment-16744107
]
Ignite TC Bot commented on IGNITE-9739:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2814354buildTypeId=IgniteTests24Java8_RunAll]
> Critical exception in transaction processing in case we have nodes out of
> baseline and non-persisted cache
> --
>
> Key: IGNITE-9739
> URL: https://issues.apache.org/jira/browse/IGNITE-9739
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
>
> Activation finished
> {code:java}
> 2018-09-20 20:47:05.169 [INFO
> ][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Successfully performed final activation steps
> [nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
> {code}
> but we have nodes not in base line
> {code:java}
> 2018-09-20 20:45:36.116 [INFO
> ][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Local node is not included in Baseline Topology and will not be used for
> persistent data storage. Use control.(sh|bat) script or IgniteCluster
> interface to include the node to Baseline Topology.
> {code}
> And we have cache (869481129) in the data region with persistanceEnabled=false
> {code:java}
> 2018-09-20 20:49:01.825 [INFO
> ][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
> Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
> STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted,
> mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
> {code}
> Transaction on this cache(869481129)
> {code:java}
> 869481129{code}
> leads to critical error causing nodes by faulure handler:
> {code:java}
> 2018-09-20 20:50:24.275
> [ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235,
> msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774,
> futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821,
> nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC,
> isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365,
> order=1537511036824, nodeOrder=7], timeout=299970, reads=null,
> writes=ArrayList [
> IgniteTxEntry [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*], val=[op=CREATE,
> val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple
> [idHash=811765531, hash=1522508040,
> cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList
> {com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1583970836, hash=363194492, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList
> \{isDeleted},moduleName=union-module
> , cachedUnselectives=1, selectors=ArrayList {isDeleted},
> exceptUnselectives=false, primitiveCollection=false, isVersioned=false,
> isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false,
> isGlobal=false, maxSelective=1000],
> com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=2060926101, hash=1983794578, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList ,moduleName=union-module,
> cachedUnselectives=1, selectors=ArrayList, exceptUnselectives=false,
> primitiveCollection=false, isVersioned=false, isComposite=false,
> isSystemTypeBelongs=false, name=com.sbt.gbk.entities.DocType_DPL_code,
> isIndexedCollection=false, isGlobal=true, maxSelective=1000]
> , com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1821682714, hash=-1245813786, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList {globalId},
> moduleName=union-module, cachedUnselectives=1,
[jira] [Updated] (IGNITE-5234) JDBC thin driver: support connection timeout
[ https://issues.apache.org/jira/browse/IGNITE-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5234: Fix Version/s: 2.8 > JDBC thin driver: support connection timeout > > > Key: IGNITE-5234 > URL: https://issues.apache.org/jira/browse/IGNITE-5234 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Alexander Lapin >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10476) Merge similar tests.
[ https://issues.apache.org/jira/browse/IGNITE-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kalinin reassigned IGNITE-10476: --- Assignee: Andrey Kalinin > Merge similar tests. > > > Key: IGNITE-10476 > URL: https://issues.apache.org/jira/browse/IGNITE-10476 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Assignee: Andrey Kalinin >Priority: Minor > Labels: MakeTeamcityGreenAgain > > CacheNamesSelfTest and CacheNamesWithSpecialCharactersTest looks similar and > can be merged. > We already have test suite these tests are related to, so we can merge them > into GridCacheConfigurationValidationSelfTest. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5438) JDBC thin: support query timeout
[
https://issues.apache.org/jira/browse/IGNITE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5438:
Fix Version/s: 2.8
> JDBC thin: support query timeout
>
>
> Key: IGNITE-5438
> URL: https://issues.apache.org/jira/browse/IGNITE-5438
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{setQueryTimeout}} method of JDBC {{Statement}} must be supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10957) Reduce EnsuredMessageHistory heap occupation
Alexei Scherbakov created IGNITE-10957: -- Summary: Reduce EnsuredMessageHistory heap occupation Key: IGNITE-10957 URL: https://issues.apache.org/jira/browse/IGNITE-10957 Project: Ignite Issue Type: Improvement Reporter: Alexei Scherbakov Fix For: 2.8 EnsuredMessageHistory can hold up to 512 discovery messages to ensure message delivery on client reconnect and clears lazily. With large topology and a large amount caches/partitions this can take up to several Gbs of heap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5439) JDBC thin: support query cancel
[
https://issues.apache.org/jira/browse/IGNITE-5439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5439:
Ignite Flags: (was: Docs Required)
> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.8
>
>
> The JDBC {{Statement.cancel}} method must be supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5438) JDBC thin: support query timeout
[
https://issues.apache.org/jira/browse/IGNITE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744094#comment-16744094
]
Vladimir Ozerov commented on IGNITE-5438:
-
Merged to master.
> JDBC thin: support query timeout
>
>
> Key: IGNITE-5438
> URL: https://issues.apache.org/jira/browse/IGNITE-5438
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{setQueryTimeout}} method of JDBC {{Statement}} must be supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10180) Investigate migration from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov resolved IGNITE-10180. --- Resolution: Done > Investigate migration from Junit 4 to 5 > --- > > Key: IGNITE-10180 > URL: https://issues.apache.org/jira/browse/IGNITE-10180 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Ivan Fedotov >Priority: Major > > If needed, refer parent task for more details. > Find out if Junit 5 is mature enough - specifically why maven and, especially > surefire plugin, still uses Junit 4 as more comfortable from a side of adding > dependencies, are there serious reasons for that or not. If it looks okay, > create a new JIRA task to migrate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10582) MVCC: Error on txLog initialization.
[
https://issues.apache.org/jira/browse/IGNITE-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744093#comment-16744093
]
Andrew Mashenkov commented on IGNITE-10582:
---
Possibly fixed in IGNITE-10421. We have to check tests.
> MVCC: Error on txLog initialization.
>
>
> Key: IGNITE-10582
> URL: https://issues.apache.org/jira/browse/IGNITE-10582
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: Muted_test, mvcc_stabilization_stage_1, pagememory
> Fix For: 2.8
>
>
> A sporadic error occurs during {{txLog}} initialization. Reproducer:
> {{IgnitePdsCacheAssignmentNodeRestartsTest#testAssignmentAfterRestarts}}.
> This error may be the result of the test settings. We need to check it more
> carefully.
> Stacktrace:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to complete exchange process.
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCaches(IgniteKernal.java:3068)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsCacheAssignmentNodeRestartsTest.testAssignmentAfterRestarts(IgnitePdsCacheAssignmentNodeRestartsTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to complete
> exchange process.
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3041)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3069)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3151)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2748)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2556)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2544)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:395)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2544)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1807)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1200(GridCachePartitionExchangeManager.java:145)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:382)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:340)
> at
>
[jira] [Updated] (IGNITE-10379) SQL: Extract partition info from BETWEEN and range conditions for integer types
[
https://issues.apache.org/jira/browse/IGNITE-10379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10379:
-
Ignite Flags: (was: Docs Required)
> SQL: Extract partition info from BETWEEN and range conditions for integer
> types
> ---
>
> Key: IGNITE-10379
> URL: https://issues.apache.org/jira/browse/IGNITE-10379
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> If there is a range condition on affinity column of integer type, we may try
> to extract partition info from it in a way similar to IN clause [1]:
> {{x BETWEEN 1 and 5}} -> {{x IN (1, 2, 3, 4, 5)}}
> {{x > 1 and x <= 5}} -> {{x IN (2, 3, 4, 5)}}
> [1] IGNITE-9632
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10379) SQL: Extract partition info from BETWEEN and range conditions for integer types
[
https://issues.apache.org/jira/browse/IGNITE-10379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744085#comment-16744085
]
Vladimir Ozerov commented on IGNITE-10379:
--
Merged to master.
> SQL: Extract partition info from BETWEEN and range conditions for integer
> types
> ---
>
> Key: IGNITE-10379
> URL: https://issues.apache.org/jira/browse/IGNITE-10379
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> If there is a range condition on affinity column of integer type, we may try
> to extract partition info from it in a way similar to IN clause [1]:
> {{x BETWEEN 1 and 5}} -> {{x IN (1, 2, 3, 4, 5)}}
> {{x > 1 and x <= 5}} -> {{x IN (2, 3, 4, 5)}}
> [1] IGNITE-9632
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744065#comment-16744065 ] Ivan Daschinskiy commented on IGNITE-10507: --- [~antonovsergey93] Fix looks good to me. Thanks for contribution > Control.sh add ability to check crc sums of stored pages > > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We should have ability to check stored data on disk. Also we should return > all exceptions from all nodes, if they are occurred. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[
https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744061#comment-16744061
]
Ignite TC Bot commented on IGNITE-10507:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2813764buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh add ability to check crc sums of stored pages
>
>
> Key: IGNITE-10507
> URL: https://issues.apache.org/jira/browse/IGNITE-10507
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should have ability to check stored data on disk. Also we should return
> all exceptions from all nodes, if they are occurred.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-3622) BinaryObject: print idHash in toString() method only in debug mode
[
https://issues.apache.org/jira/browse/IGNITE-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744059#comment-16744059
]
Andrey Kalinin commented on IGNITE-3622:
[~vozerov] I would like to know your opinion about the presence of idHash in
the toString() method output. Can it be safely removed?
> BinaryObject: print idHash in toString() method only in debug mode
> --
>
> Key: IGNITE-3622
> URL: https://issues.apache.org/jira/browse/IGNITE-3622
> Project: Ignite
> Issue Type: Task
> Components: binary
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Rohit Mohta
>Priority: Trivial
> Labels: newbie
>
> Current implementation of BinaryObject.toString() method print idHash for
> internal objects, for example, for AffinityKey.
> This lead to "unstable" result of toString() method, you will get different
> strings on each toString() invocation.
> Possible fix: introduce
> {code}
> private static final boolean debug = false;
> {code}
> And check this flag in toString().
> If some one will need idHash for debug reasons he could change this flag in
> its private build and debug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744047#comment-16744047 ] Ilya Kasnacheev commented on IGNITE-10886: -- I think we should at least find one working way to run that on Windows & clear error messages when it does not work. > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9926) Improve metada distribution speed in a scenario with concurrent updates for the same schema
[ https://issues.apache.org/jira/browse/IGNITE-9926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov resolved IGNITE-9926. --- Resolution: Fixed Fixed by IGNITE-10376 > Improve metada distribution speed in a scenario with concurrent updates for > the same schema > --- > > Key: IGNITE-9926 > URL: https://issues.apache.org/jira/browse/IGNITE-9926 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > If multiple threads start putting same object with non-existent schema in the > cache simultaneously every update will trigger full propose-accept round trip > in current implementation. > Propose message should be send only for first update, others should wait for > it's completion instead of sending messages for same schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10880) Document how we should evolve our persistence functionality while keeping it compatible with files created by old versions
[ https://issues.apache.org/jira/browse/IGNITE-10880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744054#comment-16744054 ] Alexey Goncharuk commented on IGNITE-10880: --- Got it, will do. > Document how we should evolve our persistence functionality while keeping it > compatible with files created by old versions > -- > > Key: IGNITE-10880 > URL: https://issues.apache.org/jira/browse/IGNITE-10880 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Eduard Shangareev >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > It's not documented at all (???). > We need complete documentation to not break compatibility with previously > created database files while updating/evolving code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744046#comment-16744046 ] Ilya Kasnacheev commented on IGNITE-10886: -- There's the following in CommandLineTransformer: if (!checkJVMOptionIsSupported(jvmOpt)) throw new RuntimeException(JVM_OPTION_PREFIX + " JVM parameters for Ignite batch scripts " + "with double quotes are not supported. " + "Use JVM_OPTS environment variable to pass any custom JVM option."); but I don't observe such messages/errors when running it, JVM_OPTS does not seem to work either. > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[
https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744046#comment-16744046
]
Ilya Kasnacheev edited comment on IGNITE-10886 at 1/16/19 1:40 PM:
---
There's the following in CommandLineTransformer:
{code}
if (!checkJVMOptionIsSupported(jvmOpt))
throw new RuntimeException(JVM_OPTION_PREFIX + " JVM
parameters for Ignite batch scripts " +
"with double quotes are not supported. " +
"Use JVM_OPTS environment variable to pass any custom
JVM option.");
{code}
but I don't observe such messages/errors when running it, JVM_OPTS does not
seem to work either.
was (Author: ilyak):
There's the following in CommandLineTransformer:
if (!checkJVMOptionIsSupported(jvmOpt))
throw new RuntimeException(JVM_OPTION_PREFIX + " JVM
parameters for Ignite batch scripts " +
"with double quotes are not supported. " +
"Use JVM_OPTS environment variable to pass any custom
JVM option.");
but I don't observe such messages/errors when running it, JVM_OPTS does not
seem to work either.
> -J-PARAMS does not allow spaces in arguments
>
>
> Key: IGNITE-10886
> URL: https://issues.apache.org/jira/browse/IGNITE-10886
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> -J-PARAMS doesn't allow spaces, so you can not pass for example:
> -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC.
> it will fail with the following message:
> mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G
> -J-DIGNITE_CLUSTER_NAME="dev dev dev"
> Error: Could not find or load main class dev
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10763) MVCC: Transaction already completed error in some tests
[
https://issues.apache.org/jira/browse/IGNITE-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744044#comment-16744044
]
Ivan Pavlukhin commented on IGNITE-10763:
-
[~gvvinblade], I updates the patch as you suggested. Could we go even further
and reset context in {{GridNearTxAbstractEnlistFuture#init}}? It will look nice
because context will be set and cleared in the same class. Can such way break
something?
> MVCC: Transaction already completed error in some tests
> ---
>
> Key: IGNITE-10763
> URL: https://issues.apache.org/jira/browse/IGNITE-10763
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1,
> transactions
> Fix For: 2.8
>
>
> "Transaction is already completed" error occurs time to time in some tests.
> Reproducer:
> {{CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction}}
> {{CacheMvccPartitionedSqlTxQueriesWithReducerTest.testQueryReducerDeadlockInsertWithTxTimeout}}
>
> {noformat}
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:660)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:832)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:813)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:796)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1131)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:1990)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1636)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1526)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2167)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2162)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2670)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2176)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2196)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2157)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2118)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2091)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.runSql(CacheMvccReplicatedSqlTxQueriesTest.java:234)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction(CacheMvccReplicatedSqlTxQueriesTest.java:202)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10763) MVCC: Transaction already completed error in some tests
[
https://issues.apache.org/jira/browse/IGNITE-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744044#comment-16744044
]
Ivan Pavlukhin edited comment on IGNITE-10763 at 1/16/19 1:36 PM:
--
[~gvvinblade], I updated the patch as you suggested. Could we go even further
and reset context in {{GridNearTxAbstractEnlistFuture#init}}? It will look nice
because context will be set and cleared in the same class. Can such way break
something?
was (Author: pavlukhin):
[~gvvinblade], I updates the patch as you suggested. Could we go even further
and reset context in {{GridNearTxAbstractEnlistFuture#init}}? It will look nice
because context will be set and cleared in the same class. Can such way break
something?
> MVCC: Transaction already completed error in some tests
> ---
>
> Key: IGNITE-10763
> URL: https://issues.apache.org/jira/browse/IGNITE-10763
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1,
> transactions
> Fix For: 2.8
>
>
> "Transaction is already completed" error occurs time to time in some tests.
> Reproducer:
> {{CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction}}
> {{CacheMvccPartitionedSqlTxQueriesWithReducerTest.testQueryReducerDeadlockInsertWithTxTimeout}}
>
> {noformat}
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:660)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:832)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:813)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:796)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1131)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:1990)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1636)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1526)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2167)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2162)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2670)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2176)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2196)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2157)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2118)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2091)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.runSql(CacheMvccReplicatedSqlTxQueriesTest.java:234)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccReplicatedSqlTxQueriesTest.testReplicatedAndPartitionedUpdateSingleTransaction(CacheMvccReplicatedSqlTxQueriesTest.java:202)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
>
[jira] [Commented] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744041#comment-16744041 ] Ilya Kasnacheev commented on IGNITE-10886: -- [~mcherkasov] there is same problem for ignite.bat on Windows, I think they should both be tackled at once. Can you look at it? > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10899) Service Grid: disconnecting during node stop may lead to deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744038#comment-16744038
]
Eduard Shangareev edited comment on IGNITE-10899 at 1/16/19 1:27 PM:
-
[~daradurvs], looks good. Thank you for your contribution!
was (Author: edshanggg):
[~daradurvs], looks good. Thank you for your cotribution!
> Service Grid: disconnecting during node stop may lead to deadlock
> -
>
> Key: IGNITE-10899
> URL: https://issues.apache.org/jira/browse/IGNITE-10899
> Project: Ignite
> Issue Type: Task
> Components: managed services
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> In a rare case {{onDisconneced}} may be called during node stopping and
> deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
> blocks busyLock and not release it intentionally.
> The issue has been found on TeamCity in [Zookeeper's
> suite|https://ci.ignite.apache.org/viewLog.html?buildId=2768270=IgniteTests24Java8_ZooKeeperDiscovery2]
> with the following stack trace:
> {code:java}
> disco-notifier-worker-#569118%client4%"
> #609288
> prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
> sleeping[0x7f9383efd000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
> at
> org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
> at
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
> - locked <0xf7ecdfa0> (a java.lang.Object)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
> Source)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10899) Service Grid: disconnecting during node stop may lead to deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744038#comment-16744038
]
Eduard Shangareev commented on IGNITE-10899:
[~daradurvs], looks good. Thank you for your cotribution!
> Service Grid: disconnecting during node stop may lead to deadlock
> -
>
> Key: IGNITE-10899
> URL: https://issues.apache.org/jira/browse/IGNITE-10899
> Project: Ignite
> Issue Type: Task
> Components: managed services
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> In a rare case {{onDisconneced}} may be called during node stopping and
> deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
> blocks busyLock and not release it intentionally.
> The issue has been found on TeamCity in [Zookeeper's
> suite|https://ci.ignite.apache.org/viewLog.html?buildId=2768270=IgniteTests24Java8_ZooKeeperDiscovery2]
> with the following stack trace:
> {code:java}
> disco-notifier-worker-#569118%client4%"
> #609288
> prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
> sleeping[0x7f9383efd000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
> at
> org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
> at
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
> - locked <0xf7ecdfa0> (a java.lang.Object)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
> Source)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache
[
https://issues.apache.org/jira/browse/IGNITE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744028#comment-16744028
]
Ilya Lantukh commented on IGNITE-9739:
--
Looks good.
> Critical exception in transaction processing in case we have nodes out of
> baseline and non-persisted cache
> --
>
> Key: IGNITE-9739
> URL: https://issues.apache.org/jira/browse/IGNITE-9739
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
>
> Activation finished
> {code:java}
> 2018-09-20 20:47:05.169 [INFO
> ][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Successfully performed final activation steps
> [nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
> {code}
> but we have nodes not in base line
> {code:java}
> 2018-09-20 20:45:36.116 [INFO
> ][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Local node is not included in Baseline Topology and will not be used for
> persistent data storage. Use control.(sh|bat) script or IgniteCluster
> interface to include the node to Baseline Topology.
> {code}
> And we have cache (869481129) in the data region with persistanceEnabled=false
> {code:java}
> 2018-09-20 20:49:01.825 [INFO
> ][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
> Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
> STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted,
> mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
> {code}
> Transaction on this cache(869481129)
> {code:java}
> 869481129{code}
> leads to critical error causing nodes by faulure handler:
> {code:java}
> 2018-09-20 20:50:24.275
> [ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235,
> msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774,
> futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821,
> nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC,
> isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365,
> order=1537511036824, nodeOrder=7], timeout=299970, reads=null,
> writes=ArrayList [
> IgniteTxEntry [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*], val=[op=CREATE,
> val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple
> [idHash=811765531, hash=1522508040,
> cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList
> {com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1583970836, hash=363194492, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList
> \{isDeleted},moduleName=union-module
> , cachedUnselectives=1, selectors=ArrayList {isDeleted},
> exceptUnselectives=false, primitiveCollection=false, isVersioned=false,
> isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false,
> isGlobal=false, maxSelective=1000],
> com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=2060926101, hash=1983794578, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList ,moduleName=union-module,
> cachedUnselectives=1, selectors=ArrayList, exceptUnselectives=false,
> primitiveCollection=false, isVersioned=false, isComposite=false,
> isSystemTypeBelongs=false, name=com.sbt.gbk.entities.DocType_DPL_code,
> isIndexedCollection=false, isGlobal=true, maxSelective=1000]
> , com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1821682714, hash=-1245813786, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList {globalId},
> moduleName=union-module, cachedUnselectives=1, selectors=ArrayList
> {globalId}, exceptUnselectives=false, primitiveCollection=false,
> isVersioned=false, isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_globalId, isIndexedCollection=false,
>
[jira] [Commented] (IGNITE-10648) Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener hangs on latch.
[ https://issues.apache.org/jira/browse/IGNITE-10648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744027#comment-16744027 ] Alexey Goncharuk commented on IGNITE-10648: --- [~v.pyatkov], when I run the test, it dumps a lot of warning about a critical thread being blocked, is that something that is supposed to happen? If so, I would like to ignore this critical failure in the test not to dump threads every 5 seconds. Also, 40 seconds for such a test is too long, we need to reduce the test execution time. > Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener > hangs on latch. > - > > Key: IGNITE-10648 > URL: https://issues.apache.org/jira/browse/IGNITE-10648 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > If Ignition.start waits on rebalance then GridRestProcessor is not started > yet then we call Ingition.stop and > GridTcpRestNioListener hangs on > if (marshMapLatch.getCount() > 0) > U.awaitQuiet(marshMapLatch); > cause wasn't counted down on start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10648) Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener hangs on latch.
[ https://issues.apache.org/jira/browse/IGNITE-10648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10648: -- Fix Version/s: 2.8 > Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener > hangs on latch. > - > > Key: IGNITE-10648 > URL: https://issues.apache.org/jira/browse/IGNITE-10648 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > If Ignition.start waits on rebalance then GridRestProcessor is not started > yet then we call Ingition.stop and > GridTcpRestNioListener hangs on > if (marshMapLatch.getCount() > 0) > U.awaitQuiet(marshMapLatch); > cause wasn't counted down on start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10648) Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener hangs on latch.
[ https://issues.apache.org/jira/browse/IGNITE-10648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10648: -- Ignite Flags: (was: Docs Required) > Ignite hang to stop if node wasn't started completely. GridTcpRestNioListener > hangs on latch. > - > > Key: IGNITE-10648 > URL: https://issues.apache.org/jira/browse/IGNITE-10648 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Vladislav Pyatkov >Priority: Major > > If Ignition.start waits on rebalance then GridRestProcessor is not started > yet then we call Ingition.stop and > GridTcpRestNioListener hangs on > if (marshMapLatch.getCount() > 0) > U.awaitQuiet(marshMapLatch); > cause wasn't counted down on start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5463) Weird CPU load reported
[
https://issues.apache.org/jira/browse/IGNITE-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744011#comment-16744011
]
Andrey Kalinin commented on IGNITE-5463:
[~yzhdanov] This ticket was created more than a year and a half ago and, as it
seems to me, the attached information is not enough to reproduce this
situation. In addition, since then the product progress has gone far ahead.
Thus, I propose to close this ticket as irrelevant.
> Weird CPU load reported
> ---
>
> Key: IGNITE-5463
> URL: https://issues.apache.org/jira/browse/IGNITE-5463
> Project: Ignite
> Issue Type: Bug
>Reporter: Yakov Zhdanov
>Priority: Minor
> Labels: newbie
>
> {noformat}
> 2017-06-09 16:27:55,827 INFO [IgniteKernal%187358542614215] -
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=56495ffd, name=187358542614215, uptime=00:46:42:936]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=4]
> ^-- CPU [cur=100%, avg=12.85%, GC=125.47%]
> ^-- PageMemory [pages=314674]
> ^-- Heap [used=4777MB, free=12.52%, comm=5461MB]
> ^-- Non heap [used=71MB, free=-1%, comm=77MB]
> ^-- Public thread pool [active=0, idle=0, qSize=0]
> ^-- System thread pool [active=0, idle=1, qSize=0]
> ^-- Outbound messages queue [size=0]
> {noformat}
> Need to investigate strange numbers reported and fix. My Ignite process had
> no free heap at the moment I noticed that in the logs but OOME was not thrown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10316) control.sh --baseline remove outputs wrong error message when trying to remove node from baseline when cluster is inactive.
[
https://issues.apache.org/jira/browse/IGNITE-10316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-10316:
--
Ignite Flags: (was: Docs Required)
> control.sh --baseline remove outputs wrong error message when trying to
> remove node from baseline when cluster is inactive.
> ---
>
> Key: IGNITE-10316
> URL: https://issues.apache.org/jira/browse/IGNITE-10316
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
> 1. start 2 nodes from clean lfs
> 2. grep node consistent ids
> {noformat}
> $ grep "Consistent ID" work/log/*.log
> work/log/ignite-15958745.0.log:[16:59:13,190][INFO][main][PdsFoldersResolver]
> Consistent ID used for local node is [7ee8018b-3f5f-4c58-b6dd-f53ed7af2679]
> according to persistence data storage folders
> work/log/ignite-300c7412.0.log:[16:59:15,678][INFO][main][PdsFoldersResolver]
> Consistent ID used for local node is [5adcf3a1-7ad9-40fa-88ac-40b488dc6b34]
> according to persistence data storage folders
> {noformat}
> 3. try to remove node from baseline
> expected: error message about cluster inactive state
> actual: error message about node id not found, BUG
> {noformat}
> Caused by: java.lang.IllegalStateException: Node not found for consistent ID:
> 7ee8018b-3f5f-4c58-b6dd-f53ed7af2679
> at
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.remove(VisorBaselineTask.java:178)
> at
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:208)
> at
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:52)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6726)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> ... 19 more
> {noformat}
> however, when trying to add node to baseline, error message is correct:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Changing BaselineTopology
> on inactive cluster is not allowed.
> at
> org.apache.ignite.internal.cluster.IgniteClusterImpl.validateBeforeBaselineChange(IgniteClusterImpl.java:406)
> at
> org.apache.ignite.internal.cluster.IgniteClusterImpl.setBaselineTopology(IgniteClusterImpl.java:356)
> at
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.set0(VisorBaselineTask.java:87)
> at
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.add(VisorBaselineTask.java:162)
> at
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:205)
> at
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:52)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6726)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1123)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1407)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:660)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:532)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10956) MVCC TX: Move queryEnlisted flag from IgniteTxLocalAdapter to IgniteTxState
Igor Seliverstov created IGNITE-10956: - Summary: MVCC TX: Move queryEnlisted flag from IgniteTxLocalAdapter to IgniteTxState Key: IGNITE-10956 URL: https://issues.apache.org/jira/browse/IGNITE-10956 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov queryEnlisted flag represents a transaction state (like txState.empty(), in other words shows whether there were some updates on MVCC caches or not). It makes sense to move such flag to IgniteTxState. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10954) MVCC: Umute fixed tests.
[ https://issues.apache.org/jira/browse/IGNITE-10954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10954: -- Fix Version/s: 2.8 > MVCC: Umute fixed tests. > > > Key: IGNITE-10954 > URL: https://issues.apache.org/jira/browse/IGNITE-10954 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: mvcc_stabilization_stage_1 > Fix For: 2.8 > > > Check if next tests passes on TC and unmute them, > otherwise re-mute with correct ticket. > IgnitePdsDataRegionMetricsTest.testUsedCheckpointBuffer > TxRollbackAsyncWithPersistenceTest.testSynchronousRollback -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10954) MVCC: Umute fixed tests.
[ https://issues.apache.org/jira/browse/IGNITE-10954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10954: - Assignee: Andrew Mashenkov > MVCC: Umute fixed tests. > > > Key: IGNITE-10954 > URL: https://issues.apache.org/jira/browse/IGNITE-10954 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: mvcc_stabilization_stage_1 > > Check if next tests passes on TC and unmute them, > otherwise re-mute with correct ticket. > IgnitePdsDataRegionMetricsTest.testUsedCheckpointBuffer > TxRollbackAsyncWithPersistenceTest.testSynchronousRollback -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10955) [ML] Migrate boosting implementation to sequential trainers composition combinator
Artem Malykh created IGNITE-10955: - Summary: [ML] Migrate boosting implementation to sequential trainers composition combinator Key: IGNITE-10955 URL: https://issues.apache.org/jira/browse/IGNITE-10955 Project: Ignite Issue Type: Improvement Components: ml Affects Versions: 2.8 Reporter: Artem Malykh Assignee: Artem Malykh There are two trainers composition primitives which are used in other ensemble training methods (Bagging and Stacking) implementation. To unify implementation I suggest to rewrite impl of boosting using these composition primitives as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10180) Investigate migration from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744005#comment-16744005 ] Ivan Fedotov commented on IGNITE-10180: --- [~oignatenko], I investigated the migration process to JUnit 5 and got the next results. 1. JUnit 5 was integrated to SureFire by collaboration maven and JUnit teams and some architecture aspects were suggested by JUnit developers [1] 2. Integration was provided in several steps and was finished in 2018 [2] 3. JUnit 5 framework is divided into 3 sub-projects: Jupiter - new annotations and extensions, Vintage - for running 3 and 4 JUnit versions and Platform which is used for launching new framework on JVM. So, for usage 5 version it could be necessary to add several dependencies [3]. 4. Maven uses Java 6 language level. For JUnit 4 it is necessary Java 5, for JUnit 5 at least Java 8. So, it seems that segregation into different modules was proposed by implementation issue. Moreover, apparent adjunction inconvenience JUnit4 to maven could be because of maven language level. Anyway, nothing prevents in JUnit5 run JUnit 3 and JUnit 4 based tests on the platform with Vintage sub-project. [1] https://github.com/apache/maven-surefire/pull/184 [2] https://issues.apache.org/jira/browse/SUREFIRE-1330 [3] https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5 > Investigate migration from Junit 4 to 5 > --- > > Key: IGNITE-10180 > URL: https://issues.apache.org/jira/browse/IGNITE-10180 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Ivan Fedotov >Priority: Major > > If needed, refer parent task for more details. > Find out if Junit 5 is mature enough - specifically why maven and, especially > surefire plugin, still uses Junit 4 as more comfortable from a side of adding > dependencies, are there serious reasons for that or not. If it looks okay, > create a new JIRA task to migrate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10954) MVCC: Umute fixed tests.
Andrew Mashenkov created IGNITE-10954: - Summary: MVCC: Umute fixed tests. Key: IGNITE-10954 URL: https://issues.apache.org/jira/browse/IGNITE-10954 Project: Ignite Issue Type: Test Components: mvcc Reporter: Andrew Mashenkov Check if next tests passes on TC and unmute them, otherwise re-mute with correct ticket. IgnitePdsDataRegionMetricsTest.testUsedCheckpointBuffer TxRollbackAsyncWithPersistenceTest.testSynchronousRollback -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7309) Sutable exception should be return as job results when node is about to stop.
[
https://issues.apache.org/jira/browse/IGNITE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743979#comment-16743979
]
Ilya Kasnacheev commented on IGNITE-7309:
-
[~guseinov] I have reviewed proposed change, asked to simplify if condition and
write test if possible.
> Sutable exception should be return as job results when node is about to stop.
> -
>
> Key: IGNITE-7309
> URL: https://issues.apache.org/jira/browse/IGNITE-7309
> Project: Ignite
> Issue Type: Bug
> Components: compute, general
>Reporter: Andrew Mashenkov
>Assignee: Roman Guseinov
>Priority: Minor
> Labels: newbie, pull-request-available
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User job can fails with confusing exception when server node is stopping and
> going to leave the grid.
> We should suppress InterruptedException. If node is stopping then user should
> see NodeStoppingException.
> {code:java}
> [org.apache.ignite.internal.processors.job.GridJobWorker] Failed to serialize
> job response [nodeId=02e1588
> c-53eb-454a-99a1-48ac6cb33667, ses=GridJobSessionImpl
> [ses=GridTaskSessionImpl
> ..
> org.apache.ignite.IgniteCheckedException: Failed to register class.
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:9929)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.finishJob(GridJobWorker.java:819)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.finishJob(GridJobWorker.java:760)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:619)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:483)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1180)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1899)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1519)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1147)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:119)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1087)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to register
> class.
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:778)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:751)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:621)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:239)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:9923)
> ... 14 common frames omitted
> Caused by: org.apache.ignite.internal.IgniteInterruptedCheckedException: null
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.tryGetAndPut(GridDhtAtomicCache.java:724)
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:169)
> at
> org.apache.ignite.internal.MarshallerContextAdapter$1.applyx(MarshallerContextAdapter.java:168)
> at
> org.apache.ignite.internal.MarshallerContextAdapter$1.applyx(MarshallerContextAdapter.java:166)
> at
> org.apache.ignite.internal.MarshallerContextAdapter.computeIfAbsent(MarshallerContextAdapter.java:224)
> at
>
[jira] [Comment Edited] (IGNITE-10376) Fail to update metadata during invocation on cache
[
https://issues.apache.org/jira/browse/IGNITE-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743971#comment-16743971
]
Sergey Chugunov edited comment on IGNITE-10376 at 1/16/19 12:34 PM:
[~ivanan.fed],
Fix looks good to me, I took a look at some red tests in the latest TC run but
they don't seem related to your code change. Lets proceed with merging.
Thank you for your efforts!
was (Author: sergey-chugunov):
[~ivanan.fed],
Fix looks good to me, I took a look at some red tests in the latest TC run but
they don't seem related to your code change. Lets proceed with merging.
Thank you for your work!
> Fail to update metadata during invocation on cache
> ---
>
> Key: IGNITE-10376
> URL: https://issues.apache.org/jira/browse/IGNITE-10376
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, stability, test-fail
> Fix For: 2.8
>
> Attachments: IGNITE-10376 log.txt
>
>
> BinaryObjectException exception sometimes appears in
> [testAtomicOnheapTwoBackupAsyncFullSync|https://ci.ignite.apache.org/viewLog.html?buildId=2398013=buildResultsDiv=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025]
> at the
> [moment|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L371]
> of CacheEntryProcessor invocation.
> {code}class org.apache.ignite.binary.BinaryObjectException: Failed to update
> meta data for type:
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$QueryTestValue
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:516)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:194)
> at
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1332)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1150)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:831)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1438)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1482)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1228)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$1.run(CacheContinuousQueryOrderingEventTest.java:373)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1300)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10376) Fail to update metadata during invocation on cache
[
https://issues.apache.org/jira/browse/IGNITE-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743971#comment-16743971
]
Sergey Chugunov commented on IGNITE-10376:
--
[~ivanan.fed],
Fix looks good to me, I took a look at some red tests in the latest TC run but
they don't seem related to your code change. Lets proceed with merging.
Thank you for your work!
> Fail to update metadata during invocation on cache
> ---
>
> Key: IGNITE-10376
> URL: https://issues.apache.org/jira/browse/IGNITE-10376
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, stability, test-fail
> Fix For: 2.8
>
> Attachments: IGNITE-10376 log.txt
>
>
> BinaryObjectException exception sometimes appears in
> [testAtomicOnheapTwoBackupAsyncFullSync|https://ci.ignite.apache.org/viewLog.html?buildId=2398013=buildResultsDiv=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025]
> at the
> [moment|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L371]
> of CacheEntryProcessor invocation.
> {code}class org.apache.ignite.binary.BinaryObjectException: Failed to update
> meta data for type:
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$QueryTestValue
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:516)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:194)
> at
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1332)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1150)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:831)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1438)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1482)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1228)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$1.run(CacheContinuousQueryOrderingEventTest.java:373)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1300)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[
https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743962#comment-16743962
]
Ignite TC Bot commented on IGNITE-10877:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2805125buildTypeId=IgniteTests24Java8_RunAll]
> GridAffinityAssignment.initPrimaryBackupMaps memory pressure
>
>
> Key: IGNITE-10877
> URL: https://issues.apache.org/jira/browse/IGNITE-10877
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
> Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> 1) While running tests with JFR we observe huge memory allocation pressure
> produced by:
> *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*
> java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784
> 100
> java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044
> 784 100
> java.util.HashMap.put(Object, Object) 481 298 044 784 100
> java.util.HashSet.add(Object) 480 297 221 040 99,724
>
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
> 1 823 744 0,276
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
> List, List) 1 823 744 0,276
> *Allocation stats*
> Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB
> Size(bytes) Total TLAB Size(bytes) Pressure(%)
> java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
> java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
> java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864
> 11,341
> java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
> java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198
> 2) Also another hot place found
> Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)
> java.util.ArrayList.grow(int) 7 5 766 448 9,554
> java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554
> java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554
> java.util.ArrayList.add(Object) 7 5 766 448 9,554
>
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int,
> AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5
> 766 448 9,554
> The reason of that is defail
> I think we need to improve memory efficiency by switching from from Sets to
> BitSets
>
> JFR attached, see Allocations in 12:50:28 - 12:50:29
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[
https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-9845:
Assignee: Pavel Konstantinov (was: Alexey Kuznetsov)
Merged fix of NPE to master.
> Web Console: Add support of two way ssl authentication in Web Console agent
> ---
>
> Key: IGNITE-9845
> URL: https://issues.apache.org/jira/browse/IGNITE-9845
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Affects Versions: 2.6
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Selection_274.png, generate.bat, generate.sh,
> jetty-with-ssl.xml, ssl.pdf
>
>
> RestExecutor should not be shared between different users requests in case of
> two way ssl authentication:
> * For each token with ssl we need create separated RestExecutor and set up
> socketFactory and trustManager.
> * RestExecutor should be removed if token expired.
> Add program arguments for passing client certificate, client password, trust
> store, trust store password for ignite node connection and web console
> backend.
> Example on okhttp:
> [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]
> Upgrade socket-io from 1.x to 2.x.
> Add support for SSL cipher suites
> Add tests.
> ---
> *How to do local testing:*
> On Windows
> # Download Open SSL: Download Open SSL for Windows from
> [https://wiki.openssl.org/index.php/Binaries]
> # Unpack it.
> On Linux - it is usually built-in.
> Generate keys with provided script (see attached generate.bat, it could be
> easily adapted for Linux).
>
> Add to etc/hosts:
> 127.0.0.1 localhost console.test.local
>
> After that configure SSL for:
> # Web Console back-end.
> # Web Agent.
> # Cluster.
> *Configure Web Console back-end settings:*
> "ssl": true,
> "key": "some_path/server.key",
> "cert": "some_path/server.crt",
> "ca": "some_path/ca.crt",
> "keyPassphrase": "p123456",
> *Configure Web Agent parameters (see parameters descriptions):*
> -t your_token
> -s [https://console.test.local:3000|https://console.test.local:3000/] -n
> [https://console.test.local:11443|https://console.test.local:11443/]
> -nks client.jks -nkp p123456
> -nts ca.jks -ntp p123456
> -sks client.jks -skp p123456
> -sts ca.jks -stp p123456
> *Configure cluster JETTY config (see FULL config attached):*
>
> https
> default="11443"/>
> true
> true
> class="org.eclipse.jetty.server.SecureRequestCustomizer"/>
>
> class="org.eclipse.jetty.util.ssl.SslContextFactory">
> some_path/server.jks
> p123456
> some_path/ca.jks
> p123456
> true
>
> *How to start secure web console in direct install edition in Ubuntu:*
> # Download ignite web console direct install for linux ZIP archive .
> # Unpack downloaded archive to goal folder.
> # Generate SSL certificates.
> # Copy generated certificates to folder with unpacked web console direct
> install.
> # Open terminal and navigate to folder with unpacked web console direct
> install.
> # Run web console with the next command:
> {code:java}
> ignite-web-console-linux --server:port 11443 --server:ssl true
> --server:requestCert true --server:key "server.key" --server:cert
> "server.crt" --server:ca "ca.crt" --server:passphrase "p123456"{code}
> 7. Import client.p12 certificate into your browser. See attached
> screenstot in Chrome browser.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10879) Create suite of Cassandra Cache Store tests, add to TC
[ https://issues.apache.org/jira/browse/IGNITE-10879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743881#comment-16743881 ] Ilya Kasnacheev commented on IGNITE-10879: -- https://ci.ignite.apache.org/viewLog.html?buildId=2814144=IgniteTests24Java8_CassandraStore tests pass > Create suite of Cassandra Cache Store tests, add to TC > -- > > Key: IGNITE-10879 > URL: https://issues.apache.org/jira/browse/IGNITE-10879 > Project: Ignite > Issue Type: Sub-task > Components: cassandra >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > Currently, they're not running in TC at all -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10796) Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
[
https://issues.apache.org/jira/browse/IGNITE-10796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743874#comment-16743874
]
Dmitriy Govorukhin commented on IGNITE-10796:
-
[~oignatenko] Merged to master. Thanks!
> Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
> --
>
> Key: IGNITE-10796
> URL: https://issues.apache.org/jira/browse/IGNITE-10796
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This task is to migrate from JUnit 3 to 4 test suites suites involving
> {{IgniteTestSuite}} API that was introduced per IGNITE-3658.
> If needed, refer parent task comments for more details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[
https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743865#comment-16743865
]
Pavel Konstantinov commented on IGNITE-9845:
{code}
[WARN ][main][AgentLauncher] Options contains both '--node-trust-store' and
'-Dtrust.all=true'. Option '-Dtrust.all=true' will be ignored.
Exception in thread "main" java.lang.NullPointerException: trustManager == null
at okhttp3.OkHttpClient$Builder.sslSocketFactory(OkHttpClient.java:805)
at
org.apache.ignite.console.agent.AgentLauncher.main(AgentLauncher.java:367)
{code}
agent's default.properties ssl settings are
{code}
node-key-store=client.jks
node-key-store-password=p123456
node-trust-store=ca.jks
node-trust-store-password=p123456
server-key-store=client.jks
server-key-store-password=p123456
#server-trust-store=ca.jks
server-trust-store-password=p123456
#cipher-suites=CIPHER1,CIPHER2,CIPHER3
{code}
> Web Console: Add support of two way ssl authentication in Web Console agent
> ---
>
> Key: IGNITE-9845
> URL: https://issues.apache.org/jira/browse/IGNITE-9845
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Affects Versions: 2.6
>Reporter: Andrey Novikov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Selection_274.png, generate.bat, generate.sh,
> jetty-with-ssl.xml, ssl.pdf
>
>
> RestExecutor should not be shared between different users requests in case of
> two way ssl authentication:
> * For each token with ssl we need create separated RestExecutor and set up
> socketFactory and trustManager.
> * RestExecutor should be removed if token expired.
> Add program arguments for passing client certificate, client password, trust
> store, trust store password for ignite node connection and web console
> backend.
> Example on okhttp:
> [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]
> Upgrade socket-io from 1.x to 2.x.
> Add support for SSL cipher suites
> Add tests.
> ---
> *How to do local testing:*
> On Windows
> # Download Open SSL: Download Open SSL for Windows from
> [https://wiki.openssl.org/index.php/Binaries]
> # Unpack it.
> On Linux - it is usually built-in.
> Generate keys with provided script (see attached generate.bat, it could be
> easily adapted for Linux).
>
> Add to etc/hosts:
> 127.0.0.1 localhost console.test.local
>
> After that configure SSL for:
> # Web Console back-end.
> # Web Agent.
> # Cluster.
> *Configure Web Console back-end settings:*
> "ssl": true,
> "key": "some_path/server.key",
> "cert": "some_path/server.crt",
> "ca": "some_path/ca.crt",
> "keyPassphrase": "p123456",
> *Configure Web Agent parameters (see parameters descriptions):*
> -t your_token
> -s [https://console.test.local:3000|https://console.test.local:3000/] -n
> [https://console.test.local:11443|https://console.test.local:11443/]
> -nks client.jks -nkp p123456
> -nts ca.jks -ntp p123456
> -sks client.jks -skp p123456
> -sts ca.jks -stp p123456
> *Configure cluster JETTY config (see FULL config attached):*
>
> https
> default="11443"/>
> true
> true
> class="org.eclipse.jetty.server.SecureRequestCustomizer"/>
>
> class="org.eclipse.jetty.util.ssl.SslContextFactory">
> some_path/server.jks
> p123456
> some_path/ca.jks
> p123456
> true
>
> *How to start secure web console in direct install edition in Ubuntu:*
> # Download ignite web console direct install for linux ZIP archive .
> # Unpack downloaded archive to goal folder.
> # Generate SSL certificates.
> # Copy generated certificates to folder with unpacked web console direct
> install.
> # Open terminal and navigate to folder with unpacked web console direct
> install.
> # Run web console with the next command:
> {code:java}
> ignite-web-console-linux --server:port 11443 --server:ssl true
> --server:requestCert true --server:key "server.key" --server:cert
> "server.crt" --server:ca "ca.crt" --server:passphrase "p123456"{code}
> 7. Import client.p12 certificate into your browser. See attached
> screenstot in Chrome browser.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
[
https://issues.apache.org/jira/browse/IGNITE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743863#comment-16743863
]
Alexey Kuznetsov commented on IGNITE-9845:
--
Merged to master.
> Web Console: Add support of two way ssl authentication in Web Console agent
> ---
>
> Key: IGNITE-9845
> URL: https://issues.apache.org/jira/browse/IGNITE-9845
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Affects Versions: 2.6
>Reporter: Andrey Novikov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Selection_274.png, generate.bat, generate.sh,
> jetty-with-ssl.xml, ssl.pdf
>
>
> RestExecutor should not be shared between different users requests in case of
> two way ssl authentication:
> * For each token with ssl we need create separated RestExecutor and set up
> socketFactory and trustManager.
> * RestExecutor should be removed if token expired.
> Add program arguments for passing client certificate, client password, trust
> store, trust store password for ignite node connection and web console
> backend.
> Example on okhttp:
> [https://github.com/square/okhttp/blob/cd872fd83824512c128dcd80c04d445c8a2fc8eb/okhttp-tests/src/test/java/okhttp3/internal/tls/ClientAuthTest.java]
> Upgrade socket-io from 1.x to 2.x.
> Add support for SSL cipher suites
> Add tests.
> ---
> *How to do local testing:*
> On Windows
> # Download Open SSL: Download Open SSL for Windows from
> [https://wiki.openssl.org/index.php/Binaries]
> # Unpack it.
> On Linux - it is usually built-in.
> Generate keys with provided script (see attached generate.bat, it could be
> easily adapted for Linux).
>
> Add to etc/hosts:
> 127.0.0.1 localhost console.test.local
>
> After that configure SSL for:
> # Web Console back-end.
> # Web Agent.
> # Cluster.
> *Configure Web Console back-end settings:*
> "ssl": true,
> "key": "some_path/server.key",
> "cert": "some_path/server.crt",
> "ca": "some_path/ca.crt",
> "keyPassphrase": "p123456",
> *Configure Web Agent parameters (see parameters descriptions):*
> -t your_token
> -s [https://console.test.local:3000|https://console.test.local:3000/] -n
> [https://console.test.local:11443|https://console.test.local:11443/]
> -nks client.jks -nkp p123456
> -nts ca.jks -ntp p123456
> -sks client.jks -skp p123456
> -sts ca.jks -stp p123456
> *Configure cluster JETTY config (see FULL config attached):*
>
> https
> default="11443"/>
> true
> true
> class="org.eclipse.jetty.server.SecureRequestCustomizer"/>
>
> class="org.eclipse.jetty.util.ssl.SslContextFactory">
> some_path/server.jks
> p123456
> some_path/ca.jks
> p123456
> true
>
> *How to start secure web console in direct install edition in Ubuntu:*
> # Download ignite web console direct install for linux ZIP archive .
> # Unpack downloaded archive to goal folder.
> # Generate SSL certificates.
> # Copy generated certificates to folder with unpacked web console direct
> install.
> # Open terminal and navigate to folder with unpacked web console direct
> install.
> # Run web console with the next command:
> {code:java}
> ignite-web-console-linux --server:port 11443 --server:ssl true
> --server:requestCert true --server:key "server.key" --server:cert
> "server.crt" --server:ca "ca.crt" --server:passphrase "p123456"{code}
> 7. Import client.p12 certificate into your browser. See attached
> screenstot in Chrome browser.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10890) Web console: UIRouter cleanup
[ https://issues.apache.org/jira/browse/IGNITE-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-10890: -- Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) > Web console: UIRouter cleanup > - > > Key: IGNITE-10890 > URL: https://issues.apache.org/jira/browse/IGNITE-10890 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Labels: architecture, ui, wizard > Original Estimate: 6h > Time Spent: 2.5h > Remaining Estimate: 3.5h > > 1. Do not depend on _@uirouter/angularjs/lib/legacy/stateEvents_, replace all > legacy $scope events with transition-based API. > 2. Remove _@uirouter/visualizer_, which is only used for development. > The goal is to decrease bundle size and drop legacy APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10890) Web console: UIRouter cleanup
[ https://issues.apache.org/jira/browse/IGNITE-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743830#comment-16743830 ] Alexander Kalinin commented on IGNITE-10890: Please test queries notebook screen works right. > Web console: UIRouter cleanup > - > > Key: IGNITE-10890 > URL: https://issues.apache.org/jira/browse/IGNITE-10890 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Labels: architecture, ui, wizard > Original Estimate: 6h > Time Spent: 2.5h > Remaining Estimate: 3.5h > > 1. Do not depend on _@uirouter/angularjs/lib/legacy/stateEvents_, replace all > legacy $scope events with transition-based API. > 2. Remove _@uirouter/visualizer_, which is only used for development. > The goal is to decrease bundle size and drop legacy APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10935) "Invalid node order" error occurs while cycle cluster nodes restart
[
https://issues.apache.org/jira/browse/IGNITE-10935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-10935:
--
Ignite Flags: (was: Docs Required)
> "Invalid node order" error occurs while cycle cluster nodes restart
> ---
>
> Key: IGNITE-10935
> URL: https://issues.apache.org/jira/browse/IGNITE-10935
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Assignee: Alexey Goncharuk
>Priority: Critical
>
> Same scenario as in https://issues.apache.org/jira/browse/IGNITE-10878
> {code:java}
> Exception in thread "tcp-disco-msg-worker-#2" java.lang.AssertionError:
> Invalid node order: TcpDiscoveryNode
> [id=9a332aa3-3d60-469a-9ff5-3deee8918451, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.17.0.1, 172.25.1.40], sockAddrs=[/172.25.1.40:47501,
> /0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, /172.17.0.1:47501],
> discPort=47501, order=0, intOrder=16, lastExchangeTime=1547486771047,
> loc=false, ver=2.4.13#20190114-sha1:a7667ae6, isClient=false]
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:51)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:48)
> at org.apache.ignite.internal.util.lang.GridFunc.isAll(GridFunc.java:2030)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9635)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9608)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nodes(TcpDiscoveryNodesRing.java:625)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.visibleNodes(TcpDiscoveryNodesRing.java:145)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.notifyDiscovery(ServerImpl.java:1429)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2400(ServerImpl.java:176)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4565)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2732)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2554)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6955)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2634)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Collaps{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10935) "Invalid node order" error occurs while cycle cluster nodes restart
[
https://issues.apache.org/jira/browse/IGNITE-10935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743813#comment-16743813
]
Alexey Goncharuk commented on IGNITE-10935:
---
The issue is caused by the new coordinator never sending
{{TcpDiscoveryNodeAddFinishedMessage}} when an old coordinator failed before
sending the message.
Initial suggestion for the fix is to monitor when the local nodes becomes a
coordinator and send the {{TcpDiscoveryNodeAddFinishedMessage}} for all nodes
having order equal to 0.
> "Invalid node order" error occurs while cycle cluster nodes restart
> ---
>
> Key: IGNITE-10935
> URL: https://issues.apache.org/jira/browse/IGNITE-10935
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Assignee: Alexey Goncharuk
>Priority: Critical
>
> Same scenario as in https://issues.apache.org/jira/browse/IGNITE-10878
> {code:java}
> Exception in thread "tcp-disco-msg-worker-#2" java.lang.AssertionError:
> Invalid node order: TcpDiscoveryNode
> [id=9a332aa3-3d60-469a-9ff5-3deee8918451, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.17.0.1, 172.25.1.40], sockAddrs=[/172.25.1.40:47501,
> /0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, /172.17.0.1:47501],
> discPort=47501, order=0, intOrder=16, lastExchangeTime=1547486771047,
> loc=false, ver=2.4.13#20190114-sha1:a7667ae6, isClient=false]
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:51)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:48)
> at org.apache.ignite.internal.util.lang.GridFunc.isAll(GridFunc.java:2030)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9635)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9608)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nodes(TcpDiscoveryNodesRing.java:625)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.visibleNodes(TcpDiscoveryNodesRing.java:145)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.notifyDiscovery(ServerImpl.java:1429)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2400(ServerImpl.java:176)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4565)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2732)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2554)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6955)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2634)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Collaps{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10866) [ML] Add an example of LogRegression model loading
[ https://issues.apache.org/jira/browse/IGNITE-10866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10866: Fix Version/s: 2.8 > [ML] Add an example of LogRegression model loading > -- > > Key: IGNITE-10866 > URL: https://issues.apache.org/jira/browse/IGNITE-10866 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Load the LogReg model from Spark via Spark ML Writable to parquet file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10935) "Invalid node order" error occurs while cycle cluster nodes restart
[
https://issues.apache.org/jira/browse/IGNITE-10935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-10935:
--
Fix Version/s: 2.8
> "Invalid node order" error occurs while cycle cluster nodes restart
> ---
>
> Key: IGNITE-10935
> URL: https://issues.apache.org/jira/browse/IGNITE-10935
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
>
> Same scenario as in https://issues.apache.org/jira/browse/IGNITE-10878
> {code:java}
> Exception in thread "tcp-disco-msg-worker-#2" java.lang.AssertionError:
> Invalid node order: TcpDiscoveryNode
> [id=9a332aa3-3d60-469a-9ff5-3deee8918451, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.17.0.1, 172.25.1.40], sockAddrs=[/172.25.1.40:47501,
> /0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, /172.17.0.1:47501],
> discPort=47501, order=0, intOrder=16, lastExchangeTime=1547486771047,
> loc=false, ver=2.4.13#20190114-sha1:a7667ae6, isClient=false]
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:51)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:48)
> at org.apache.ignite.internal.util.lang.GridFunc.isAll(GridFunc.java:2030)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9635)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9608)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nodes(TcpDiscoveryNodesRing.java:625)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.visibleNodes(TcpDiscoveryNodesRing.java:145)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.notifyDiscovery(ServerImpl.java:1429)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2400(ServerImpl.java:176)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4565)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2732)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2554)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6955)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2634)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Collaps{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10935) "Invalid node order" error occurs while cycle cluster nodes restart
[
https://issues.apache.org/jira/browse/IGNITE-10935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reassigned IGNITE-10935:
-
Assignee: Alexey Goncharuk
> "Invalid node order" error occurs while cycle cluster nodes restart
> ---
>
> Key: IGNITE-10935
> URL: https://issues.apache.org/jira/browse/IGNITE-10935
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Assignee: Alexey Goncharuk
>Priority: Critical
>
> Same scenario as in https://issues.apache.org/jira/browse/IGNITE-10878
> {code:java}
> Exception in thread "tcp-disco-msg-worker-#2" java.lang.AssertionError:
> Invalid node order: TcpDiscoveryNode
> [id=9a332aa3-3d60-469a-9ff5-3deee8918451, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.17.0.1, 172.25.1.40], sockAddrs=[/172.25.1.40:47501,
> /0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, /172.17.0.1:47501],
> discPort=47501, order=0, intOrder=16, lastExchangeTime=1547486771047,
> loc=false, ver=2.4.13#20190114-sha1:a7667ae6, isClient=false]
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:51)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:48)
> at org.apache.ignite.internal.util.lang.GridFunc.isAll(GridFunc.java:2030)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9635)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9608)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nodes(TcpDiscoveryNodesRing.java:625)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.visibleNodes(TcpDiscoveryNodesRing.java:145)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.notifyDiscovery(ServerImpl.java:1429)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2400(ServerImpl.java:176)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4565)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2732)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2554)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6955)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2634)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Collaps{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8728) "IllegalStateException: Duplicate Key" on node join
[ https://issues.apache.org/jira/browse/IGNITE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743794#comment-16743794 ] Mahesh Renduchintala commented on IGNITE-8728: -- Stan, thanks for the visibility. # Over the last year, we move from various versions of ignite 2.4, 2.5 to 2.7. I always keep work folder in tact. # Over a period of development, we might have tried to create index a second or many times on the same column on which an index already existed. Now, could that cause a confusion at ignite level, especially in a multi-node scenario? Was something out of sync? Was a check missing? # Over a period of time, we dropped the table several times and recreated the table several times and indexes. Was something stable left out in work folder. # We always used 2 or more nodes. # Over a period of time, we saw issues with index creation as well. My colleague posted another strange behaviour with index creation. See the issue here, [http://apache-ignite-users.70518.x6.nabble.com/Failing-to-create-index-on-Ignite-table-column-td26252.html#a26258] # Summary is if we don't give index names the ignite gives exceptions. Something seems to be wrong with Ignite index handling in multi-node environment. Regarding your point 2, absolutely, makes sense not to crash the node. We have about 100GB data (tables) on ignite and the only work around right now seems to be Boot node 1. Keep its work folder. Boot node 2 after removing its work folder This scenario though does not produce an issue, gives the cluster a down-time of about 1-2 hours. > "IllegalStateException: Duplicate Key" on node join > --- > > Key: IGNITE-8728 > URL: https://issues.apache.org/jira/browse/IGNITE-8728 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Mahesh Renduchintala >Priority: Critical > Attachments: NS1_ignite-9676df15.0.log, NS2_ignite-7cfc8008.0.log, > node-config.xml > > > I have two nodes on which we have 3 tables which are partitioned. Index are > also built on these tables. > For 24 hours caches work fine. The tables are definitely distributed across > both the nodes > Node 2 reboots due to some issue - goes out of the baseline - comes back and > joins the baseline. Other baseline nodes crash and in the logs we see > duplicate Key error > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > accepted incoming connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > spawning a new thread for connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] Started > serving remote node connection [rmtAddr=/192.168.1.7:45102, rmtPort=45102] > [10:38:35,451][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] > Finished serving remote node connection [rmtAddr=/192.168.1.7:45102, > rmtPort=45102 > [10:38:35,457][SEVERE][tcp-disco-msg-worker-#3|#3][TcpDiscoverySpi] > TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node > in order to prevent cluster wide instability. > *java.lang.IllegalStateException: Duplicate key* > at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223) > at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174) > at > org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114) > at > org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536) > at > org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:38:35,459][SEVERE][tcp-disco-msg-worker-#3|#3][] Critical system error > detected. Will be handled accordingly to configured handler [hnd=class > o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: > Duplicate key]] >
[jira] [Resolved] (IGNITE-10116) Document implemented design of Service Grid (redesign phase 1)
[ https://issues.apache.org/jira/browse/IGNITE-10116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur resolved IGNITE-10116. - Resolution: Done The article has been updated according to merged solution IGNITE-9607. > Document implemented design of Service Grid (redesign phase 1) > -- > > Key: IGNITE-10116 > URL: https://issues.apache.org/jira/browse/IGNITE-10116 > Project: Ignite > Issue Type: Task > Components: documentation, managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to document implemented design of Service Grid and publish in > wiki. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[
https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743778#comment-16743778
]
Ignite TC Bot commented on IGNITE-10507:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2808286buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh add ability to check crc sums of stored pages
>
>
> Key: IGNITE-10507
> URL: https://issues.apache.org/jira/browse/IGNITE-10507
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should have ability to check stored data on disk. Also we should return
> all exceptions from all nodes, if they are occurred.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8227) Research possibility and implement JUnit test failure handler for TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743775#comment-16743775 ] Ryabov Dmitrii commented on IGNITE-8227: [~dpavlov], I reworked failure handler, can you review [PR|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1000]? > Research possibility and implement JUnit test failure handler for TeamCity > -- > > Key: IGNITE-8227 > URL: https://issues.apache.org/jira/browse/IGNITE-8227 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Pavlov >Assignee: Ryabov Dmitrii >Priority: Major > > After IEP-14 > (https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling) > we found a lot of TC failures involving unexpected nodes stop. > To avoid suites exit codes, tests have NoOpFailureHandler as default. > But instead of this, better handler could be > stopNode + fail currenly running test with message. > This default allows to identify such failures without log-message fail > condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10914) Web Console: Account email should be unique
[ https://issues.apache.org/jira/browse/IGNITE-10914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-10914: --- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web Console: Account email should be unique > --- > > Key: IGNITE-10914 > URL: https://issues.apache.org/jira/browse/IGNITE-10914 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.7 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: screenshot-1.png > > Time Spent: 10m > Remaining Estimate: 0h > > I found that if user click several times on "Sign up" it will result in > several identical accounts created, but only one is allowed. > > To fix we need add unique index for "email" field and prepare migration that > will remove possible duplicates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10949) org.apache.ignite.internal.MarshallerContextImpl.CombinedMap generates NPE
[ https://issues.apache.org/jira/browse/IGNITE-10949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kalinin reassigned IGNITE-10949: --- Assignee: Andrey Kalinin > org.apache.ignite.internal.MarshallerContextImpl.CombinedMap generates NPE > -- > > Key: IGNITE-10949 > URL: https://issues.apache.org/jira/browse/IGNITE-10949 > Project: Ignite > Issue Type: Bug > Components: binary >Affects Versions: 2.7 >Reporter: Alexand Polyakov >Assignee: Andrey Kalinin >Priority: Major > Labels: newbie > > method entrySet return null then generates NullPointerException in method > hashCode, toString and all classes that use an instance of this object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10953) Cassandra examples should not use test classes
Ilya Kasnacheev created IGNITE-10953: Summary: Cassandra examples should not use test classes Key: IGNITE-10953 URL: https://issues.apache.org/jira/browse/IGNITE-10953 Project: Ignite Issue Type: Bug Components: cassandra, documentation Affects Versions: 2.7, 2.0 Reporter: Ilya Kasnacheev https://apacheignite-mix.readme.io/docs/examples "org.apache.ignite.tests.utils" are test classes, not shipped anywhere. Probably copied from tests, but should not be in examples as such examples will not run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10518) MVCC: Update operation may hangs on backup on unstable topology.
[ https://issues.apache.org/jira/browse/IGNITE-10518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743767#comment-16743767 ] Andrew Mashenkov commented on IGNITE-10518: --- I'll take a look. > MVCC: Update operation may hangs on backup on unstable topology. > - > > Key: IGNITE-10518 > URL: https://issues.apache.org/jira/browse/IGNITE-10518 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: Hanging, failover, mvcc_stabilization_stage_1 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Update operation may hangs on backup awaiting next topology. > Symptoms: > # Exchange for topology version 6.1 has been finished. > # Exchange for topology version 6.2 awaits for partition release. > # DhtTxRemote waits for exchange. > Seems, tx maps on outdated topology version. > Reproducer IgniteTxCachePrimarySyncTest.testSingleKeyCommit() in Mvcc mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10914) Web Console: Account email should be unique
[ https://issues.apache.org/jira/browse/IGNITE-10914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743766#comment-16743766 ] Pavel Konstantinov commented on IGNITE-10914: - Removing of duplicates proceeds correctly. > Web Console: Account email should be unique > --- > > Key: IGNITE-10914 > URL: https://issues.apache.org/jira/browse/IGNITE-10914 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.7 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > Attachments: screenshot-1.png > > Time Spent: 10m > Remaining Estimate: 0h > > I found that if user click several times on "Sign up" it will result in > several identical accounts created, but only one is allowed. > > To fix we need add unique index for "email" field and prepare migration that > will remove possible duplicates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8728) "IllegalStateException: Duplicate Key" on node join
[ https://issues.apache.org/jira/browse/IGNITE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-8728: --- Summary: "IllegalStateException: Duplicate Key" on node join (was: Baselined node rejoining crashes other baseline nodes - Duplicate Key Error) > "IllegalStateException: Duplicate Key" on node join > --- > > Key: IGNITE-8728 > URL: https://issues.apache.org/jira/browse/IGNITE-8728 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Mahesh Renduchintala >Priority: Critical > Attachments: NS1_ignite-9676df15.0.log, NS2_ignite-7cfc8008.0.log, > node-config.xml > > > I have two nodes on which we have 3 tables which are partitioned. Index are > also built on these tables. > For 24 hours caches work fine. The tables are definitely distributed across > both the nodes > Node 2 reboots due to some issue - goes out of the baseline - comes back and > joins the baseline. Other baseline nodes crash and in the logs we see > duplicate Key error > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > accepted incoming connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > spawning a new thread for connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] Started > serving remote node connection [rmtAddr=/192.168.1.7:45102, rmtPort=45102] > [10:38:35,451][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] > Finished serving remote node connection [rmtAddr=/192.168.1.7:45102, > rmtPort=45102 > [10:38:35,457][SEVERE][tcp-disco-msg-worker-#3|#3][TcpDiscoverySpi] > TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node > in order to prevent cluster wide instability. > *java.lang.IllegalStateException: Duplicate key* > at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223) > at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174) > at > org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114) > at > org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536) > at > org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:38:35,459][SEVERE][tcp-disco-msg-worker-#3|#3][] Critical system error > detected. Will be handled accordingly to configured handler [hnd=class > o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: > Duplicate key]] > java.lang.IllegalStateException: Duplicate key > at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223) > at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174) > at > org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114) > at > org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536) > at > org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:38:35,460][SEVERE][tcp-disco-msg-worker-#3|#3][] JVM will be halted > immediately due to the failure:
[jira] [Commented] (IGNITE-8728) Baselined node rejoining crashes other baseline nodes - Duplicate Key Error
[ https://issues.apache.org/jira/browse/IGNITE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743752#comment-16743752 ] Stanislav Lukyanov commented on IGNITE-8728: Looked at the logs. What happened is that the first node (the one that was online) tried to iterate over its own indexes when the second node joined to validate the second node's indexes. And at that time the first node detected that there is a repeating index name in its indexes - and halted because that's a totally unexpected situation. There are two issues here 1. Why were there two indexes of the same name? We need to figure out what are the steps leading to that and cover that hole. 2. The handling of the duplicate indexes is very unfortunate. The node shouldn't halt - even though we have a duplicate index name, we can try to continue to work (and probably successful) instead of just crashing. We also don't print any useful debug info. > Baselined node rejoining crashes other baseline nodes - Duplicate Key Error > --- > > Key: IGNITE-8728 > URL: https://issues.apache.org/jira/browse/IGNITE-8728 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Mahesh Renduchintala >Priority: Critical > Attachments: NS1_ignite-9676df15.0.log, NS2_ignite-7cfc8008.0.log, > node-config.xml > > > I have two nodes on which we have 3 tables which are partitioned. Index are > also built on these tables. > For 24 hours caches work fine. The tables are definitely distributed across > both the nodes > Node 2 reboots due to some issue - goes out of the baseline - comes back and > joins the baseline. Other baseline nodes crash and in the logs we see > duplicate Key error > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > accepted incoming connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > spawning a new thread for connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] Started > serving remote node connection [rmtAddr=/192.168.1.7:45102, rmtPort=45102] > [10:38:35,451][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] > Finished serving remote node connection [rmtAddr=/192.168.1.7:45102, > rmtPort=45102 > [10:38:35,457][SEVERE][tcp-disco-msg-worker-#3|#3][TcpDiscoverySpi] > TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node > in order to prevent cluster wide instability. > *java.lang.IllegalStateException: Duplicate key* > at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223) > at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174) > at > org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114) > at > org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536) > at > org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:38:35,459][SEVERE][tcp-disco-msg-worker-#3|#3][] Critical system error > detected. Will be handled accordingly to configured handler [hnd=class > o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: > Duplicate key]] > java.lang.IllegalStateException: Duplicate key > at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223) > at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174) > at > org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114) > at > org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536) > at > org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566) > at >
[jira] [Assigned] (IGNITE-10944) Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode
[ https://issues.apache.org/jira/browse/IGNITE-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov reassigned IGNITE-10944: -- Assignee: Mikhail Cherkasov > Plugin discovery data from PluginProvider.provideDiscoveryData should be > available in PluginProvider.validateNewNode > > > Key: IGNITE-10944 > URL: https://issues.apache.org/jira/browse/IGNITE-10944 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.8 > > > *Current sequence:* > > 1)Server starts (coordinator) > 2)Client starts > 3)Client sends to the coordinator its discovery data using > *provideDiscoveryData* method > 4)Coordinator start validation of the node using *validateNewNode* > 5)The client joins the cluster; otherwise fails > 6)Coordinator provides the discovery data to plugin provider in > *receiveDiscoveryData.* After that this data could be passed to the plugin. > But in case if we require to validate new node using the discovery data from > *receiveDiscoveryData* method then we should add a possibility to get this > data in *validateNewNode* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
