[jira] [Comment Edited] (IGNITE-9552) Web console: add TypeScript support
[ https://issues.apache.org/jira/browse/IGNITE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620079#comment-16620079 ] Ilya Borisov edited comment on IGNITE-9552 at 9/19/18 4:57 AM: --- [~kuaw26] please [review|https://github.com/apache/ignite/pull/4789]. was (Author: klaster_1): [~kuaw26] please review. > Web console: add TypeScript support > --- > > Key: IGNITE-9552 > URL: https://issues.apache.org/jira/browse/IGNITE-9552 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Original Estimate: 48h > Time Spent: 3.5h > Remaining Estimate: 13.75h > > What to do: > 1. ✔ Add TypeScript preset to babel config. > 2. ✔ Update webpack configs to load .ts files with babel-loader. > 3. ✔ Make sure eslint lint .ts files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9552) Web console: add TypeScript support
[ https://issues.apache.org/jira/browse/IGNITE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-9552: Assignee: Alexey Kuznetsov (was: Ilya Borisov) [~kuaw26] please review. > Web console: add TypeScript support > --- > > Key: IGNITE-9552 > URL: https://issues.apache.org/jira/browse/IGNITE-9552 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Original Estimate: 48h > Time Spent: 3.25h > Remaining Estimate: 14h > > What to do: > 1. ✔ Add TypeScript preset to babel config. > 2. ✔ Update webpack configs to load .ts files with babel-loader. > 3. ✔ Make sure eslint lint .ts files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9365) Force backups to different AWS availability zones using only Spring XML
[ https://issues.apache.org/jira/browse/IGNITE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620072#comment-16620072 ] David Harvey commented on IGNITE-9365: -- [~vkulichenko], the use case I thinking about is we have a working cluster, and a new node is added to the baseline, but it is missing the attribute. If the affinityBackupFilter throws an exception, there is nothing to catch all the way back to GridDhtPartitionsExchangeFuture.processFullMessage(), and all nodes that tries to calculate() affinity will throw that exception. For this use case, we would want to validate that the node coming online has the proper attribute set, and not discover this on an arbitrary node. I don't have a complete enough understanding to know where that validation should go. A more promising approach is to not allow a node with a null attribute to service _either_ the primary or backup. That is, if you configure a cache with an affinityBackupFilter, the set of nodes that can service that cache will be limited to nodes that will not throw an exception if the filter is given the node and a list of nodes only containing that node. I don't yet see how to handle the case where no nodes have the attribute, however. > Force backups to different AWS availability zones using only Spring XML > --- > > Key: IGNITE-9365 > URL: https://issues.apache.org/jira/browse/IGNITE-9365 > Project: Ignite > Issue Type: Improvement > Components: cache > Environment: >Reporter: David Harvey >Assignee: David Harvey >Priority: Minor > Fix For: 2.7 > > Attachments: master_947962f785_availability_zones_via_spring.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > As a developer, I want to be able to force cache backups each to a different > "Availability Zone", when I'm running out-of-the-box Ignite, without > additional Jars installed. "Availability zone" is a AWS feature with > different names for the same function by other cloud providers. A single > availability zone has the characteristic that some or all of the EC2 > instances in that zone can fail together due to a single fault. You have no > control over the hosts on which the EC2 instance VMs run on in AWS, except by > controlling the availability zone . > > I could write a few lines of a custom affinityBackupFilter, and configure it > a RendezvousAffinityFunction, but then I have to get it deployed on all nodes > in the cluster, and peer class loading will not work to this. The code to > do this should just be part of Ignite. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9609) Web console: update to AngularJS 1.7.4
[ https://issues.apache.org/jira/browse/IGNITE-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9609: - Fix Version/s: 2.7 > Web console: update to AngularJS 1.7.4 > -- > > Key: IGNITE-9609 > URL: https://issues.apache.org/jira/browse/IGNITE-9609 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.7 > > Time Spent: 56m > Remaining Estimate: 0h > > Let's update package-.json to use AngularJS 1.7.4, the 1.7.3 release > introduced some interesting new feature we might use (like extra form methods > and arbitrary event/property bindings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9609) Web console: update to AngularJS 1.7.4
[ https://issues.apache.org/jira/browse/IGNITE-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9609: - Ignite Flags: (was: Docs Required) > Web console: update to AngularJS 1.7.4 > -- > > Key: IGNITE-9609 > URL: https://issues.apache.org/jira/browse/IGNITE-9609 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.7 > > Time Spent: 56m > Remaining Estimate: 0h > > Let's update package-.json to use AngularJS 1.7.4, the 1.7.3 release > introduced some interesting new feature we might use (like extra form methods > and arbitrary event/property bindings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9552) Web console: add TypeScript support
[ https://issues.apache.org/jira/browse/IGNITE-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-9552: - Description: What to do: 1. ✔ Add TypeScript preset to babel config. 2. ✔ Update webpack configs to load .ts files with babel-loader. 3. ✔ Make sure eslint lint .ts files was: What to do: 1. Add TypeScript preset to babel config. 2. Update webpack configs to load .ts files with babel-loader. 3. Make sure eslint lint .ts files > Web console: add TypeScript support > --- > > Key: IGNITE-9552 > URL: https://issues.apache.org/jira/browse/IGNITE-9552 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Original Estimate: 48h > Time Spent: 3.25h > Remaining Estimate: 14h > > What to do: > 1. ✔ Add TypeScript preset to babel config. > 2. ✔ Update webpack configs to load .ts files with babel-loader. > 3. ✔ Make sure eslint lint .ts files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9365) Force backups to different AWS availability zones using only Spring XML
[ https://issues.apache.org/jira/browse/IGNITE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619842#comment-16619842 ] Valentin Kulichenko commented on IGNITE-9365: - [~syssoftsol], I don't think there is a precedent as we don't have any out of the box backup filter implementations, but in general a filter can throw any exception. As a matter of fact, I think it definitely should in case of misconfiguration. If data affinity doesn't work correctly, there is no reason to continue. And I'm absolutely against logging only option for that particular reason. Can you clarify why you think we would need rework of the function itself if we throw an exception? Is there a scenario when it doesn't behave properly? If so, do you have a test demonstrating this? > Force backups to different AWS availability zones using only Spring XML > --- > > Key: IGNITE-9365 > URL: https://issues.apache.org/jira/browse/IGNITE-9365 > Project: Ignite > Issue Type: Improvement > Components: cache > Environment: >Reporter: David Harvey >Assignee: David Harvey >Priority: Minor > Fix For: 2.7 > > Attachments: master_947962f785_availability_zones_via_spring.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > As a developer, I want to be able to force cache backups each to a different > "Availability Zone", when I'm running out-of-the-box Ignite, without > additional Jars installed. "Availability zone" is a AWS feature with > different names for the same function by other cloud providers. A single > availability zone has the characteristic that some or all of the EC2 > instances in that zone can fail together due to a single fault. You have no > control over the hosts on which the EC2 instance VMs run on in AWS, except by > controlling the availability zone . > > I could write a few lines of a custom affinityBackupFilter, and configure it > a RendezvousAffinityFunction, but then I have to get it deployed on all nodes > in the cluster, and peer class loading will not work to this. The code to > do this should just be part of Ignite. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[ https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6044: Fix Version/s: 2.7 > SQL insert waits for transaction commit, but it must be executed right away > --- > > Key: IGNITE-6044 > URL: https://issues.apache.org/jira/browse/IGNITE-6044 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Assignee: Yury Gerzhedovich >Priority: Critical > Labels: sql-stability, usability > Fix For: 2.7 > > > Doc says: > ""Presently, DML supports the atomic mode only meaning that if there is a DML > query that is executed as a part of an Ignite transaction then it will not be > enlisted in the transaction's writing queue and will be executed right away."" > https://apacheignite.readme.io/docs/dml#section-transactional-support > However the data will be added to cache only after transaction commit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8485) TDE - Phase-1
[
https://issues.apache.org/jira/browse/IGNITE-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619628#comment-16619628
]
Vladimir Ozerov commented on IGNITE-8485:
-
Hi [~NIzhikov], my comments:
First part of comments relate to public API only:
1) EncryptionSpi should be located inside o.a.i.spi.encryption package for
consistency with other SPIs
2) Please add package-info files to new public packages (o.a.i.spi.encryption,
o.a.i.spi.encryption.jks)
3) I would rename "jks" package to "keystore" to have consistency between
package and class names (as in most other SPIs)
4) Same thing for EncryptionKey -> KeystoreEncryptionKey
5) NoopEncryptionSpi should either be removed completely (manager could be used
to check if encryption is enabled), or moved to "noop" package (with
package-info). I vote for removal - no need to add useless classes to public
API.
6) IEncryptionSpi - dotnetdocs are missing
7) Apache.Ignite.Core.Encryption.Aes namespace should be renamed to
Apache.Ignite.Core.Encryption.Keystore
Internals:
1) GridComponent.DiscoveryDataExchangeType.ENCRYPTION_MGR - I think it is
better to move it after CACHE_CRD_PROC for safety.
2) GridEncryptionManager.start/stop - no need to write debug log, as it is
already written in startSpi/stopSpi methods
3) GridEncryptionManager.onKernalStart0 - this is too late to register
listeners, as IO and discovery is already active at this point. Things like
this should be prepared on start() stage.
4) GridEncryptionManager.onKernalStart0 - I cannot understand why we are
listening to {{ctx.discovery().localJoinFuture().listen}} here. Could you
please clarify?
5) GridEncryptionManager - checks for {{notCoordinator()}} looks strange to me.
I do not see any cases where current coordinator should do anything else than
other nodes. All of them are equal. The only thing we need is to agree on
encryption key, which should happen on all nodes in the same place - during
cache creation inside exchange thread.
All in all, looks like we need to do some clean up in API and in manager.
Also I would like to ask persistence experts to throw a glance at
storage-related code (WAL, IOs, etc). [~agoncharuk], could you please do that
or suggest someone else, who can help us?
> TDE - Phase-1
> -
>
> Key: IGNITE-8485
> URL: https://issues.apache.org/jira/browse/IGNITE-8485
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Critical
> Fix For: 2.7
>
>
> Basic support for a Transparent Data Encryption should be implemented:
> 1. Usage of standard JKS, Java Security.
> 2. Persistent Data Encryption/Decryption.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9514) [ML] Reduce time for the updating models on many partitions
[ https://issues.apache.org/jira/browse/IGNITE-9514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619517#comment-16619517 ] ASF GitHub Bot commented on IGNITE-9514: GitHub user zaleslaw opened a pull request: https://github.com/apache/ignite/pull/4788 IGNITE-9514: Refactor tests and common test time You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9514 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4788.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4788 commit 8d20b3ec8889cd4628866e7f70ff41d3790a0adb Author: Zinoviev Alexey Date: 2018-09-18T16:32:59Z Reduce amount of partitions commit da1ffa0eb9f78d7b83698a9ecbb05fcc348eaaba Author: Zinoviev Alexey Date: 2018-09-18T17:53:56Z Fixed codestyle in tests commit 924060adfc49b94fc788dd95a270947a4622b0a9 Author: Zinoviev Alexey Date: 2018-09-18T18:21:03Z Refactor Trainer tests > [ML] Reduce time for the updating models on many partitions > --- > > Key: IGNITE-9514 > URL: https://issues.apache.org/jira/browse/IGNITE-9514 > Project: Ignite > Issue Type: Task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619398#comment-16619398
]
Andrey Kuznetsov commented on IGNITE-8570:
--
Thanks, [~xtern]. I'll examine your change in a day.
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.7
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression, {{Matcher}} can be passed to the listener
>
> _+Proposed design+_, pseudocode:
> ```
> Class GridRegexpLogger implements IgniteLogger{
> …
> debug(String str){
> if (/* str matches pattern. */)
> \{ /* notify listeners. */ }
> }
> …
> listen("regexp", IgniteInClosure loggerListener)// listener receives
> message
> { /* registers listener. */ }
> listenDebug("regexp", loggerListener)
> { /* registers listener for debug output only. */ }
> …
> }
> ```
> +_Sample regexp logger usage_+:
> ```
> GridRegexpLogger logger;
> logger.listen(“regexp”, new GridRegexpListener());
> logger.listenDebug("regexp", new GridRegexpListener());
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-8570:
Assignee: Pavel Pereslegin (was: Alexey Kuznetsov)
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.7
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression, {{Matcher}} can be passed to the listener
>
> _+Proposed design+_, pseudocode:
> ```
> Class GridRegexpLogger implements IgniteLogger{
> …
> debug(String str){
> if (/* str matches pattern. */)
> \{ /* notify listeners. */ }
> }
> …
> listen("regexp", IgniteInClosure loggerListener)// listener receives
> message
> { /* registers listener. */ }
> listenDebug("regexp", loggerListener)
> { /* registers listener for debug output only. */ }
> …
> }
> ```
> +_Sample regexp logger usage_+:
> ```
> GridRegexpLogger logger;
> logger.listen(“regexp”, new GridRegexpListener());
> logger.listenDebug("regexp", new GridRegexpListener());
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619388#comment-16619388
]
Pavel Pereslegin commented on IGNITE-8570:
--
Hello [~andrey-kuznetsov].
I had a private talk with [~Alexey Kuznetsov], and he didn't mind that I will
continue to work on this ticket.
I would like to simplify the API and keep only one method to register the
listener:
{{listen("expression", IgniteInClosure listener)}}
For debugging purposes there is a {{debug}} flag, that enables debug/trace
messages checking.
Please take a look at my PR (4786).
I added link to upsource review.
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression, {{Matcher}} can be passed to the listener
>
> _+Proposed design+_, pseudocode:
> ```
> Class GridRegexpLogger implements IgniteLogger{
> …
> debug(String str){
> if (/* str matches pattern. */)
> \{ /* notify listeners. */ }
> }
> …
> listen("regexp", IgniteInClosure loggerListener)// listener receives
> message
> { /* registers listener. */ }
> listenDebug("regexp", loggerListener)
> { /* registers listener for debug output only. */ }
> …
> }
> ```
> +_Sample regexp logger usage_+:
> ```
> GridRegexpLogger logger;
> logger.listen(“regexp”, new GridRegexpListener());
> logger.listenDebug("regexp", new GridRegexpListener());
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8427) Apache ignite unable to connect to a minor upgrade version
[
https://issues.apache.org/jira/browse/IGNITE-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619358#comment-16619358
]
Pavel Pereslegin commented on IGNITE-8427:
--
Hello [~Kinny],
According to recent [devlist
discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Minor-version-changes-and-server-client-compatibility-tp34757p34905.html]:
{quote}
Ignite should be maintains (according to review checklist [1]):
- binary compatibility for persistence store between minor releases;
- JDBC and ODBC and thin client protocol forward and backward compatibility
between two consecutive minor releases;
[1] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
{quote}
You can join this or another compatibility discussion (if you have not already
done so).
p.s. sorry for the late reply.
> Apache ignite unable to connect to a minor upgrade version
> --
>
> Key: IGNITE-8427
> URL: https://issues.apache.org/jira/browse/IGNITE-8427
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3, 2.4
>Reporter: Arvindo
>Priority: Major
>
> We have a distributed cache cluster, say with 2.3.0 in the cluster. We have
> cache clients connecting to the cluster in client mode (clientMode=true).
> When we upgrade the cluster to 2.4.0 (minor version). The clients are unable
> to connect to the new cluster. Apache ignite is not following semantic
> versioning standard, forcing the clients to upgrade their binaries for minor
> upgrades.
> [semantic MINOR release version standards|https://semver.org/].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7855) ODBC: Support streaming mode
[
https://issues.apache.org/jira/browse/IGNITE-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619301#comment-16619301
]
Taras Ledkov edited comment on IGNITE-7855 at 9/18/18 3:46 PM:
---
[~isapego], my comments:
# Please review my minor changes of the codestyle and typos;
# Please add javadoc for {{OdbcRequestHandler#extractBatchError}},
{{OdbcQuery#(read|write)Binary}} ;
# {{OdbcQuery#OdbcQuery(java.lang.String, java.lang.Object[])}} not used;
# Please fix typo: {{SqlLexer::IsDelimeter}}->{{SqlLexer::IsDelimiter}}.
# Looks like the lexer doesn't handle quotas inside a STRING constant, e.g.
{{'I''m, OK with it.'}}. I guess the test {{LexerTokens}} is invalid:
"{{string with 'string quotes' inside}}" must be expected for SQL string
{{"'string with ''string quotes'' inside'"}}. However, this functionality is
not used in current implementation. It is not major issue.
was (Author: tledkov-gridgain):
[~isapego], my comments:
# Please review my minor changes of the codestyle;
# Please add javadoc for {{OdbcRequestHandler#extractBatchError}},
{{OdbcQuery#(read|write)Binary}} ;
# {{OdbcQuery#OdbcQuery(java.lang.String, java.lang.Object[])}} not used;
# Please fix typo: {{SqlLexer::IsDelimeter}}->{{SqlLexer::IsDelimiter}}.
# Looks like the lexer doesn't handle quotas inside a STRING constant, e.g.
{{'I''m, OK with it.'}}. I guess the test {{LexerTokens}} is invalid:
"{{string with 'string quotes' inside}}" must be expected for SQL string
{{"'string with ''string quotes'' inside'"}}. However, this functionality is
not used in current implementation. It is not major issue.
> ODBC: Support streaming mode
>
>
> Key: IGNITE-7855
> URL: https://issues.apache.org/jira/browse/IGNITE-7855
> Project: Ignite
> Issue Type: New Feature
> Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.7
>
>
> We need to support streaming mode in the same way it is done for JDBC.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7855) ODBC: Support streaming mode
[
https://issues.apache.org/jira/browse/IGNITE-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619301#comment-16619301
]
Taras Ledkov commented on IGNITE-7855:
--
[~isapego], my comments:
# Please review my minor changes of the codestyle;
# Please add javadoc for {{OdbcRequestHandler#extractBatchError}},
{{OdbcQuery#(read|write)Binary}} ;
# {{OdbcQuery#OdbcQuery(java.lang.String, java.lang.Object[])}} not used;
# Please fix typo: {{SqlLexer::IsDelimeter}}->{{SqlLexer::IsDelimiter}}.
# Looks like the lexer doesn't handle quotas inside a STRING constant, e.g.
{{'I''m, OK with it.'}}. I guess the test {{LexerTokens}} is invalid:
"{{string with 'string quotes' inside}}" must be expected for SQL string
{{"'string with ''string quotes'' inside'"}}. However, this functionality is
not used in current implementation. It is not major issue.
> ODBC: Support streaming mode
>
>
> Key: IGNITE-7855
> URL: https://issues.apache.org/jira/browse/IGNITE-7855
> Project: Ignite
> Issue Type: New Feature
> Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.7
>
>
> We need to support streaming mode in the same way it is done for JDBC.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9639) Flaky failure of SqlSystemViewsSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619287#comment-16619287
]
ASF GitHub Bot commented on IGNITE-9639:
GitHub user alex-plekhanov opened a pull request:
https://github.com/apache/ignite/pull/4787
IGNITE-9639 Flaky failure of SqlSystemViewsSelfTest
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/alex-plekhanov/ignite ignite-9639
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4787.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4787
commit 80715bf1e721e9c72b98d7764d57aff8e0a5570a
Author: Aleksey Plekhanov
Date: 2018-09-18T15:24:08Z
IGNITE-9639 Flaky failure of SqlSystemViewsSelfTest
commit b836a154864dbbd2edaaf97c5728a09f0fce4c9a
Author: Aleksey Plekhanov
Date: 2018-09-18T15:26:10Z
IGNITE-9639 For TC run
> Flaky failure of SqlSystemViewsSelfTest
>
>
> Key: IGNITE-9639
> URL: https://issues.apache.org/jira/browse/IGNITE-9639
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, iep-13
>
> SqlSystemViewsSelfTest fails sometimes with the following error:
> {noformat}
> [2018-09-18 08:23:56,275][ERROR][main][root] Test failed.
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to register MBean for component:
> org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@58f7fe1b
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1326)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3161)
> at
> org.apache.ignite.internal.processors.query.SqlSystemViewsSelfTest.execSql(SqlSystemViewsSelfTest.java:76)
> at
> org.apache.ignite.internal.processors.query.SqlSystemViewsSelfTest.testNodesViews(SqlSystemViewsSelfTest.java:386)
> 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.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to register
> MBean for component:
> org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@58f7fe1b
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:4312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1727)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1982)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:439)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:633)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:379)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2393)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2529)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> ... 1 more
> Caused by: javax.management.InstanceAlreadyExistsException:
> org.apache:clsLdr=5c080ef3,igniteInstanceName=query.SqlSystemViewsSelfTest1,group=default,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at
>
[jira] [Created] (IGNITE-9640) [TC Bot] Determine repetitive failure types by analyzing build log
Andrey Kuznetsov created IGNITE-9640:
Summary: [TC Bot] Determine repetitive failure types by analyzing
build log
Key: IGNITE-9640
URL: https://issues.apache.org/jira/browse/IGNITE-9640
Project: Ignite
Issue Type: Task
Reporter: Andrey Kuznetsov
When someone is analyzing flaky test failure, it's important to distinguish
between newly created failure and pre-existing one. In the latter case, the bot
should not attract contributor's attention to the test.
In more detail, TC build log fragments starts with identical substrings for
identical failures very often, e.g.
{noformat}
junit.framework.AssertionFailedError
at
org.apache.ignite.internal.GridVersionSelfTest.testVersions(GridVersionSelfTest.java:54)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9631) Timeouts in ZookeeperDIscoverySpi test suite
[ https://issues.apache.org/jira/browse/IGNITE-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619269#comment-16619269 ] ASF GitHub Bot commented on IGNITE-9631: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4782 > Timeouts in ZookeeperDIscoverySpi test suite > > > Key: IGNITE-9631 > URL: https://issues.apache.org/jira/browse/IGNITE-9631 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Sometimes this test suite times out. Failed test examples: > [https://ci.ignite.apache.org/viewLog.html?buildId=1862120=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] > [https://ci.ignite.apache.org/viewLog.html?buildId=1839809=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] > It seems that test class GridCachePartitionedNodeRestartTest times out and > block all suite. > We need to add timeouts into test for suite timeouts preventing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[ https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619270#comment-16619270 ] Uday Kale commented on IGNITE-9532: --- [~avinogradov] I have updated the PR. I am just doubtful of my changes to GridCacheQueueProxy#withKeepBinary(). > Binary mode for Ignite Queue > > > Key: IGNITE-9532 > URL: https://issues.apache.org/jira/browse/IGNITE-9532 > Project: Ignite > Issue Type: New Feature > Components: binary, data structures >Reporter: Uday Kale >Assignee: Uday Kale >Priority: Major > Fix For: 2.8 > > > Add binary mode (withKeepBinary) to Data Structures Queue. > This will allow retrieving values in binary format when needed or when class > is not available, and will allow implementing the structures in other > platforms (.NET, C++). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9631) Timeouts in ZookeeperDIscoverySpi test suite
[ https://issues.apache.org/jira/browse/IGNITE-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9631: - Fix Version/s: 2.7 > Timeouts in ZookeeperDIscoverySpi test suite > > > Key: IGNITE-9631 > URL: https://issues.apache.org/jira/browse/IGNITE-9631 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Sometimes this test suite times out. Failed test examples: > [https://ci.ignite.apache.org/viewLog.html?buildId=1862120=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] > [https://ci.ignite.apache.org/viewLog.html?buildId=1839809=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] > It seems that test class GridCachePartitionedNodeRestartTest times out and > block all suite. > We need to add timeouts into test for suite timeouts preventing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9639) Flaky failure of SqlSystemViewsSelfTest
Aleksey Plekhanov created IGNITE-9639:
-
Summary: Flaky failure of SqlSystemViewsSelfTest
Key: IGNITE-9639
URL: https://issues.apache.org/jira/browse/IGNITE-9639
Project: Ignite
Issue Type: Task
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
SqlSystemViewsSelfTest fails sometimes with the following error:
{noformat}
[2018-09-18 08:23:56,275][ERROR][main][root] Test failed.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to register MBean for component:
org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@58f7fe1b
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1326)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3161)
at
org.apache.ignite.internal.processors.query.SqlSystemViewsSelfTest.execSql(SqlSystemViewsSelfTest.java:76)
at
org.apache.ignite.internal.processors.query.SqlSystemViewsSelfTest.testNodesViews(SqlSystemViewsSelfTest.java:386)
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.runTestInternal(GridAbstractTest.java:2177)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to register
MBean for component:
org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@58f7fe1b
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:4312)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1727)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1982)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:439)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:633)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:379)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2393)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2529)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
... 1 more
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache:clsLdr=5c080ef3,igniteInstanceName=query.SqlSystemViewsSelfTest1,group=default,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at
org.apache.ignite.internal.util.IgniteUtils.registerMBean(IgniteUtils.java:4614)
at
org.apache.ignite.internal.util.IgniteUtils.registerMBean(IgniteUtils.java:4585)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:4308)
... 10 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9026) Two levels of Peer class loading fails in CONTINUOUS mode
[ https://issues.apache.org/jira/browse/IGNITE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619224#comment-16619224 ] Ryabov Dmitrii edited comment on IGNITE-9026 at 9/18/18 2:58 PM: - Hello, [~syssoftsol]. I left some comments about [coding style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines] in [upsource|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-864]. Also, I started test on [TeamCity|https://ci.ignite.apache.org/viewQueued.html?itemId=1900650=queuedBuildOverviewTab]. Please, start "Run All" tests for your tickets and check them before going Patch Available. was (Author: somefire): Hello, [~syssoftsol]. I left some comments about [coding style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines] in [upsource|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-864]. > Two levels of Peer class loading fails in CONTINUOUS mode > - > > Key: IGNITE-9026 > URL: https://issues.apache.org/jira/browse/IGNITE-9026 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: David Harvey >Assignee: David Harvey >Priority: Major > Attachments: master_1b3742f4d7_p2p_two_hops.patch > > > We had an seemingly functional system in SHARED_MODE, where we have a custom > StreamReceiver that sometimes sends closures on the peer class loaded code to > other servers. However, we ended up running out of Metaspace, because we had > > 6000 class loaders! We suspected a regression in this change > [https://github.com/apache/ignite/commit/d2050237ee2b760d1c9cbc906b281790fd0976b4#diff-3fae20691c16a617d0c6158b0f61df3c], > so we switched to CONTINUOUS mode. We then started getting failures to > load some of the classes for the closures on the second server. Through > some testing and code inspection, there seems to be the following flaws > between GridDeploymentCommunication.sendResourceRequest and its two callers. > The callers iterate though all the participant nodes until they find an > online node that responds to the request (timeout is treated as offline > node), with either success or failure, and then the loop terminates. The > assumption is that all nodes are equally capable of providing the resource, > so if one fails, then the others would also fail. > The first flaw is that GridDeploymentCommunication.sendResourceRequest() has > a check for a cycle, i.e., whether the destination node is one of the nodes > that originated or forwarded this request, and in that case, a failure > response is faked. However, that causes the caller's loop to terminate. So > depending on the order of the nodes in the participant list, > sendResourceRequest() may fail before trying any nodes because it has one of > the calling nodes on this list. It should instead be skipping any of the > calling nodes. > Example with 1 client node a 2 server nodes: C1 sends data to S1, which > forwards closure to S2. C1 also sends to S2 which forwards to S1. So now > the node lists on S1 and S2 contain C1 and the other S node. If the order > of the node lists on S1 is (S2,C1) and on S2 (S1,C1), then when S1 tries to > load a class, it will try S2, then S2 will try S1, but will get a fake > failure generated, causing S2 not to try more nodes (i.e., C1), and causing > S1 also not to try more nodes. > The other flaw is the assumption that all participants have equal access to > the resource. Assume S1 knows about userVersion1 via S3 and S4, with S3 > though C1 and S4 through C2. If C2 fails, then S4 is not capable of getting > back to a master, but S1 has no way of knowing that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9589) GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619226#comment-16619226
]
Alexey Goncharuk commented on IGNITE-9589:
--
[~NSAmelchev], can we change the discovery port to a different base (say, +1000
ports) if we encounter this exception instead of sleep? I would like not to
waste 1 minute of test time at worst when we can have a faster solution.
> GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
> ---
>
> Key: IGNITE-9589
> URL: https://issues.apache.org/jira/browse/IGNITE-9589
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange fails
> periodicaly.
> From the logs, I see that the failure is caused by BindException. It causes
> node start fails because the test port range is 0.
> {noformat}
> [2018-09-13
> 04:06:20,060][ERROR][test-runner-#225862%tcp.GridTcpCommunicationSpiConfigSelfTest%][GridTcpCommunicationSpiConfigSelfTest]
> Failed to start manager: GridManagerAdapter [enabled=true,
> name=o.a.i.i.managers.communication.GridIoManager]
> class org.apache.ignite.IgniteCheckedException: Failed to get SPI attributes.
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:262)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1755)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:975)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:673)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:598)
> at org.apache.ignite.Ignition.start(Ignition.java:323)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1370)
> at
> org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange(GridTcpCommunicationSpiConfigSelfTest.java:65)
> 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.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize TCP server: 0.0.0.0/0.0.0.0
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2137)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:261)
> ... 20 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind to
> any port within range [startPort=47100, portRange=0, locHost=0.0.0.0/0.0.0.0]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2450)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2134)
> ... 21 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> initialize NIO selector.
> at
> org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:988)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:342)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:97)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$Builder.build(GridNioServer.java:3669)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2415)
> ... 22 more
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
[jira] [Commented] (IGNITE-9026) Two levels of Peer class loading fails in CONTINUOUS mode
[ https://issues.apache.org/jira/browse/IGNITE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619224#comment-16619224 ] Ryabov Dmitrii commented on IGNITE-9026: Hello, [~syssoftsol]. I left some comments about [coding style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines] in [upsource|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-864]. > Two levels of Peer class loading fails in CONTINUOUS mode > - > > Key: IGNITE-9026 > URL: https://issues.apache.org/jira/browse/IGNITE-9026 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: David Harvey >Assignee: David Harvey >Priority: Major > Attachments: master_1b3742f4d7_p2p_two_hops.patch > > > We had an seemingly functional system in SHARED_MODE, where we have a custom > StreamReceiver that sometimes sends closures on the peer class loaded code to > other servers. However, we ended up running out of Metaspace, because we had > > 6000 class loaders! We suspected a regression in this change > [https://github.com/apache/ignite/commit/d2050237ee2b760d1c9cbc906b281790fd0976b4#diff-3fae20691c16a617d0c6158b0f61df3c], > so we switched to CONTINUOUS mode. We then started getting failures to > load some of the classes for the closures on the second server. Through > some testing and code inspection, there seems to be the following flaws > between GridDeploymentCommunication.sendResourceRequest and its two callers. > The callers iterate though all the participant nodes until they find an > online node that responds to the request (timeout is treated as offline > node), with either success or failure, and then the loop terminates. The > assumption is that all nodes are equally capable of providing the resource, > so if one fails, then the others would also fail. > The first flaw is that GridDeploymentCommunication.sendResourceRequest() has > a check for a cycle, i.e., whether the destination node is one of the nodes > that originated or forwarded this request, and in that case, a failure > response is faked. However, that causes the caller's loop to terminate. So > depending on the order of the nodes in the participant list, > sendResourceRequest() may fail before trying any nodes because it has one of > the calling nodes on this list. It should instead be skipping any of the > calling nodes. > Example with 1 client node a 2 server nodes: C1 sends data to S1, which > forwards closure to S2. C1 also sends to S2 which forwards to S1. So now > the node lists on S1 and S2 contain C1 and the other S node. If the order > of the node lists on S1 is (S2,C1) and on S2 (S1,C1), then when S1 tries to > load a class, it will try S2, then S2 will try S1, but will get a fake > failure generated, causing S2 not to try more nodes (i.e., C1), and causing > S1 also not to try more nodes. > The other flaw is the assumption that all participants have equal access to > the resource. Assume S1 knows about userVersion1 via S3 and S4, with S3 > though C1 and S4 through C2. If C2 fails, then S4 is not capable of getting > back to a master, but S1 has no way of knowing that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7855) ODBC: Support streaming mode
[ https://issues.apache.org/jira/browse/IGNITE-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-7855: Issue Type: New Feature (was: Task) > ODBC: Support streaming mode > > > Key: IGNITE-7855 > URL: https://issues.apache.org/jira/browse/IGNITE-7855 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Vladimir Ozerov >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > We need to support streaming mode in the same way it is done for JDBC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8855) Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is significantly smaller than number of clients
[
https://issues.apache.org/jira/browse/IGNITE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619206#comment-16619206
]
Ignite TC Bot commented on IGNITE-8855:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1890883buildTypeId=IgniteTests24Java8_RunAll]
> Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is
> significantly smaller than number of clients
>
>
> Key: IGNITE-8855
> URL: https://issues.apache.org/jira/browse/IGNITE-8855
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.7
>
>
> After fixing client nodes hangs in IGNITE-8657 another issue was found out:
> when EXCHANGE_HISTORY is significantly smaller than number of clients they
> interfere with each other on initial exchange and make reconnect attempts
> over and over again.
> To avoid this random delay (maybe exponential) should be added for clients
> before making new reconnect attempt.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9589) GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-9589:
-
Ignite Flags: (was: Docs Required)
> GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
> ---
>
> Key: IGNITE-9589
> URL: https://issues.apache.org/jira/browse/IGNITE-9589
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange fails
> periodicaly.
> From the logs, I see that the failure is caused by BindException. It causes
> node start fails because the test port range is 0.
> {noformat}
> [2018-09-13
> 04:06:20,060][ERROR][test-runner-#225862%tcp.GridTcpCommunicationSpiConfigSelfTest%][GridTcpCommunicationSpiConfigSelfTest]
> Failed to start manager: GridManagerAdapter [enabled=true,
> name=o.a.i.i.managers.communication.GridIoManager]
> class org.apache.ignite.IgniteCheckedException: Failed to get SPI attributes.
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:262)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1755)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:975)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:673)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:598)
> at org.apache.ignite.Ignition.start(Ignition.java:323)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1370)
> at
> org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange(GridTcpCommunicationSpiConfigSelfTest.java:65)
> 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.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize TCP server: 0.0.0.0/0.0.0.0
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2137)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:261)
> ... 20 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind to
> any port within range [startPort=47100, portRange=0, locHost=0.0.0.0/0.0.0.0]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2450)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2134)
> ... 21 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> initialize NIO selector.
> at
> org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:988)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:342)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:97)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$Builder.build(GridNioServer.java:3669)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2415)
> ... 22 more
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at
[jira] [Commented] (IGNITE-9330) Multiple CacheMetricsManageTest tests are failing
[ https://issues.apache.org/jira/browse/IGNITE-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619197#comment-16619197 ] ASF GitHub Bot commented on IGNITE-9330: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4738 > Multiple CacheMetricsManageTest tests are failing > - > > Key: IGNITE-9330 > URL: https://issues.apache.org/jira/browse/IGNITE-9330 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Amelchev Nikita >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > testCacheManagerStatisticsEnable and testClusterApiClearStatistics fail every > so often, such as in > https://ci.ignite.apache.org/viewLog.html?buildId=1676464 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619183#comment-16619183
]
ASF GitHub Bot commented on IGNITE-8570:
GitHub user xtern opened a pull request:
https://github.com/apache/ignite/pull/4786
IGNITE-8570
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/xtern/ignite IGNITE-8570
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4786.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4786
commit d9bcad3752feb73988576fb4cc5181c5a7baff0d
Author: voipp
Date: 2018-06-28T20:14:54Z
logger implemented
commit cbb1442ac9cf3a01fad3b7690cc1266ec6f61b55
Author: voipp
Date: 2018-07-05T16:18:52Z
added listener for null-regexp. Removed waitFor
commit 53e4dd678376f0a5a530921e033660bee95f0787
Author: pereslegin-pa
Date: 2018-09-18T13:41:52Z
IGNITE-8570 Code cleanup.
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression, {{Matcher}} can be passed to the listener
>
> _+Proposed design+_, pseudocode:
> ```
> Class GridRegexpLogger implements IgniteLogger{
> …
> debug(String str){
> if (/* str matches pattern. */)
> \{ /* notify listeners. */ }
> }
> …
> listen("regexp", IgniteInClosure loggerListener)// listener receives
> message
> { /* registers listener. */ }
> listenDebug("regexp", loggerListener)
> { /* registers listener for debug output only. */ }
> …
> }
> ```
> +_Sample regexp logger usage_+:
> ```
> GridRegexpLogger logger;
> logger.listen(“regexp”, new GridRegexpListener());
> logger.listenDebug("regexp", new GridRegexpListener());
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9330) Multiple CacheMetricsManageTest tests are failing
[ https://issues.apache.org/jira/browse/IGNITE-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9330: - Ignite Flags: (was: Docs Required) > Multiple CacheMetricsManageTest tests are failing > - > > Key: IGNITE-9330 > URL: https://issues.apache.org/jira/browse/IGNITE-9330 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Amelchev Nikita >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > testCacheManagerStatisticsEnable and testClusterApiClearStatistics fail every > so often, such as in > https://ci.ignite.apache.org/viewLog.html?buildId=1676464 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9638) .Net: JVM keeps track of CLR Threads, even when they are finished
[ https://issues.apache.org/jira/browse/IGNITE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9638: Attachment: IgniteRepro.zip > .Net: JVM keeps track of CLR Threads, even when they are finished > -- > > Key: IGNITE-9638 > URL: https://issues.apache.org/jira/browse/IGNITE-9638 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Priority: Major > Attachments: IgniteRepro.zip > > > When you create a Thread in C#, JVM creates corresponding thread > "Thread-" which is visible in jstack. When C# joins this thread, it is > not removed from JVM and is kept around. This means that jstack may show > thousands of threads which are not there. Reproducer is attached. It is > presumed that memory will be exhausted eventually. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9638) .Net: JVM keeps track of CLR Threads, even when they are finished
Ilya Kasnacheev created IGNITE-9638: --- Summary: .Net: JVM keeps track of CLR Threads, even when they are finished Key: IGNITE-9638 URL: https://issues.apache.org/jira/browse/IGNITE-9638 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.6 Reporter: Ilya Kasnacheev When you create a Thread in C#, JVM creates corresponding thread "Thread-" which is visible in jstack. When C# joins this thread, it is not removed from JVM and is kept around. This means that jstack may show thousands of threads which are not there. Reproducer is attached. It is presumed that memory will be exhausted eventually. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9638) .Net: JVM keeps track of CLR Threads, even when they are finished
[ https://issues.apache.org/jira/browse/IGNITE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9638: Issue Type: Bug (was: Improvement) > .Net: JVM keeps track of CLR Threads, even when they are finished > -- > > Key: IGNITE-9638 > URL: https://issues.apache.org/jira/browse/IGNITE-9638 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Priority: Major > > When you create a Thread in C#, JVM creates corresponding thread > "Thread-" which is visible in jstack. When C# joins this thread, it is > not removed from JVM and is kept around. This means that jstack may show > thousands of threads which are not there. Reproducer is attached. It is > presumed that memory will be exhausted eventually. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8717) Move persisted cache configuration to metastore
[ https://issues.apache.org/jira/browse/IGNITE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reassigned IGNITE-8717: -- Assignee: Sergey Antonov > Move persisted cache configuration to metastore > --- > > Key: IGNITE-8717 > URL: https://issues.apache.org/jira/browse/IGNITE-8717 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Sergey Antonov >Priority: Major > > Currently, we persist cache configuration to local files which resulted in > several inconsistencies when a node misses configuration update (create > index, cache destroy, etc). > I think the cache configuration should be saved to the metastore the same way > as baseline topology is saved. Same mechanics should be used for conflicting > configuration updates resolution. > Along with cache configuration, it also makes sense to move marshaller and > binary metadata to the metastore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[
https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619081#comment-16619081
]
ASF GitHub Bot commented on IGNITE-9585:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4753
> Error message sometimes refers nonexisting log file when remote node fails to
> start
> ---
>
> Key: IGNITE-9585
> URL: https://issues.apache.org/jira/browse/IGNITE-9585
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Teamcity build logs sometimes refer to remote node log files that aren't
> present in build artifacts
> ([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
> I managed to reproduce this on my machine (details below) and it looks like
> typically the root cause of this is error message from
> [StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
> referring readers to file that doesn't exist (and it wasn't even created to
> start with).
> {code:java}
> return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
> node could not start. " +
> "See log for details: " + scriptOutputPath);
> {code}
> This is quite painful when one tries to investigate node launching failures
> because the misleading message causes one to waste time investigating the
> problem that doesn't exist (it appears as if log file was there but somehow
> disappeared for some mysterious reason).
>
> To reproduce the issue locally (on Ubuntu 16.04) one can do as follows:
> first, modify file
> [start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
> by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
> {{noignite.sh}}. After that, execute unit test
> [IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
> and study its results and logs.
> You will find that {{testCustomScript}} fails - which is expected because
> name of the script intended to be executed has changed to one that doesn't
> exist. Also you will find that log file for respective node hasn't been
> created - which is also expected because shell command fails before creating
> it. But in the same time test log will refer to mentioned file as if it
> exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9585) Error message sometimes refers nonexisting log file when remote node fails to start
[
https://issues.apache.org/jira/browse/IGNITE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619077#comment-16619077
]
Dmitriy Govorukhin commented on IGNITE-9585:
[~oignatenko] Thanks for the contribution, merged to master.
> Error message sometimes refers nonexisting log file when remote node fails to
> start
> ---
>
> Key: IGNITE-9585
> URL: https://issues.apache.org/jira/browse/IGNITE-9585
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Teamcity build logs sometimes refer to remote node log files that aren't
> present in build artifacts
> ([example|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_StartNodes=1849937_IgniteTests24Java8_StartNodes=%3Cdefault%3E]).
> I managed to reproduce this on my machine (details below) and it looks like
> typically the root cause of this is error message from
> [StartNodeCallableImpl|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java]
> referring readers to file that doesn't exist (and it wasn't even created to
> start with).
> {code:java}
> return new ClusterStartNodeResultImpl(spec.host(), false, "Remote
> node could not start. " +
> "See log for details: " + scriptOutputPath);
> {code}
> This is quite painful when one tries to investigate node launching failures
> because the misleading message causes one to waste time investigating the
> problem that doesn't exist (it appears as if log file was there but somehow
> disappeared for some mysterious reason).
>
> To reproduce the issue locally (on Ubuntu 16.04) one can do as follows:
> first, modify file
> [start-nodes-custom.sh|https://github.com/apache/ignite/blob/master/modules/core/src/test/bin/start-nodes-custom.sh]
> by replacing {{ignite.sh}} with the name of script that doesn't exist, eg
> {{noignite.sh}}. After that, execute unit test
> [IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
> and study its results and logs.
> You will find that {{testCustomScript}} fails - which is expected because
> name of the script intended to be executed has changed to one that doesn't
> exist. Also you will find that log file for respective node hasn't been
> created - which is also expected because shell command fails before creating
> it. But in the same time test log will refer to mentioned file as if it
> exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9629) JDBCv2: JdbcResultSet must support types conversions
[
https://issues.apache.org/jira/browse/IGNITE-9629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619043#comment-16619043
]
Taras Ledkov commented on IGNITE-9629:
--
[~vozerov], please review the patch. Tests are OK.
> JDBCv2: JdbcResultSet must support types conversions
>
>
> Key: IGNITE-9629
> URL: https://issues.apache.org/jira/browse/IGNITE-9629
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.7
>
>
> Now {{JdbcResultSet}} doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value::
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal,
> getBoolean, getString, getNString}}
> See the table B-6 at the JDBC spec (see also [8.9.5 and
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619036#comment-16619036 ] ASF GitHub Bot commented on IGNITE-9550: GitHub user ibessonov opened a pull request: https://github.com/apache/ignite/pull/4785 IGNITE-9550 Get operation returns null for a lost partition with READ_SAFE policy You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9550 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4785.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4785 commit 09187b0525f5198d9822bae2b254c0761bf90e46 Author: ibessonov Date: 2018-09-14T15:58:10Z IGNITE-9550 Added test that reproduces the problem reliably. commit 106a0d606f5187498ae6983a9f501ff8576c32f5 Author: ibessonov Date: 2018-09-18T12:02:04Z Merge branch 'master' into ignite-9550 commit 5e3d17c0ee0c0b987972b0344b7566a59387316c Author: ibessonov Date: 2018-09-18T12:17:29Z IGNITE-9550 Supposed fix. Documentation and minor cleanup is required > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Ivan Bessonov >Priority: Critical > Fix For: 2.7 > > Attachments: PartitionLostReproducer.java > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9022) [ML] Implement class labels mapping for SVM binary classifier
[
https://issues.apache.org/jira/browse/IGNITE-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619034#comment-16619034
]
ASF GitHub Bot commented on IGNITE-9022:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4749
> [ML] Implement class labels mapping for SVM binary classifier
> -
>
> Key: IGNITE-9022
> URL: https://issues.apache.org/jira/browse/IGNITE-9022
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Alexey Platonov
>Assignee: Aleksey Zinoviev
>Priority: Major
> Fix For: 2.7
>
>
> We need to automatically compute mapping from user's labels to \{-1;1} for
> SVM.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9158) [ML] Pipeline
[ https://issues.apache.org/jira/browse/IGNITE-9158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619031#comment-16619031 ] ASF GitHub Bot commented on IGNITE-9158: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4715 > [ML] Pipeline > - > > Key: IGNITE-9158 > URL: https://issues.apache.org/jira/browse/IGNITE-9158 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > > We want to implement our own pipeline for ML operations. More details in > [dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/ML-Machine-Learning-Pipeline-Improvement-tt32772.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9365) Force backups to different AWS availability zones using only Spring XML
[ https://issues.apache.org/jira/browse/IGNITE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619011#comment-16619011 ] David Harvey commented on IGNITE-9365: -- The misspelling of the attribute name would seem to be the common error. Having this silently suppress all backups seems wrong. It would be slightly less wrong to silently act as if the filter was not specified, but I guess it is still wrong. To have an exception thrown in the filter do reasonable things, there would need to be rework of the RendezvousAffinityFunction, which seems excessive. Is there precedent for exceptions like this that would take down all nodes at the time the first cache with backups is created? Logging seems like the best alternative. Logging warnings in the filter each time would flood the logs, but I guess that would get it noticed. Logging an error in the filter the first time would be the other choice. What would the right mechanism be to get a logger available in the filter's constructor? > Force backups to different AWS availability zones using only Spring XML > --- > > Key: IGNITE-9365 > URL: https://issues.apache.org/jira/browse/IGNITE-9365 > Project: Ignite > Issue Type: Improvement > Components: cache > Environment: >Reporter: David Harvey >Assignee: David Harvey >Priority: Minor > Fix For: 2.7 > > Attachments: master_947962f785_availability_zones_via_spring.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > As a developer, I want to be able to force cache backups each to a different > "Availability Zone", when I'm running out-of-the-box Ignite, without > additional Jars installed. "Availability zone" is a AWS feature with > different names for the same function by other cloud providers. A single > availability zone has the characteristic that some or all of the EC2 > instances in that zone can fail together due to a single fault. You have no > control over the hosts on which the EC2 instance VMs run on in AWS, except by > controlling the availability zone . > > I could write a few lines of a custom affinityBackupFilter, and configure it > a RendezvousAffinityFunction, but then I have to get it deployed on all nodes > in the cluster, and peer class loading will not work to this. The code to > do this should just be part of Ignite. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9637) SQL: Add indexes to data load benchmarks
Pavel Kuznetsov created IGNITE-9637: --- Summary: SQL: Add indexes to data load benchmarks Key: IGNITE-9637 URL: https://issues.apache.org/jira/browse/IGNITE-9637 Project: Ignite Issue Type: Bug Reporter: Pavel Kuznetsov Assignee: Pavel Kuznetsov We want to measure data load with indexes. We already have table with several fileds. We need benchmark parameter that handles number of indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9589) GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618977#comment-16618977
]
Amelchev Nikita commented on IGNITE-9589:
-
I have [prepared PR|https://github.com/apache/ignite/pull/4751] to fix the test.
The test uses zero port range to start node and sometimes throws bind exception
if address already uses.
I added retry node start after some timeout to avoid bind exception. This way
successfully used in other communication tests. [TC
tests|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Spi_IgniteTests24Java8=pull%2F4751%2Fhead=buildTypeStatusDiv]
are OK([100
runs|https://ci.ignite.apache.org/viewLog.html?buildId=1896514=IgniteTests24Java8_Spi=testsInfo]).
> GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
> ---
>
> Key: IGNITE-9589
> URL: https://issues.apache.org/jira/browse/IGNITE-9589
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange fails
> periodicaly.
> From the logs, I see that the failure is caused by BindException. It causes
> node start fails because the test port range is 0.
> {noformat}
> [2018-09-13
> 04:06:20,060][ERROR][test-runner-#225862%tcp.GridTcpCommunicationSpiConfigSelfTest%][GridTcpCommunicationSpiConfigSelfTest]
> Failed to start manager: GridManagerAdapter [enabled=true,
> name=o.a.i.i.managers.communication.GridIoManager]
> class org.apache.ignite.IgniteCheckedException: Failed to get SPI attributes.
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:262)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1755)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:975)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:673)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:598)
> at org.apache.ignite.Ignition.start(Ignition.java:323)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1370)
> at
> org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange(GridTcpCommunicationSpiConfigSelfTest.java:65)
> 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.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize TCP server: 0.0.0.0/0.0.0.0
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2137)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:261)
> ... 20 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind to
> any port within range [startPort=47100, portRange=0, locHost=0.0.0.0/0.0.0.0]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2450)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2134)
> ... 21 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> initialize NIO selector.
> at
> org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:988)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:342)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:97)
> at
>
[jira] [Updated] (IGNITE-9589) GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-9589:
Fix Version/s: 2.7
> GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange is flaky in master
> ---
>
> Key: IGNITE-9589
> URL: https://issues.apache.org/jira/browse/IGNITE-9589
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange fails
> periodicaly.
> From the logs, I see that the failure is caused by BindException. It causes
> node start fails because the test port range is 0.
> {noformat}
> [2018-09-13
> 04:06:20,060][ERROR][test-runner-#225862%tcp.GridTcpCommunicationSpiConfigSelfTest%][GridTcpCommunicationSpiConfigSelfTest]
> Failed to start manager: GridManagerAdapter [enabled=true,
> name=o.a.i.i.managers.communication.GridIoManager]
> class org.apache.ignite.IgniteCheckedException: Failed to get SPI attributes.
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:262)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1755)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:975)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:673)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:598)
> at org.apache.ignite.Ignition.start(Ignition.java:323)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1370)
> at
> org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiConfigSelfTest.testLocalPortRange(GridTcpCommunicationSpiConfigSelfTest.java:65)
> 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.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize TCP server: 0.0.0.0/0.0.0.0
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2137)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:261)
> ... 20 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind to
> any port within range [startPort=47100, portRange=0, locHost=0.0.0.0/0.0.0.0]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2450)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:2134)
> ... 21 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> initialize NIO selector.
> at
> org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:988)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:342)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:97)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$Builder.build(GridNioServer.java:3669)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:2415)
> ... 22 more
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at
>
[jira] [Updated] (IGNITE-9636) CacheBaselineTopologyTest#testClusterActiveWhileBaselineChanging is flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-9636: - Description: The test asynchronously sets baseline topology and while the transition happens checks that public API active state returns true. Sometimes this fails because publicApiActiveState(false) checks for transition and may return false if transition is in progress. Looks like an easy ticket. was:The test asynchronously sets baseline topology and while the transition happens checks that public API active state returns true. Sometimes this fails because publicApiActiveState(false) checks for transition and may return false if transition is in progress. > CacheBaselineTopologyTest#testClusterActiveWhileBaselineChanging is flaky in > master > --- > > Key: IGNITE-9636 > URL: https://issues.apache.org/jira/browse/IGNITE-9636 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > The test asynchronously sets baseline topology and while the transition > happens checks that public API active state returns true. Sometimes this > fails because publicApiActiveState(false) checks for transition and may > return false if transition is in progress. > Looks like an easy ticket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9636) CacheBaselineTopologyTest#testClusterActiveWhileBaselineChanging is flaky in master
Alexey Goncharuk created IGNITE-9636: Summary: CacheBaselineTopologyTest#testClusterActiveWhileBaselineChanging is flaky in master Key: IGNITE-9636 URL: https://issues.apache.org/jira/browse/IGNITE-9636 Project: Ignite Issue Type: Test Reporter: Alexey Goncharuk The test asynchronously sets baseline topology and while the transition happens checks that public API active state returns true. Sometimes this fails because publicApiActiveState(false) checks for transition and may return false if transition is in progress. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9635) Eternal initial partition map exchange
[ https://issues.apache.org/jira/browse/IGNITE-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618945#comment-16618945 ] Alexey Platonov commented on IGNITE-9635: - Note that some of thread awaits put but tx-threads are already absent. > Eternal initial partition map exchange > -- > > Key: IGNITE-9635 > URL: https://issues.apache.org/jira/browse/IGNITE-9635 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Sometimes test suites times out on test class > GridCacheReplicatedNodeRestartSelfTest. Finally, some test from this class > blocked on awaiting node starting due to eternal initial partition map > exchange. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9635) Eternal initial partition map exchange
[ https://issues.apache.org/jira/browse/IGNITE-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618942#comment-16618942 ] Alexey Platonov commented on IGNITE-9635: - Examples of failed tests: [https://ci.ignite.apache.org/viewLog.html?buildId=1862120=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] [https://ci.ignite.apache.org/viewLog.html?buildId=1862692=buildResultsDiv=IgniteTests24Java8_CacheRestarts1] > Eternal initial partition map exchange > -- > > Key: IGNITE-9635 > URL: https://issues.apache.org/jira/browse/IGNITE-9635 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Sometimes test suites times out on test class > GridCacheReplicatedNodeRestartSelfTest. Finally, some test from this class > blocked on awaiting node starting due to eternal initial partition map > exchange. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9635) Eternal initial partition map exchange
[
https://issues.apache.org/jira/browse/IGNITE-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618938#comment-16618938
]
Alexey Platonov commented on IGNITE-9635:
-
Examples of stacktraces part are listed below:
==
1 threads with trace:
States: \{WAITING=1}
Names:
- "test-runner-#298713%near.GridCachePartitionedNodeRestartTest%"
Stack:
- sun.misc.Unsafe.park(Native Method)
- - parking to wait for (a java.util.concurrent.CountDownLatch$Sync)
- java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
-
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
-
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
-
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
- java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
- org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7605)
-
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1666)
- org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1284)
- org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1262)
- org.apache.ignite.Ignition.allGrids(Ignition.java:498)
-
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1182)
-
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1171)
-
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithPut(GridCacheAbstractNodeRestartSelfTest.java:693)
-
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups(GridCacheAbstractNodeRestartSelfTest.java:370)
-
org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedNodeRestartTest.testRestartWithPutFourNodesNoBackups(GridCachePartitionedNodeRestartTest.java:76)
- sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
- sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
-
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
- java.lang.reflect.Method.invoke(Method.java:498)
- junit.framework.TestCase.runTest(TestCase.java:176)
-
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2177)
-
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
-
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
- java.lang.Thread.run(Thread.java:748)
==
1 threads with trace:
States: \{TIMED_WAITING=1}
Names:
- "restart-worker-0"
Stack:
- sun.misc.Unsafe.park(Native Method)
- java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
-
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
-
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
-
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
-
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:669)
-
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:891)
- org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1110)
-
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
-
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
- - locked (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
- org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
- org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
-
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:917)
-
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:855)
-
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:843)
-
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:809)
-
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$1000(GridCacheAbstractNodeRestartSelfTest.java:64)
-
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:665)
- java.lang.Thread.run(Thread.java:748)
[jira] [Created] (IGNITE-9635) Eternal initial partition map exchange
Alexey Platonov created IGNITE-9635: --- Summary: Eternal initial partition map exchange Key: IGNITE-9635 URL: https://issues.apache.org/jira/browse/IGNITE-9635 Project: Ignite Issue Type: Bug Reporter: Alexey Platonov Sometimes test suites times out on test class GridCacheReplicatedNodeRestartSelfTest. Finally, some test from this class blocked on awaiting node starting due to eternal initial partition map exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9633) [ML] Hyperparameter tuning improvements umbrella ticket
[ https://issues.apache.org/jira/browse/IGNITE-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618936#comment-16618936 ] Aleksey Zinoviev commented on IGNITE-9633: -- Look at [https://cloud.google.com/ml-engine/docs/tensorflow/using-hyperparameter-tuning] to add a few features like parallel trials and SGD optimization instead current brute-force appproach > [ML] Hyperparameter tuning improvements umbrella ticket > --- > > Key: IGNITE-9633 > URL: https://issues.apache.org/jira/browse/IGNITE-9633 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > > Umbrella ticket for all hyperparameter tuning improvements -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9618) Need to be replace the data compression algorithm
[ https://issues.apache.org/jira/browse/IGNITE-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-9618: Assignee: Alexand Polyakov > Need to be replace the data compression algorithm > - > > Key: IGNITE-9618 > URL: https://issues.apache.org/jira/browse/IGNITE-9618 > Project: Ignite > Issue Type: New Feature > Components: persistence >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > Now used zip and its speed slow > Exist alternatives and on tests in terms of performance they showed > themselves to be better > source file wal 1Gb > result > ||algoritm||time, ms||size, byte|| > |zip|18 889|79 950 283| > |[Snappy|https://github.com/xerial/snappy-java]|3 372|156 482 623| > |[lz4|https://github.com/lz4/lz4-java]|2 047|128 591 795| -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9634) [ML] Trainers as pipeline parameters that can be varied
Aleksey Zinoviev created IGNITE-9634: Summary: [ML] Trainers as pipeline parameters that can be varied Key: IGNITE-9634 URL: https://issues.apache.org/jira/browse/IGNITE-9634 Project: Ignite Issue Type: Sub-task Components: ml Affects Versions: 2.8 Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.8 Based http://apache-ignite-developers.2346864.n4.nabble.com/ML-New-Feature-Trainers-as-pipeline-parameters-that-can-be-varied-td35132.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9633) [ML] Hyperparameter tuning improvements umbrella ticket
Aleksey Zinoviev created IGNITE-9633: Summary: [ML] Hyperparameter tuning improvements umbrella ticket Key: IGNITE-9633 URL: https://issues.apache.org/jira/browse/IGNITE-9633 Project: Ignite Issue Type: New Feature Components: ml Affects Versions: 2.8 Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev Fix For: 2.8 Umbrella ticket for all hyperparameter tuning improvements -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9631) Timeouts in ZookeeperDIscoverySpi test suite
[ https://issues.apache.org/jira/browse/IGNITE-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov updated IGNITE-9631: Ignite Flags: (was: Docs Required) > Timeouts in ZookeeperDIscoverySpi test suite > > > Key: IGNITE-9631 > URL: https://issues.apache.org/jira/browse/IGNITE-9631 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Sometimes this test suite times out. Failed test examples: > [https://ci.ignite.apache.org/viewLog.html?buildId=1862120=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] > [https://ci.ignite.apache.org/viewLog.html?buildId=1839809=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] > It seems that test class GridCachePartitionedNodeRestartTest times out and > block all suite. > We need to add timeouts into test for suite timeouts preventing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8873) Optimize cache scans with enabled persistence.
[ https://issues.apache.org/jira/browse/IGNITE-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov reassigned IGNITE-8873: - Assignee: Alexei Scherbakov (was: Vladislav Pyatkov) > Optimize cache scans with enabled persistence. > -- > > Key: IGNITE-8873 > URL: https://issues.apache.org/jira/browse/IGNITE-8873 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.7 > > > Currently cache scans with enabled persistence involve link resolution, which > can lead to radom disk access resulting in bad performace on SAS disks. > One possibility is to preload cache data pages to remove slow random disk > access. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9381) p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node disconnect
[ https://issues.apache.org/jira/browse/IGNITE-9381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618920#comment-16618920 ] ASF GitHub Bot commented on IGNITE-9381: GitHub user antonovsergey93 opened a pull request: https://github.com/apache/ignite/pull/4784 IGNITE-9381 fix, reproducer were added You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9381 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4784.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4784 commit 2179d49e9402190016ac33df58dcc6a14c340811 Author: Sergey Antonov Date: 2018-09-18T10:44:29Z IGNITE-9381 fix, reproducer were added > p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node > disconnect > -- > > Key: IGNITE-9381 > URL: https://issues.apache.org/jira/browse/IGNITE-9381 > Project: Ignite > Issue Type: Bug >Reporter: Andrew Medvedev >Assignee: Sergey Antonov >Priority: Major > Attachments: AndmedScanFilterClassLoadingTest.java, snapshots.xml > > > Once deployed via scan query, an IgniteBiPredicate filter does not change if > client reconnects (with a modified filter) > Steps to reproduce: > * start server node in separate jvm with attached configuration (persistence > enabled) > * run attached reproducer AndmedScanFilterClassLoadingTest. It includes a > task and a scan filter, both print "FOO" on server side > * modify FOO -> BAR for both > * re-run modifed AndmedScanFilterClassLoadingTest . > Expected: Both print "BAR". > Actual behavior: task prints "BAR", scan filter prints "FOO" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7039) SQL: local query should pin affected partitions
[
https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618884#comment-16618884
]
Vladimir Ozerov commented on IGNITE-7039:
-
[~SGrimstad], my comments:
# We should add {{IgniteCacheLocalQueryReservationsTest}} to test suite
# Unfortunately we cannot cache sql -> cacheIds that way because this is
potential leak: you will have as many mappings as there are unique queries. For
example, this will hit us if user attach parameters directly to SQL instead of
using parameters list, which is not that uncommon. Let's remove caching
altogether for now. Local queries will become slower, but this is OK - we are
fixing bug.
# Could you please confirm that partitions are reserved/released in DML as
well? If not, let's create a ticket for this.
> SQL: local query should pin affected partitions
> ---
>
> Key: IGNITE-7039
> URL: https://issues.apache.org/jira/browse/IGNITE-7039
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability
> Fix For: 2.7
>
> Attachments: 3194.patch
>
>
> When distributed query is executed, we pin cache partitions for particular
> topology version on map nodes [1]. However, it seems that we do no do that
> for local queries. This is a bug because partition with required data could
> be evicted from local node at any time, leading to incorrect results.
> [1]
> https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6587) Ignite watchdog service
[
https://issues.apache.org/jira/browse/IGNITE-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618882#comment-16618882
]
Andrey Kuznetsov commented on IGNITE-6587:
--
[~agura], I've updated the implementation after discussing your points, see
[1]. Now it's waiting for your review.
> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
> Labels: IEP-5
> Fix For: 2.7
>
> Attachments: watchdog.sh
>
>
> As described in [1], each Ignite node has a number of system-critical
> threads. We should implement a periodic check that calls failure handler when
> one of the following conditions has been detected:
> * Critical thread is not alive anymore.
> * Critical thread 'hangs' for a long time, e.g. while executing a task
> extracted from task queue.
> In case of failure condition, call stacks of all threads should be logged
> before invoking failure handler.
> Actual list of system-critical threads can be found at [1].
> Implementations based on separate diagnostic thread seem fragile, cause this
> thread become a vulnerable point with respect to thread termination and CPU
> resource starvation. So we are to use self-monitoring approach: critical
> threads themselves should monitor each other.
> Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that
> fits best to store and track system critical threads. All of them should be
> refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each
> worker should periodically choose some subset of peer workers and check
> whether
> * All of them are alive.
> * All of them are actively running.
> It's required to add a 'heartbeat' timestamp to worker in order to implement
> latter check. Additionally, infinite queue polls, waits on monitors or thread
> parks should be refactored to their timed equivalents in system critical
> threads.
> Monitoring parameters (enable/disable, check interval, thread 'hang'
> threshold, etc.) are to be set via system properties.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6587) Ignite watchdog service
[
https://issues.apache.org/jira/browse/IGNITE-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618882#comment-16618882
]
Andrey Kuznetsov edited comment on IGNITE-6587 at 9/18/18 10:28 AM:
[~agura], I've updated the implementation after discussing your points, see
[1]. Now it's waiting for your review.
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Critical-worker-threads-liveness-checking-drawbacks-td34783.html
was (Author: andrey-kuznetsov):
[~agura], I've updated the implementation after discussing your points, see
[1]. Now it's waiting for your review.
> Ignite watchdog service
> ---
>
> Key: IGNITE-6587
> URL: https://issues.apache.org/jira/browse/IGNITE-6587
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
> Labels: IEP-5
> Fix For: 2.7
>
> Attachments: watchdog.sh
>
>
> As described in [1], each Ignite node has a number of system-critical
> threads. We should implement a periodic check that calls failure handler when
> one of the following conditions has been detected:
> * Critical thread is not alive anymore.
> * Critical thread 'hangs' for a long time, e.g. while executing a task
> extracted from task queue.
> In case of failure condition, call stacks of all threads should be logged
> before invoking failure handler.
> Actual list of system-critical threads can be found at [1].
> Implementations based on separate diagnostic thread seem fragile, cause this
> thread become a vulnerable point with respect to thread termination and CPU
> resource starvation. So we are to use self-monitoring approach: critical
> threads themselves should monitor each other.
> Currently we have {{o.a.i.internal.worker.WorkersRegistry}} facility that
> fits best to store and track system critical threads. All of them should be
> refactored to be {{GridWorker's}} and added to {{WorkersRegistry}}. Each
> worker should periodically choose some subset of peer workers and check
> whether
> * All of them are alive.
> * All of them are actively running.
> It's required to add a 'heartbeat' timestamp to worker in order to implement
> latter check. Additionally, infinite queue polls, waits on monitors or thread
> parks should be refactored to their timed equivalents in system critical
> threads.
> Monitoring parameters (enable/disable, check interval, thread 'hang'
> threshold, etc.) are to be set via system properties.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9550) Get operation returns null for a lost partition with READ_SAFE policy
[ https://issues.apache.org/jira/browse/IGNITE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9550: --- Priority: Critical (was: Major) > Get operation returns null for a lost partition with READ_SAFE policy > - > > Key: IGNITE-9550 > URL: https://issues.apache.org/jira/browse/IGNITE-9550 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Pavel Vinokurov >Assignee: Ivan Bessonov >Priority: Critical > Fix For: 2.7 > > Attachments: PartitionLostReproducer.java > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9631) Timeouts in ZookeeperDIscoverySpi test suite
[ https://issues.apache.org/jira/browse/IGNITE-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618847#comment-16618847 ] ASF GitHub Bot commented on IGNITE-9631: GitHub user avplatonov opened a pull request: https://github.com/apache/ignite/pull/4782 IGNITE-9631: Timeouts in ZookeeperDIscoverySpi test suite You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9631 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4782.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4782 commit f66af0f4707d8df84f9d552a865b75bf303ddb93 Author: Alexey Platonov Date: 2018-09-18T09:47:48Z add timeouts to test > Timeouts in ZookeeperDIscoverySpi test suite > > > Key: IGNITE-9631 > URL: https://issues.apache.org/jira/browse/IGNITE-9631 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Sometimes this test suite times out. Failed test examples: > [https://ci.ignite.apache.org/viewLog.html?buildId=1862120=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] > [https://ci.ignite.apache.org/viewLog.html?buildId=1839809=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] > It seems that test class GridCachePartitionedNodeRestartTest times out and > block all suite. > We need to add timeouts into test for suite timeouts preventing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9631) Timeouts in ZookeeperDIscoverySpi test suite
[
https://issues.apache.org/jira/browse/IGNITE-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618844#comment-16618844
]
Alexey Platonov commented on IGNITE-9631:
-
This test case was blocked by grid starting while eternal initial partition map
exchange.
Example of stacktrace:
States: \{TIMED_WAITING=1}
Names:
- "restart-worker-0"
Stack:
- sun.misc.Unsafe.park(Native Method)
- java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
-
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
-
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
-
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
-
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:669)
-
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:891)
- org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1110)
-
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
-
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
- - locked (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
- org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
- org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
-
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:917)
-
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:855)
-
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:843)
-
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:809)
-
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$1000(GridCacheAbstractNodeRestartSelfTest.java:64)
-
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:665)
- java.lang.Thread.run(Thread.java:748)
For preventing such blocking I added manual interrupting of workers of test.
But this situation should be investigated in other task because such blocking
appears in other suites (like IgniteCacheRestartTestSuite). Example in ofher
suite:
https://ci.ignite.apache.org/viewLog.html?buildId=1862692=buildResultsDiv=IgniteTests24Java8_CacheRestarts1
> Timeouts in ZookeeperDIscoverySpi test suite
>
>
> Key: IGNITE-9631
> URL: https://issues.apache.org/jira/browse/IGNITE-9631
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Sometimes this test suite times out. Failed test examples:
> [https://ci.ignite.apache.org/viewLog.html?buildId=1862120=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2]
> [https://ci.ignite.apache.org/viewLog.html?buildId=1839809=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2]
> It seems that test class GridCachePartitionedNodeRestartTest times out and
> block all suite.
> We need to add timeouts into test for suite timeouts preventing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9629) JDBCv2: JdbcResultSet must support types conversions
[
https://issues.apache.org/jira/browse/IGNITE-9629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618814#comment-16618814
]
ASF GitHub Bot commented on IGNITE-9629:
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/4781
IGNITE-9629 JDBCv2: supports types conversions at the JdbcResultSet
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9629
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4781.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4781
commit 62cf76d910af0e6d57327ee3af6c2a4ba9621f0d
Author: tledkov-gridgain
Date: 2018-09-18T10:01:17Z
IGNITE-9629 JDBCv2: supports types conversions at the JdbcResultSet
> JDBCv2: JdbcResultSet must support types conversions
>
>
> Key: IGNITE-9629
> URL: https://issues.apache.org/jira/browse/IGNITE-9629
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.7
>
>
> Now {{JdbcResultSet}} doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value::
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal,
> getBoolean, getString, getNString}}
> See the table B-6 at the JDBC spec (see also [8.9.5 and
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9628) Java 9: ML module compilation failure
[
https://issues.apache.org/jira/browse/IGNITE-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618811#comment-16618811
]
ASF GitHub Bot commented on IGNITE-9628:
GitHub user dmitrievanthony opened a pull request:
https://github.com/apache/ignite/pull/4780
IGNITE-9628 Avoid using sun.reflect.generics.reflectiveObjects package in
ML module
in ML module.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9628
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4780.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4780
commit 87dc630c26eb23b3bd2407724f24992323492622
Author: Anton Dmitriev
Date: 2018-09-18T09:58:33Z
IGNITE-9628 Avoid using sun.reflect.generics.reflectiveObjects package
in ML module.
> Java 9: ML module compilation failure
> -
>
> Key: IGNITE-9628
> URL: https://issues.apache.org/jira/browse/IGNITE-9628
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Peter Ivanov
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.7
>
>
> {code}
> [17:56:31][ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project ignite-ml: Compilation failure: Compilation
> failure:
> [17:56:31][ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/ml/src/main/java/org/apache/ignite/ml/tree/randomforest/data/impurity/MSEHistogram.java:[28,28]
> package sun.reflect.generics.reflectiveObjects is not visible
> [17:56:31][ERROR] (package sun.reflect.generics.reflectiveObjects is
> declared in module java.base, which does not export it to the unnamed module)
> [17:56:31][ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/ml/src/main/java/org/apache/ignite/ml/tree/randomforest/data/impurity/GiniHistogram.java:[34,28]
> package sun.reflect.generics.reflectiveObjects is not visible
> [17:56:31][ERROR] (package sun.reflect.generics.reflectiveObjects is
> declared in module java.base, which does not export it to the unnamed module)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9519) PK as complex type should can be keep at inline index
[ https://issues.apache.org/jira/browse/IGNITE-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9519: Fix Version/s: 2.7 > PK as complex type should can be keep at inline index > - > > Key: IGNITE-9519 > URL: https://issues.apache.org/jira/browse/IGNITE-9519 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.6 >Reporter: Yury Gerzhedovich >Assignee: Stanislav Lukyanov >Priority: Major > Fix For: 2.7 > > > Currently in case PK is complex type it can not be keep at inline index. > This is critical performance issue due to for any put or get operation it > cant' be fully comparable and require read full object from the heap or even > disk storage. > To mitigate the problem we need add ability keep complex type (java object) > at inline indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9629) JDBCv2: JdbcResultSet must support types conversions
[
https://issues.apache.org/jira/browse/IGNITE-9629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-9629:
-
Summary: JDBCv2: JdbcResultSet must support types conversions (was:
JDBCv2: JdbcThinResultSet must support types conversions)
> JDBCv2: JdbcResultSet must support types conversions
>
>
> Key: IGNITE-9629
> URL: https://issues.apache.org/jira/browse/IGNITE-9629
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.7
>
>
> Now {{JdbcResultSet}} doesn't support data types transformation.
> e.g.: if the attribute type is SHORT
> all the methods below must return valid value::
> {{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal,
> getBoolean, getString, getNString}}
> See the table B-6 at the JDBC spec (see also [8.9.5 and
> 8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9628) Java 9: ML module compilation failure
[
https://issues.apache.org/jira/browse/IGNITE-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev reassigned IGNITE-9628:
--
Assignee: Anton Dmitriev
> Java 9: ML module compilation failure
> -
>
> Key: IGNITE-9628
> URL: https://issues.apache.org/jira/browse/IGNITE-9628
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Peter Ivanov
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.7
>
>
> {code}
> [17:56:31][ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project ignite-ml: Compilation failure: Compilation
> failure:
> [17:56:31][ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/ml/src/main/java/org/apache/ignite/ml/tree/randomforest/data/impurity/MSEHistogram.java:[28,28]
> package sun.reflect.generics.reflectiveObjects is not visible
> [17:56:31][ERROR] (package sun.reflect.generics.reflectiveObjects is
> declared in module java.base, which does not export it to the unnamed module)
> [17:56:31][ERROR]
> /data/teamcity/work/9198da4c51c3e112/modules/ml/src/main/java/org/apache/ignite/ml/tree/randomforest/data/impurity/GiniHistogram.java:[34,28]
> package sun.reflect.generics.reflectiveObjects is not visible
> [17:56:31][ERROR] (package sun.reflect.generics.reflectiveObjects is
> declared in module java.base, which does not export it to the unnamed module)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9625) ML: Can't build ignite binaries because java doc exception
[
https://issues.apache.org/jira/browse/IGNITE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618795#comment-16618795
]
ASF GitHub Bot commented on IGNITE-9625:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4778
> ML: Can't build ignite binaries because java doc exception
> --
>
> Key: IGNITE-9625
> URL: https://issues.apache.org/jira/browse/IGNITE-9625
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Anton Dmitriev
>Priority: Blocker
> Fix For: 2.7
>
>
> Exception:
> {code}
> Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run
> (javadoc-postprocessing-new) on project apache-ignite: An Ant BuildException
> has occured: Execution failed due to: Class doesn't have description in file:
> /target/javadoc/core/org/apache/ignite/ml/composition/boosting/GDBTrainer.GDBModel.html
> Class doesn't have description in file:
> /target/javadoc/core/org/apache/ignite/ml/trainers/DatasetTrainer.EmptyDatasetException.html
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9441) Failed to read WAL record at position
[
https://issues.apache.org/jira/browse/IGNITE-9441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618792#comment-16618792
]
ASF GitHub Bot commented on IGNITE-9441:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4714
> Failed to read WAL record at position
> -
>
> Key: IGNITE-9441
> URL: https://issues.apache.org/jira/browse/IGNITE-9441
> Project: Ignite
> Issue Type: Test
> Components: persistence
>Reporter: Anton Kalashnikov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> IgnitePdsAtomicCacheHistoricalRebalancingTest.testPartitionCounterConsistencyOnUnstableTopology
> IgnitePdsAtomicCacheHistoricalRebalancingTest.testTopologyChangesWithConstantLoad
> IgnitePdsTxHistoricalRebalancingTest.testPartitionCounterConsistencyOnUnstableTopology
> {noformat}
> [2018-08-31
> 10:00:51,550][ERROR][sys-#32855%persistence.IgnitePdsTxHistoricalRebalancingTest1%][GridCacheIoManager]
> Failed processing message [senderId=60a69491-d44f-482b-9e7a-5ab1e2c3,
> msg=GridDhtPartitionDemandMessage [rebalanceId=1,
> parts=IgniteDhtDemandedPartitionsMap
> [historical=CachePartitionPartialCountersMap {0=(1561,1591), 1=(1561,1591),
> 2=(1561,1591), 4=(1561,1591), 7=(1561,1591), 11=(1560,1591), 13=(1560,1591),
> 14=(1560,1591), 24=(1560,1591), 25=(1560,1590), 27=(1560,1590),
> 31=(1560,1590), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0),
> 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0),
> 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0)}], timeout=1,
> workerId=-1, topVer=AffinityTopologyVersion [topVer=30, minorTopVer=0],
> partCnt=12, super=GridCacheGroupIdMessage [grpId=94416770]]]
> class org.apache.ignite.IgniteException: Failed to read WAL record at
> position: 23721849 size: 67108864
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:38)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.advance(GridCacheOffheapManager.java:1043)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.next(GridCacheOffheapManager.java:958)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.nextX(GridCacheOffheapManager.java:927)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.nextX(GridCacheOffheapManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.nextX(IgniteRebalanceIteratorImpl.java:130)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.next(IgniteRebalanceIteratorImpl.java:185)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.next(IgniteRebalanceIteratorImpl.java:37)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:345)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:426)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:405)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:390)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1613)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2768)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1529)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:127)
> at
>
[jira] [Updated] (IGNITE-9625) ML: Can't build ignite binaries because java doc exception
[
https://issues.apache.org/jira/browse/IGNITE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9625:
Priority: Blocker (was: Major)
> ML: Can't build ignite binaries because java doc exception
> --
>
> Key: IGNITE-9625
> URL: https://issues.apache.org/jira/browse/IGNITE-9625
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Anton Dmitriev
>Priority: Blocker
>
> Exception:
> {code}
> Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run
> (javadoc-postprocessing-new) on project apache-ignite: An Ant BuildException
> has occured: Execution failed due to: Class doesn't have description in file:
> /target/javadoc/core/org/apache/ignite/ml/composition/boosting/GDBTrainer.GDBModel.html
> Class doesn't have description in file:
> /target/javadoc/core/org/apache/ignite/ml/trainers/DatasetTrainer.EmptyDatasetException.html
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9632) Add support of trivial IN-operation for partition extraction
[ https://issues.apache.org/jira/browse/IGNITE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Grimstad updated IGNITE-9632: Description: GridSqlQuerySplitter when extractPartition should support IN operations for simple cases like IN (const, const ...) > Add support of trivial IN-operation for partition extraction > > > Key: IGNITE-9632 > URL: https://issues.apache.org/jira/browse/IGNITE-9632 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Grimstad >Assignee: Sergey Grimstad >Priority: Major > Fix For: 2.7 > > > GridSqlQuerySplitter when extractPartition should support IN operations for > simple cases like IN (const, const ...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9632) Add support of trivial IN-operation for partition extraction
[ https://issues.apache.org/jira/browse/IGNITE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Grimstad updated IGNITE-9632: Ignite Flags: (was: Docs Required) > Add support of trivial IN-operation for partition extraction > > > Key: IGNITE-9632 > URL: https://issues.apache.org/jira/browse/IGNITE-9632 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Grimstad >Assignee: Sergey Grimstad >Priority: Major > Fix For: 2.7 > > > GridSqlQuerySplitter when extractPartition should support IN operations for > simple cases like IN (const, const ...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9441) Failed to read WAL record at position
[
https://issues.apache.org/jira/browse/IGNITE-9441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618787#comment-16618787
]
Dmitriy Govorukhin commented on IGNITE-9441:
[~ibessonov] Changes look good, thanks for the contribution, merged to master.
> Failed to read WAL record at position
> -
>
> Key: IGNITE-9441
> URL: https://issues.apache.org/jira/browse/IGNITE-9441
> Project: Ignite
> Issue Type: Test
> Components: persistence
>Reporter: Anton Kalashnikov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> IgnitePdsAtomicCacheHistoricalRebalancingTest.testPartitionCounterConsistencyOnUnstableTopology
> IgnitePdsAtomicCacheHistoricalRebalancingTest.testTopologyChangesWithConstantLoad
> IgnitePdsTxHistoricalRebalancingTest.testPartitionCounterConsistencyOnUnstableTopology
> {noformat}
> [2018-08-31
> 10:00:51,550][ERROR][sys-#32855%persistence.IgnitePdsTxHistoricalRebalancingTest1%][GridCacheIoManager]
> Failed processing message [senderId=60a69491-d44f-482b-9e7a-5ab1e2c3,
> msg=GridDhtPartitionDemandMessage [rebalanceId=1,
> parts=IgniteDhtDemandedPartitionsMap
> [historical=CachePartitionPartialCountersMap {0=(1561,1591), 1=(1561,1591),
> 2=(1561,1591), 4=(1561,1591), 7=(1561,1591), 11=(1560,1591), 13=(1560,1591),
> 14=(1560,1591), 24=(1560,1591), 25=(1560,1590), 27=(1560,1590),
> 31=(1560,1590), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0),
> 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0),
> 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0), 0=(0,0)}], timeout=1,
> workerId=-1, topVer=AffinityTopologyVersion [topVer=30, minorTopVer=0],
> partCnt=12, super=GridCacheGroupIdMessage [grpId=94416770]]]
> class org.apache.ignite.IgniteException: Failed to read WAL record at
> position: 23721849 size: 67108864
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:38)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.advance(GridCacheOffheapManager.java:1043)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.next(GridCacheOffheapManager.java:958)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.nextX(GridCacheOffheapManager.java:927)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.nextX(GridCacheOffheapManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.nextX(IgniteRebalanceIteratorImpl.java:130)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.next(IgniteRebalanceIteratorImpl.java:185)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.next(IgniteRebalanceIteratorImpl.java:37)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:345)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:426)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:405)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:390)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1613)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2768)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1529)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:127)
> at
>
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618788#comment-16618788
]
Anton Vinogradov commented on IGNITE-9532:
--
[~uday],
Not sure I understand your question.
What I see, you relocated {{IgniteQueue queueBin =
grid(0).queue("q1", 0, config(false)).withKeepBinary();}} to another line and
gain "Succeeds" in both cases.
Reason still not clear to me. Why relocation cause another behavior?
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9632) Add support of trivial IN-operation for partition extraction
Sergey Grimstad created IGNITE-9632: --- Summary: Add support of trivial IN-operation for partition extraction Key: IGNITE-9632 URL: https://issues.apache.org/jira/browse/IGNITE-9632 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.7 Reporter: Sergey Grimstad Assignee: Sergey Grimstad Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9631) Timeouts in ZookeeperDIscoverySpi test suite
Alexey Platonov created IGNITE-9631: --- Summary: Timeouts in ZookeeperDIscoverySpi test suite Key: IGNITE-9631 URL: https://issues.apache.org/jira/browse/IGNITE-9631 Project: Ignite Issue Type: Bug Reporter: Alexey Platonov Assignee: Alexey Platonov Sometimes this test suite times out. Failed test examples: [https://ci.ignite.apache.org/viewLog.html?buildId=1862120=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] [https://ci.ignite.apache.org/viewLog.html?buildId=1839809=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery2] It seems that test class GridCachePartitionedNodeRestartTest times out and block all suite. We need to add timeouts into test for suite timeouts preventing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9630) Partitions intersection for AND condition of same key
Sergey Grimstad created IGNITE-9630: --- Summary: Partitions intersection for AND condition of same key Key: IGNITE-9630 URL: https://issues.apache.org/jira/browse/IGNITE-9630 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.7 Reporter: Sergey Grimstad Assignee: Sergey Grimstad Fix For: 2.7 GridSqlQuerySplitter when extractPartition for AND operation type should calculate intersection of resolved partitions for the same key -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9629) JDBCv2: JdbcThinResultSet must support types conversions
Taras Ledkov created IGNITE-9629:
Summary: JDBCv2: JdbcThinResultSet must support types conversions
Key: IGNITE-9629
URL: https://issues.apache.org/jira/browse/IGNITE-9629
Project: Ignite
Issue Type: Bug
Components: jdbc
Affects Versions: 2.6
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.7
Now {{JdbcResultSet}} doesn't support data types transformation.
e.g.: if the attribute type is SHORT
all the methods below must return valid value::
{{getByte, getShort, getInt, getLong, getFloat, getDouble, getBigDecimal,
getBoolean, getString, getNString}}
See the table B-6 at the JDBC spec (see also [8.9.5 and
8.9.6|http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#996857]).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9609) Web console: update to AngularJS 1.7.4
[ https://issues.apache.org/jira/browse/IGNITE-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-9609: -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: update to AngularJS 1.7.4 > -- > > Key: IGNITE-9609 > URL: https://issues.apache.org/jira/browse/IGNITE-9609 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Time Spent: 56m > Remaining Estimate: 0h > > Let's update package-.json to use AngularJS 1.7.4, the 1.7.3 release > introduced some interesting new feature we might use (like extra form methods > and arbitrary event/property bindings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9609) Web console: update to AngularJS 1.7.4
[ https://issues.apache.org/jira/browse/IGNITE-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618742#comment-16618742 ] Pavel Konstantinov commented on IGNITE-9609: Smoke test is done. > Web console: update to AngularJS 1.7.4 > -- > > Key: IGNITE-9609 > URL: https://issues.apache.org/jira/browse/IGNITE-9609 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Time Spent: 56m > Remaining Estimate: 0h > > Let's update package-.json to use AngularJS 1.7.4, the 1.7.3 release > introduced some interesting new feature we might use (like extra form methods > and arbitrary event/property bindings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9628) Java 9: ML module compilation failure
Peter Ivanov created IGNITE-9628:
Summary: Java 9: ML module compilation failure
Key: IGNITE-9628
URL: https://issues.apache.org/jira/browse/IGNITE-9628
Project: Ignite
Issue Type: Task
Affects Versions: 2.6
Reporter: Peter Ivanov
Fix For: 2.7
{code}
[17:56:31] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile)
on project ignite-ml: Compilation failure: Compilation failure:
[17:56:31] [ERROR]
/data/teamcity/work/9198da4c51c3e112/modules/ml/src/main/java/org/apache/ignite/ml/tree/randomforest/data/impurity/MSEHistogram.java:[28,28]
package sun.reflect.generics.reflectiveObjects is not visible
[17:56:31] [ERROR] (package sun.reflect.generics.reflectiveObjects is
declared in module java.base, which does not export it to the unnamed module)
[17:56:31] [ERROR]
/data/teamcity/work/9198da4c51c3e112/modules/ml/src/main/java/org/apache/ignite/ml/tree/randomforest/data/impurity/GiniHistogram.java:[34,28]
package sun.reflect.generics.reflectiveObjects is not visible
[17:56:31] [ERROR] (package sun.reflect.generics.reflectiveObjects is
declared in module java.base, which does not export it to the unnamed module)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9162) Query returns ICE: org.h2.table.TableView cannot be cast
[
https://issues.apache.org/jira/browse/IGNITE-9162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618726#comment-16618726
]
ASF GitHub Bot commented on IGNITE-9162:
GitHub user SGrimstad opened a pull request:
https://github.com/apache/ignite/pull/4779
IGNITE-9162 fixing condition is added
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite IGNITE-9162
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4779.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4779
commit b8312c14d4c63e1471504d1c152344114f01387b
Author: SGrimstad
Date: 2018-09-18T08:51:26Z
IGNITE-9162 fixing condition is added
> Query returns ICE: org.h2.table.TableView cannot be cast
>
>
> Key: IGNITE-9162
> URL: https://issues.apache.org/jira/browse/IGNITE-9162
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Sergey Kozlov
>Assignee: Sergey Grimstad
>Priority: Critical
> Fix For: 2.7
>
> Attachments: caches.xml, client.xml, policies.xml, server.xml
>
>
> 1. Start 1 Ignite node {{bin/ignite.sh server.xml -v -J-DCONSISTENT_ID=node1}}
> 2. Start sqlline {{bin/sqlline.sh -u
> jdbc:ignite:thin://127.0.0.1/?distributedJoins=true}}
> 3. Execute statements:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> CREATE TABLE t1 ( id INT NOT NULL, int_col1
> INT NOT NULL, PRIMARY KEY (id)) WITH "TEMPLATE=partitioned";
> No rows affected (0,151 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> INSERT INTO t1 (id,int_col1) VALUES
> (1,0),(2,0),(3,0),(4,0);
> 4 rows affected (0,052 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> SELECT * FROM ( SELECT * FROM t1 WHERE
> int_col1 > 0 ORDER BY id ) WHERE int_col1 = 1
> ORDER BY id;
> Error: javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: org.h2.table.TableView cannot be
> cast
> to org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> (state=5,code=0)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> Node log:
> {noformat}
> [12:39:38,162][SEVERE][client-connector-#50][JdbcRequestHandler] Failed to
> execute SQL query [reqId=0, req=JdbcQueryExecuteRequest [schemaName=PUBLIC,
> pageSize=1024, maxRows=0, sqlQry=SELECT * FROM ( SELECT * FROM t1 WHERE
> int_col1 > 0 ORDER BY id ) WHERE int_col1 = 1 ORDER BY id, args=[],
> stmtType=ANY_STATEMENT_TYPE]]
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2047)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:456)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:203)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:160)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:44)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> 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: class org.apache.ignite.IgniteCheckedException:
> org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2601)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> ... 12 more
> Caused by: java.lang.ClassCastException: org.h2.table.TableView cannot be
> cast to org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
[jira] [Commented] (IGNITE-9620) MVCC: select throwing `Transaction is already completed` exception after mvcc missmatch
[
https://issues.apache.org/jira/browse/IGNITE-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618724#comment-16618724
]
Vladimir Ozerov commented on IGNITE-9620:
-
Behavior appears to be correct. Need to fix error message.
> MVCC: select throwing `Transaction is already completed` exception after
> mvcc missmatch
>
>
> Key: IGNITE-9620
> URL: https://issues.apache.org/jira/browse/IGNITE-9620
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Stepan Pilschikov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> Using sqlline with autoCommit=false
> {code}
> switch to first user
> - select * from test:
> result: [[1, 1, test_1]]
> switch to second user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> - commit:
> - select * from test:
> result: [[1, 1, test_1], [2, 2, test_2]]
> switch to first user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> error: Mvcc version mismatch.
> - select * from test
> {code}
> During last select throwing exception
> {code}
> 0: jdbc:ignite:thin://127.0.0.1:10800> select * from test;
> select * from test;
> [1;31mError: Transaction is already completed. (state=25000,code=0)[m
> java.sql.SQLException: Transaction is already completed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:764)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Exception in node logs:
> {code}
> [17:44:36,234][SEVERE][jdbc-request-handler-worker-#61][JdbcRequestHandler]
> Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select * from test,
> args=Object[] [], stmtType=ANY_STATEMENT_TYPE, autoCommit=false]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:623)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:780)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:761)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:744)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1731)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:2521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2074)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Works for any query which is throwing mvcc missmatch exception
> After commit select query works again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9627) TcpCommunicationSpiSkipMessageSendTest.testClientSegmented is flaky in master
Amelchev Nikita created IGNITE-9627:
---
Summary:
TcpCommunicationSpiSkipMessageSendTest.testClientSegmented is flaky in master
Key: IGNITE-9627
URL: https://issues.apache.org/jira/browse/IGNITE-9627
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
The test is flaky in master. Also, it uses the default failure handler and can
halt JVM.
Example of fail: [TC
build|https://ci.ignite.apache.org/viewLog.html?buildId=1895268=buildResultsDiv=IgniteTests24Java8_Spi#testNameId-3225493048753223945].
Log:
{noformat}
[2018-09-18 06:12:42,466][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError: Client wasn't segmented.
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpiSkipMessageSendTest.testClientSegmented(TcpCommunicationSpiSkipMessageSendTest.java:104)
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.runTestInternal(GridAbstractTest.java:2177)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9625) ML: Can't build ignite binaries because java doc exception
[
https://issues.apache.org/jira/browse/IGNITE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Dmitriev reassigned IGNITE-9625:
--
Assignee: Anton Dmitriev
> ML: Can't build ignite binaries because java doc exception
> --
>
> Key: IGNITE-9625
> URL: https://issues.apache.org/jira/browse/IGNITE-9625
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Anton Dmitriev
>Priority: Major
>
> Exception:
> {code}
> Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run
> (javadoc-postprocessing-new) on project apache-ignite: An Ant BuildException
> has occured: Execution failed due to: Class doesn't have description in file:
> /target/javadoc/core/org/apache/ignite/ml/composition/boosting/GDBTrainer.GDBModel.html
> Class doesn't have description in file:
> /target/javadoc/core/org/apache/ignite/ml/trainers/DatasetTrainer.EmptyDatasetException.html
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9626) Applying WAL updates ignores evicition policy
Pavel Vinokurov created IGNITE-9626: --- Summary: Applying WAL updates ignores evicition policy Key: IGNITE-9626 URL: https://issues.apache.org/jira/browse/IGNITE-9626 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Pavel Vinokurov Assignee: Pavel Vinokurov Attachments: IgniteExpirationWitPeristanceReproducer.java Steps to reproduce: 1. Add record for cache obtained by ignite.cache().withExpiryPolicy(). 2. Stops node before checkpoint. 3. Start node and get record for cache after specified duration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9625) ML: Can't build ignite binaries because java doc exception
[
https://issues.apache.org/jira/browse/IGNITE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618702#comment-16618702
]
ASF GitHub Bot commented on IGNITE-9625:
GitHub user dmitrievanthony opened a pull request:
https://github.com/apache/ignite/pull/4778
IGNITE-9625 Fix ML javadoc
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9625
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4778.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4778
commit afb9c38daed5970dfc22b703e4e9d22dcc57faee
Author: Anton Dmitriev
Date: 2018-09-18T08:37:39Z
IGNITE-9625 Fix javadoc.
> ML: Can't build ignite binaries because java doc exception
> --
>
> Key: IGNITE-9625
> URL: https://issues.apache.org/jira/browse/IGNITE-9625
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Exception:
> {code}
> Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run
> (javadoc-postprocessing-new) on project apache-ignite: An Ant BuildException
> has occured: Execution failed due to: Class doesn't have description in file:
> /target/javadoc/core/org/apache/ignite/ml/composition/boosting/GDBTrainer.GDBModel.html
> Class doesn't have description in file:
> /target/javadoc/core/org/apache/ignite/ml/trainers/DatasetTrainer.EmptyDatasetException.html
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9625) ML: Can't build ignite binaries because java doc exception
Stepan Pilschikov created IGNITE-9625:
-
Summary: ML: Can't build ignite binaries because java doc exception
Key: IGNITE-9625
URL: https://issues.apache.org/jira/browse/IGNITE-9625
Project: Ignite
Issue Type: Bug
Components: ml
Affects Versions: 2.7
Reporter: Stepan Pilschikov
Exception:
{code}
Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run
(javadoc-postprocessing-new) on project apache-ignite: An Ant BuildException
has occured: Execution failed due to: Class doesn't have description in file:
/target/javadoc/core/org/apache/ignite/ml/composition/boosting/GDBTrainer.GDBModel.html
Class doesn't have description in file:
/target/javadoc/core/org/apache/ignite/ml/trainers/DatasetTrainer.EmptyDatasetException.html
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9620) MVCC: select throwing `Transaction is already completed` exception after mvcc missmatch
[
https://issues.apache.org/jira/browse/IGNITE-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-9620:
---
Assignee: Vladimir Ozerov
> MVCC: select throwing `Transaction is already completed` exception after
> mvcc missmatch
>
>
> Key: IGNITE-9620
> URL: https://issues.apache.org/jira/browse/IGNITE-9620
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Stepan Pilschikov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> Using sqlline with autoCommit=false
> {code}
> switch to first user
> - select * from test:
> result: [[1, 1, test_1]]
> switch to second user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> - commit:
> - select * from test:
> result: [[1, 1, test_1], [2, 2, test_2]]
> switch to first user
> - insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
> error: Mvcc version mismatch.
> - select * from test
> {code}
> During last select throwing exception
> {code}
> 0: jdbc:ignite:thin://127.0.0.1:10800> select * from test;
> select * from test;
> [1;31mError: Transaction is already completed. (state=25000,code=0)[m
> java.sql.SQLException: Transaction is already completed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:764)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Exception in node logs:
> {code}
> [17:44:36,234][SEVERE][jdbc-request-handler-worker-#61][JdbcRequestHandler]
> Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select * from test,
> args=Object[] [], stmtType=ANY_STATEMENT_TYPE, autoCommit=false]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException:
> Transaction is already completed.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:623)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:780)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:761)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:744)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1731)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:2521)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2074)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Works for any query which is throwing mvcc missmatch exception
> After commit select query works again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8386) SQL: Make sure PK index do not use wrapped object
[
https://issues.apache.org/jira/browse/IGNITE-8386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618654#comment-16618654
]
Yury Gerzhedovich commented on IGNITE-8386:
---
[~ldz],
1) Potentially yes, but it's depends on...
2) No
> SQL: Make sure PK index do not use wrapped object
> -
>
> Key: IGNITE-8386
> URL: https://issues.apache.org/jira/browse/IGNITE-8386
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-19, performance
>
> Currently PK may be built over the whole {{_KEY}} column, i.e. the whole
> binary object. This could happen in two cases:
> 1) Composite PK
> 2) Plain PK but with {{WRAP_KEY}} option.
> This is critical performance issue for two reasons:
> 1) This index is effectively useless and cannot be used in any sensible
> queries; it just wastes space and makes updates slower
> 2) Binary object typically has common header bytes what may lead to excessive
> number of comparisons during index update.
> To mitigate the problem we need to ensure that index is *never* built over
> {{_KEY}}, Instead, we must always extract target columns and build normal
> index over them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9621) MVCC: sqlline warning that transactions are not supported
[
https://issues.apache.org/jira/browse/IGNITE-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepan Pilschikov updated IGNITE-9621:
--
Description:
MVCC enabled
--autoCommit=false
In sqlline first initial lines throwing warning message:
{code}
[1;34missuing: !connect jdbc:ignite:thin://127.0.0.1:10800 '' ''
org.apache.ignite.IgniteJdbcThinDriver[m
[1;34mConnecting to jdbc:ignite:thin://127.0.0.1:10800[m
[1;34mConnected to: Apache Ignite (version 2.7.1#19700101-sha1:)[m
[1;34mDriver: Apache Ignite Thin JDBC Driver (version
2.7.1#19700101-sha1:)[m
[1;34mAutocommit status: false[m
Sep 17, 2018 5:44:32 PM org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
setTransactionIsolation
WARNING: Transactions are not supported.
Sep 17, 2018 5:44:32 PM org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
getTransactionIsolation
WARNING: Transactions are not supported.
[1;34mTransaction isolation: TRANSACTION_REPEATABLE_READ[m
sqlline version 1.3.0
0: jdbc:ignite:thin://127.0.0.1:10800>
{code}
was:
MVCC enabled
--autoCommit=true
In sqlline first initial lines throwing warning message:
{code}
[1;34missuing: !connect jdbc:ignite:thin://127.0.0.1:10800 '' ''
org.apache.ignite.IgniteJdbcThinDriver[m
[1;34mConnecting to jdbc:ignite:thin://127.0.0.1:10800[m
[1;34mConnected to: Apache Ignite (version 2.7.1#19700101-sha1:)[m
[1;34mDriver: Apache Ignite Thin JDBC Driver (version
2.7.1#19700101-sha1:)[m
[1;34mAutocommit status: false[m
Sep 17, 2018 5:44:32 PM org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
setTransactionIsolation
WARNING: Transactions are not supported.
Sep 17, 2018 5:44:32 PM org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
getTransactionIsolation
WARNING: Transactions are not supported.
[1;34mTransaction isolation: TRANSACTION_REPEATABLE_READ[m
sqlline version 1.3.0
0: jdbc:ignite:thin://127.0.0.1:10800>
{code}
> MVCC: sqlline warning that transactions are not supported
> -
>
> Key: IGNITE-9621
> URL: https://issues.apache.org/jira/browse/IGNITE-9621
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Stepan Pilschikov
>Priority: Major
> Fix For: 2.7
>
>
> MVCC enabled
> --autoCommit=false
> In sqlline first initial lines throwing warning message:
> {code}
> [1;34missuing: !connect jdbc:ignite:thin://127.0.0.1:10800 '' ''
> org.apache.ignite.IgniteJdbcThinDriver[m
> [1;34mConnecting to jdbc:ignite:thin://127.0.0.1:10800[m
> [1;34mConnected to: Apache Ignite (version 2.7.1#19700101-sha1:)[m
> [1;34mDriver: Apache Ignite Thin JDBC Driver (version
> 2.7.1#19700101-sha1:)[m
> [1;34mAutocommit status: false[m
> Sep 17, 2018 5:44:32 PM
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
> setTransactionIsolation
> WARNING: Transactions are not supported.
> Sep 17, 2018 5:44:32 PM
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection
> getTransactionIsolation
> WARNING: Transactions are not supported.
> [1;34mTransaction isolation: TRANSACTION_REPEATABLE_READ[m
> sqlline version 1.3.0
> 0: jdbc:ignite:thin://127.0.0.1:10800>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9620) MVCC: select throwing `Transaction is already completed` exception after mvcc missmatch
[
https://issues.apache.org/jira/browse/IGNITE-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepan Pilschikov updated IGNITE-9620:
--
Description:
Using sqlline with autoCommit=false
{code}
switch to first user
- select * from test:
result: [[1, 1, test_1]]
switch to second user
- insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
- commit:
- select * from test:
result: [[1, 1, test_1], [2, 2, test_2]]
switch to first user
- insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
error: Mvcc version mismatch.
- select * from test
{code}
During last select throwing exception
{code}
0: jdbc:ignite:thin://127.0.0.1:10800> select * from test;
select * from test;
[1;31mError: Transaction is already completed. (state=25000,code=0)[m
java.sql.SQLException: Transaction is already completed.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:764)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
{code}
Exception in node logs:
{code}
[17:44:36,234][SEVERE][jdbc-request-handler-worker-#61][JdbcRequestHandler]
Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
[schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select * from test,
args=Object[] [], stmtType=ANY_STATEMENT_TYPE, autoCommit=false]]
class org.apache.ignite.internal.processors.query.IgniteSQLException:
Transaction is already completed.
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.checkActive(MvccUtils.java:623)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.requestSnapshot(MvccUtils.java:780)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:761)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.mvccTracker(MvccUtils.java:744)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.runQueryTwoStep(IgniteH2Indexing.java:1731)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunDistributedQuery(IgniteH2Indexing.java:2521)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2074)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{code}
Works for any query which is throwing mvcc missmatch exception
After commit select query works again
was:
Using sqlline with autoCommit=true
{code}
switch to first user
- select * from test:
result: [[1, 1, test_1]]
switch to second user
- insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
- commit:
- select * from test:
result: [[1, 1, test_1], [2, 2, test_2]]
switch to first user
- insert into test(id, field_int, field_var) values (2, 2, 'test_2'):
error: Mvcc version mismatch.
- select * from test
{code}
During last select throwing exception
{code}
0: jdbc:ignite:thin://127.0.0.1:10800> select * from test;
select * from test;
[1;31mError: Transaction is already completed. (state=25000,code=0)[m
java.sql.SQLException: Transaction is already completed.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:764)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
[jira] [Commented] (IGNITE-7783) Thin Client lib: PHP
[ https://issues.apache.org/jira/browse/IGNITE-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618640#comment-16618640 ] Alexey Kosenchuk commented on IGNITE-7783: -- Original readme (how to for the client, instructions for the examples and tests, etc.): [https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md] > Thin Client lib: PHP > > > Key: IGNITE-7783 > URL: https://issues.apache.org/jira/browse/IGNITE-7783 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: ekaterina.vergizova >Priority: Major > Fix For: 2.7 > > > Implement Thin (lightweight) Client lib in PHP programming language for > Ignite Binary Client Protocol. > Functionality: > -- > Support all operations of the Ignite Binary Client Protocol 2.6: > [https://apacheignite.readme.io/v2.6/docs/binary-client-protocol] > Except the following features which are not applicable to PHP client: > - Filter object for OP_QUERY_SCAN operation (OP_QUERY_SCAN operation itself > will be supported). > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME operations. > - Registration of a new Ignite Enum type (reading and writing items of the > existing Ignite Enum types will be supported). > Additionally support: > - SSL/TLS connection. > - "Failover re-connection algorithm": > https://issues.apache.org/jira/browse/IGNITE-7282 > Ignite Binary Client Protocol handshake versions: 1.2.0 only. > Minimal required PHP version: 7.2 > [http://php.net/supported-versions.php] > PHP code-style standards: [https://www.php-fig.org/psr/] > Synchronous API will be supported (asynchronous operations are not supported > by the standard PHP). > The API will not be thread-safe (threads are not available in the standard > PHP; pthreads extension is not available for the latest PHP version; > thread-safety is possible to support by an application). > Examples: > - > The set of examples will cover: > - cache get/create/destroy operations > - cache put/get operations > - SQL operations (create table/index, insert/select/drop) > - SQL Fields query and Scan query > - Authentication and TLS connection > - working with primitive and complex data types > Tests: > -- > PHPUnit tests [https://phpunit.de|https://phpunit.de/] for all API methods > and all basic features. Including simple tests to start examples. > Tests will be integrated into the TeamCity with the help from the community. > Docs: > -- > The provided docs will include: > - Auto-generated API spec using Doxygen: > [http://www.doxygen.org|http://www.doxygen.org/] > - Instruction how to generate the API spec. > - Instruction how to release PHP library on Packagist: > [https://packagist.org/] > - Readme for user with info how to install and use the client. > - Simple instruction how to setup/run examples. > - Simple instruction how to setup/run tests. > All docs will be provided separately from the source code and will not be > merged to the target repository. Before the release all instructions and > readme will be moved to the readme.io with the help from the community. > Release: > > Location of the client: > /modules/platforms/php > Will be released as PHP library on Packagist: [https://packagist.org/] by the > community. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618631#comment-16618631
]
Uday Kale edited comment on IGNITE-9532 at 9/18/18 8:02 AM:
[~avinogradov]
The code in my PR at GridCacheQueueProxy:484 is changing the operating context
for the queue objects already initialised in the thread. It can be confirmed
since the unit test below works but the unit test in the comments above does
not:
{code:java}
public void testContains() throws Exception {
IgniteQueue queue = grid(0).queue("q1", 0, config(false));
queue.add(new SameHashItem(Integer.toString(14)));
assertTrue(queue.contains(new SameHashItem(Integer.toString(14; //
Succeeds
IgniteQueue queueBin = grid(0).queue("q1", 0,
config(false)).withKeepBinary();
queueBin.add(sameHashBinObj(grid(0), 14));
assertTrue(queueBin.contains(sameHashBinObj(grid(0), 14))); // Succeeds
}
private static BinaryObject sameHashBinObj(Ignite ignite, int i) {
return ignite.binary().toBinary(new SameHashItem(Integer.toString(i)));
}
{code}
Is this acceptable?
was (Author: uday):
[~avinogradov]
The code in my PR at GridCacheQueueProxy:484 is changing the operating context
for the queue objects already initialised in the thread. It can be confirmed
since the unit test below works but the unit test in the comments above does
not:
{code:java}
public void testContains() throws Exception
{ IgniteQueue queue = grid(0).queue("q1", 0, config(false));
queue.add(new SameHashItem(Integer.toString(14)));
assertTrue(queue.contains(new SameHashItem(Integer.toString(14; // Fails
IgniteQueue queueBin = grid(0).queue("q1", 0,
config(false)).withKeepBinary(); queueBin.add(sameHashBinObj(grid(0), 14));
assertTrue(queueBin.contains(sameHashBinObj(grid(0), 14))); // Succeeds }
private static BinaryObject sameHashBinObj(Ignite ignite, int i)
{ return ignite.binary().toBinary(new SameHashItem(Integer.toString(i))); }
{code}
Is this acceptable?
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618631#comment-16618631
]
Uday Kale edited comment on IGNITE-9532 at 9/18/18 8:00 AM:
[~avinogradov]
The code in my PR at GridCacheQueueProxy:484 is changing the operating context
for the queue objects already initialised in the thread. It can be confirmed
since the unit test below works but the unit test in the comments above does
not:
{code:java}
public void testContains() throws Exception
{ IgniteQueue queue = grid(0).queue("q1", 0, config(false));
queue.add(new SameHashItem(Integer.toString(14)));
assertTrue(queue.contains(new SameHashItem(Integer.toString(14; // Fails
IgniteQueue queueBin = grid(0).queue("q1", 0,
config(false)).withKeepBinary(); queueBin.add(sameHashBinObj(grid(0), 14));
assertTrue(queueBin.contains(sameHashBinObj(grid(0), 14))); // Succeeds }
private static BinaryObject sameHashBinObj(Ignite ignite, int i)
{ return ignite.binary().toBinary(new SameHashItem(Integer.toString(i))); }
{code}
Is this acceptable?
was (Author: uday):
[~avinogradov]
The code in my PR at GridCacheQueueProxy:484 is changing the operating context
for the queue objects already initialised in the thread. It can be confirmed
since the unit test below works but the unit test in the comments above does
not:
public void testContains() throws Exception {
IgniteQueue queue = grid(0).queue("q1", 0, config(false));
queue.add(new SameHashItem(Integer.toString(14)));
assertTrue(queue.contains(new SameHashItem(Integer.toString(14; //
Fails
IgniteQueue queueBin = grid(0).queue("q1", 0,
config(false)).withKeepBinary();
queueBin.add(sameHashBinObj(grid(0), 14));
assertTrue(queueBin.contains(sameHashBinObj(grid(0), 14))); // Succeeds
}private static BinaryObject sameHashBinObj(Ignite ignite, int i) {
return ignite.binary().toBinary(new SameHashItem(Integer.toString(i)));
}
Is this acceptable?
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16617354#comment-16617354
]
Uday Kale edited comment on IGNITE-9532 at 9/18/18 8:00 AM:
I am trying to check if the SameHash object exists in the queue 'q1' after
adding both Binary Object and SameHash Object to it. Currently this is failing.
It is successful only if the object is converted to Binary Object. Below is a
simplified test.
{code:java}
public void testContains() throws Exception {
IgniteQueue queue = grid(0).queue("q1", 0, config(false));
IgniteQueue queueBin = grid(0).queue("q1", 0,
config(false)).withKeepBinary();
queue.add(new SameHashItem(Integer.toString(14)));
queueBin.add(sameHashBinObj(grid(0), 14));
assertTrue(queue.contains(new SameHashItem(Integer.toString(14; //
Fails
assertTrue(queueBin.contains(sameHashBinObj(grid(0), 14))); // Succeeds
}
private static BinaryObject sameHashBinObj(Ignite ignite, int i) {
return ignite.binary().toBinary(new SameHashItem(Integer.toString(i)));
}
{code}
Is this the expected behaviour?
was (Author: uday):
I am trying to check if the SameHash object exists in the queue 'q1' after
adding both Binary Object and SameHash Object to it. Currently this is failing.
It is successful only if the object is converted to Binary Object. Below is a
simplified test.
{code:java}
public void testContains() throws Exception {
IgniteQueue queue = grid(0).queue("q1", 0, config(false));
IgniteQueue queueBin = grid(0).queue("q1", 0,
config(false)).withKeepBinary();
queue.add(new SameHashItem(Integer.toString(14)));
queueBin.add(sameHashBinObj(grid(0), 14));
assertTrue(queue.contains(new SameHashItem(Integer.toString(14; //
Fails
assertTrue(queueBin.contains(sameHashBinObj(grid(0), 14))); // Succeeds
}
private static BinaryObject sameHashBinObj(Ignite ignite, int i) {
return ignite.binary().toBinary(new SameHashItem(Integer.toString(i)));
}
{code}
Is this the expected behaviour?
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9532) Binary mode for Ignite Queue
[
https://issues.apache.org/jira/browse/IGNITE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618631#comment-16618631
]
Uday Kale commented on IGNITE-9532:
---
[~avinogradov]
The code in my PR at GridCacheQueueProxy:484 is changing the operating context
for the queue objects already initialised in the thread. It can be confirmed
since the unit test below works but the unit test in the comments above does
not:
public void testContains() throws Exception {
IgniteQueue queue = grid(0).queue("q1", 0, config(false));
queue.add(new SameHashItem(Integer.toString(14)));
assertTrue(queue.contains(new SameHashItem(Integer.toString(14; //
Fails
IgniteQueue queueBin = grid(0).queue("q1", 0,
config(false)).withKeepBinary();
queueBin.add(sameHashBinObj(grid(0), 14));
assertTrue(queueBin.contains(sameHashBinObj(grid(0), 14))); // Succeeds
}private static BinaryObject sameHashBinObj(Ignite ignite, int i) {
return ignite.binary().toBinary(new SameHashItem(Integer.toString(i)));
}
Is this acceptable?
> Binary mode for Ignite Queue
>
>
> Key: IGNITE-9532
> URL: https://issues.apache.org/jira/browse/IGNITE-9532
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
>
> Add binary mode (withKeepBinary) to Data Structures Queue.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9624) Refine CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT javadoc
[
https://issues.apache.org/jira/browse/IGNITE-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9624:
Component/s: (was: documentation)
> Refine CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT javadoc
>
>
> Key: IGNITE-9624
> URL: https://issues.apache.org/jira/browse/IGNITE-9624
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> Currently {{CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT}} javadoc contains some
> typos. It might be good idea to proof read it and correct grammar.
> See PR as starting point.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
