[jira] [Assigned] (IGNITE-6229) Web console: Errors in project code generation
[ https://issues.apache.org/jira/browse/IGNITE-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-6229: - Assignee: Andrey Novikov (was: Vasiliy Sisko) > Web console: Errors in project code generation > -- > > Key: IGNITE-6229 > URL: https://issues.apache.org/jira/browse/IGNITE-6229 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.1 >Reporter: Vasiliy Sisko >Assignee: Andrey Novikov > Fix For: 2.3 > > > 1) In MemoryPolicyConfiguration: subIntervals and rateTimeInterval fields > available from 2.1 version. > 2) Unused import of common type for vararg function arguments and in some > startup classes. > 3) Number format exception for long properties in XML configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6229) Web console: Errors in project code generation
[ https://issues.apache.org/jira/browse/IGNITE-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148525#comment-16148525 ] Vasiliy Sisko commented on IGNITE-6229: --- 1-3 fixed. > Web console: Errors in project code generation > -- > > Key: IGNITE-6229 > URL: https://issues.apache.org/jira/browse/IGNITE-6229 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.1 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > Fix For: 2.3 > > > 1) In MemoryPolicyConfiguration: subIntervals and rateTimeInterval fields > available from 2.1 version. > 2) Unused import of common type for vararg function arguments and in some > startup classes. > 3) Number format exception for long properties in XML configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6229) Web console: Errors in project code generation
Vasiliy Sisko created IGNITE-6229: - Summary: Web console: Errors in project code generation Key: IGNITE-6229 URL: https://issues.apache.org/jira/browse/IGNITE-6229 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 2.1 Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Fix For: 2.3 1) In MemoryPolicyConfiguration: subIntervals and rateTimeInterval fields available from 2.1 version. 2) Unused import of common type for vararg function arguments and in some startup classes. 3) Number format exception for long properties in XML configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6115) Ignore page eviction mode if Ignite persistence is enabled
[
https://issues.apache.org/jira/browse/IGNITE-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148393#comment-16148393
]
ASF GitHub Bot commented on IGNITE-6115:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2523
> Ignore page eviction mode if Ignite persistence is enabled
> --
>
> Key: IGNITE-6115
> URL: https://issues.apache.org/jira/browse/IGNITE-6115
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Roman Shtykh
> Labels: usability
> Fix For: 2.3
>
>
> If a page eviction mode is defined for a memory region and the Ignite Native
> Persistence is enabled then the following exception is thrown on a node
> startup:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter []
>at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1791)
>at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:929)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1896)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1648)
>at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1076)
>at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:994)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:880)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:779)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:649)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:618)
>at org.apache.ignite.Ignition.start(Ignition.java:347)
>at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Page eviction is
> not compatible with persistence: 1G_Region
>at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkPolicyEvictionProperties(GridCacheDatabaseSharedManager.java:660)
>at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.validateConfiguration(IgniteCacheDatabaseSharedManager.java:336)
>at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.start0(IgniteCacheDatabaseSharedManager.java:109)
>at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:358)
>at
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
>at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:696)
>at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1788)
> {code}
> That case has to be processed differently:
> * Ignore the page eviction mode and let the node to proceed with the startup.
> * Print a warning "Page eviction mode for {name} memory region is ignored
> because Ignite Native Persistence is enabled".
> Discussion on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Ignite2-1-Page-eviction-is-not-compatible-with-persistence-when-startup-td20934.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6120) Web Console: Propagate "lazy" flag on Query screen
[ https://issues.apache.org/jira/browse/IGNITE-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-6120: - Assignee: Andrey Novikov (was: Alexey Kuznetsov) > Web Console: Propagate "lazy" flag on Query screen > -- > > Key: IGNITE-6120 > URL: https://issues.apache.org/jira/browse/IGNITE-6120 > Project: Ignite > Issue Type: Task > Components: sql, wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > Fix For: 2.3 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6182) Change default max memory size from 80% to 20%
[
https://issues.apache.org/jira/browse/IGNITE-6182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148013#comment-16148013
]
Igor Seliverstov commented on IGNITE-6182:
--
[~ptupitsyn], [~vozerov], I've changed the PR, please, look at it.
> Change default max memory size from 80% to 20%
> --
>
> Key: IGNITE-6182
> URL: https://issues.apache.org/jira/browse/IGNITE-6182
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Blocker
> Fix For: 2.2
>
>
> Currently we can allocate up to 80% of available RAM by default. It could
> lead to swap with potential risk of hang.
> In order to improve user experience, we need to do the following:
> 1) Decrease default to 20%
> ({{MemoryConfiguration.DFLT_MEMORY_POLICY_FRACTION}})
> 2) When node starts it should sum max sizes of all memory regions plus Java's
> XMX. If result is greater than 50% of total RAM, we should issue a warning
> about potential swap.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6226) Review docs for integration with Apache Zeppelin
[ https://issues.apache.org/jira/browse/IGNITE-6226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147862#comment-16147862 ] Denis Magda commented on IGNITE-6226: - [~ustas], what's wrong with the current documentation? Please elaborate. [~agura], please chime in. > Review docs for integration with Apache Zeppelin > > > Key: IGNITE-6226 > URL: https://issues.apache.org/jira/browse/IGNITE-6226 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.1 >Reporter: Ilya Suntsov >Assignee: Ilya Suntsov > Fix For: 2.3 > > > Now we have non actual documentation for Apache Zeppelin integration: > https://apacheignite.readme.io/v1.1/docs/data-analysis-with-apache-zeppelin?edits=true -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5924) .NET: Decouple Marshaller from Ignite
[
https://issues.apache.org/jira/browse/IGNITE-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147656#comment-16147656
]
Pavel Tupitsyn commented on IGNITE-5924:
May be we should introduce {{IIgniteInternal}} interface instead to decouple
from concrete implementation.
> .NET: Decouple Marshaller from Ignite
> -
>
> Key: IGNITE-5924
> URL: https://issues.apache.org/jira/browse/IGNITE-5924
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> {{Marshaller}} class has {{Ignite}} property, which is used everywhere as a
> convenient accessor.
> With thin client we don't have an {{Ignite}} instance ({{IgniteClient}} is
> there instead).
> Also, {{Marshaller}} itself only needs {{Ignite.BinaryProcessor}}, which is
> also tied to JNI.
> So the plan is:
> * Add {{IBinaryProcessor}} interface
> * Replace {{Marshaller.Ignite}} with {{Marshaller.BinaryProcessor}}
> * Fix external {{Marshaller.Ignite}} usages in some way
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-6227) Delete obsolete benchmarks for Ignite 1.9
[ https://issues.apache.org/jira/browse/IGNITE-6227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zaitsev resolved IGNITE-6227. - Resolution: Done > Delete obsolete benchmarks for Ignite 1.9 > - > > Key: IGNITE-6227 > URL: https://issues.apache.org/jira/browse/IGNITE-6227 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Aleksei Zaitsev >Assignee: Aleksei Zaitsev >Priority: Minor > Labels: benchmarks, yardstick > > Apache Ignite v2.0 and above delivers with benchmarks. So project > https://github.com/apacheignite/yardstick-ignite/ with benchmarks for Ignite > 1.9 became obsolete. To avoid confusion was decided to delete this code and > add direct link to new version of Ignite in the description of the repo. > See dev-list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Yardstick-framework-for-Ignite-2-1-td21087.html#none -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147583#comment-16147583 ] Vyacheslav Daradur commented on IGNITE-5097: [~isapego], thanks a lot! Rerun [ci.tests|https://ci.ignite.apache.org/viewQueued.html?itemId=801015]. > BinaryMarshaller should write ints in "varint" encoding where it makes sense > > > Key: IGNITE-5097 > URL: https://issues.apache.org/jira/browse/IGNITE-5097 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur > Labels: important, performance > Fix For: 2.3 > > > There are a lot of places in the code where we write integers for some > special purposes. Quite often their value will be vary small, so that > applying "varint" format could save a lot of space at the cost of very low > additional CPU overhead. > Specifically: > 1) Array/collection/map lengths > 2) BigDecimal's (usually will save ~6 bytes) > 3) Strings > 4) Enum ordinals -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147544#comment-16147544 ] Igor Sapego commented on IGNITE-5097: - [~daradurvs], I've fixed issues. Please, re-merge changes from my ticket. > BinaryMarshaller should write ints in "varint" encoding where it makes sense > > > Key: IGNITE-5097 > URL: https://issues.apache.org/jira/browse/IGNITE-5097 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur > Labels: important, performance > Fix For: 2.3 > > > There are a lot of places in the code where we write integers for some > special purposes. Quite often their value will be vary small, so that > applying "varint" format could save a lot of space at the cost of very low > additional CPU overhead. > Specifically: > 1) Array/collection/map lengths > 2) BigDecimal's (usually will save ~6 bytes) > 3) Strings > 4) Enum ordinals -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5905) .NET: Thin client: cache.Get for primitives
[
https://issues.apache.org/jira/browse/IGNITE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147508#comment-16147508
]
Pavel Tupitsyn commented on IGNITE-5905:
Merged to {{ignite-5896}}: {{085cc80e5337ff01f7173342b0fa913392aa90a6}}.
> .NET: Thin client: cache.Get for primitives
> ---
>
> Key: IGNITE-5905
> URL: https://issues.apache.org/jira/browse/IGNITE-5905
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> IGNITE-5899 implements cache.Get on Java side and includes a simple raw
> socket test.
> Next step is to provide .NET thin client foundation, so that user can call
> something like
> {{Ignition.GetClient(ClientConfiguration).GetCache(string).Get(...)}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-5931) .NET: Incorrect conflicting type error
[
https://issues.apache.org/jira/browse/IGNITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-5931.
Resolution: Fixed
> .NET: Incorrect conflicting type error
> --
>
> Key: IGNITE-5931
> URL: https://issues.apache.org/jira/browse/IGNITE-5931
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.3
>
>
> Incorrect conflicting type error can occur when registering the same time
> from multiple threads simultaneously:
> {code}
> Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
> {code}
> {{Marshaller.AddType}} should check if existing type is the same as new one
> (as we do it in {{AddUserType}}, see other usages of
> {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147462#comment-16147462 ] Igor Sapego commented on IGNITE-5097: - [~daradurvs], TC shows compilation errors. I'll take a look. > BinaryMarshaller should write ints in "varint" encoding where it makes sense > > > Key: IGNITE-5097 > URL: https://issues.apache.org/jira/browse/IGNITE-5097 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur > Labels: important, performance > Fix For: 2.3 > > > There are a lot of places in the code where we write integers for some > special purposes. Quite often their value will be vary small, so that > applying "varint" format could save a lot of space at the cost of very low > additional CPU overhead. > Specifically: > 1) Array/collection/map lengths > 2) BigDecimal's (usually will save ~6 bytes) > 3) Strings > 4) Enum ordinals -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5931) .NET: Incorrect conflicting type error
[
https://issues.apache.org/jira/browse/IGNITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147459#comment-16147459
]
ASF GitHub Bot commented on IGNITE-5931:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2553
> .NET: Incorrect conflicting type error
> --
>
> Key: IGNITE-5931
> URL: https://issues.apache.org/jira/browse/IGNITE-5931
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.3
>
>
> Incorrect conflicting type error can occur when registering the same time
> from multiple threads simultaneously:
> {code}
> Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
> {code}
> {{Marshaller.AddType}} should check if existing type is the same as new one
> (as we do it in {{AddUserType}}, see other usages of
> {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5931) .NET: Incorrect conflicting type error
[
https://issues.apache.org/jira/browse/IGNITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147450#comment-16147450
]
Pavel Tupitsyn commented on IGNITE-5931:
Merged to master: {{eae6e3b9fd43b42fc9d74e61118800dc0f3f6f0c}}.
> .NET: Incorrect conflicting type error
> --
>
> Key: IGNITE-5931
> URL: https://issues.apache.org/jira/browse/IGNITE-5931
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.3
>
>
> Incorrect conflicting type error can occur when registering the same time
> from multiple threads simultaneously:
> {code}
> Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
> {code}
> {{Marshaller.AddType}} should check if existing type is the same as new one
> (as we do it in {{AddUserType}}, see other usages of
> {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6081) .NET: Cannot get from cache values which were stored in cache with PutAll
[
https://issues.apache.org/jira/browse/IGNITE-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147444#comment-16147444
]
Pavel Tupitsyn commented on IGNITE-6081:
Missing detachment is, indeed, the root cause.
Reproducer: use PutAll with multiple objects that reference each other.
> .NET: Cannot get from cache values which were stored in cache with PutAll
> -
>
> Key: IGNITE-6081
> URL: https://issues.apache.org/jira/browse/IGNITE-6081
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.3
>
>
> If you try to put multiple non-primitive values with dictionary property to
> cache using {{PutAll}}, you'd get an exception on attempt to read those
> values. Code example below:
> {code}
> var entries = new Dictionary();
> for (int i = 0; i < 100; i++)
> entries.Add(i, new SomeType { Id = i });
> var cache = Ignition.GetIgnite().GetCache("CacheName");
> cache.PutAll(entries);
> cache.Get(42);
> {code}
> Pay attention, that {{SomeType}} should have dictionary property.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6081) .NET: Cannot get from cache values which were stored in cache with PutAll
[
https://issues.apache.org/jira/browse/IGNITE-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147442#comment-16147442
]
ASF GitHub Bot commented on IGNITE-6081:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/2555
IGNITE-6081 .NET: Fix PutAll for dependent objects
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-6081
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2555.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 #2555
commit 91f70797d9cfd98c680e02c383127ec0a645a595
Author: Pavel Tupitsyn
Date: 2017-08-30T14:52:40Z
IGNITE-6081 .NET: Cannot get from cache values which were stored in cache
with PutAll
commit 9b701c00e9418f4b42043148b3cc34e9714a09f7
Author: Pavel Tupitsyn
Date: 2017-08-30T14:58:54Z
Improve tests
commit ceab4ae086264adc148e18f6a587d9217904864f
Author: Pavel Tupitsyn
Date: 2017-08-30T15:04:34Z
Fix WriteObjectDetached
commit da46dbd3d0990e473c018faaef251b31403546a2
Author: Pavel Tupitsyn
Date: 2017-08-30T15:23:59Z
Fix tests
commit 7196bc8d2ade90468c301a8113ac473419edbd56
Author: Pavel Tupitsyn
Date: 2017-08-30T15:24:29Z
Fix WriteDictionary
commit 82e10797e4a3fb91ec787bd22f839fcc6042fded
Author: Pavel Tupitsyn
Date: 2017-08-30T15:30:04Z
Fix test
> .NET: Cannot get from cache values which were stored in cache with PutAll
> -
>
> Key: IGNITE-6081
> URL: https://issues.apache.org/jira/browse/IGNITE-6081
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.3
>
>
> If you try to put multiple non-primitive values with dictionary property to
> cache using {{PutAll}}, you'd get an exception on attempt to read those
> values. Code example below:
> {code}
> var entries = new Dictionary();
> for (int i = 0; i < 100; i++)
> entries.Add(i, new SomeType { Id = i });
> var cache = Ignition.GetIgnite().GetCache("CacheName");
> cache.PutAll(entries);
> cache.Get(42);
> {code}
> Pay attention, that {{SomeType}} should have dictionary property.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6228) Avoid closing page store file with ClosedByInterruptException when user thread is interrupted
[
https://issues.apache.org/jira/browse/IGNITE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-6228:
---
Attachment: RestartGridTest.java
> Avoid closing page store file with ClosedByInterruptException when user
> thread is interrupted
> -
>
> Key: IGNITE-6228
> URL: https://issues.apache.org/jira/browse/IGNITE-6228
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
> Fix For: 2.3
>
> Attachments: RestartGridTest.java
>
>
> If cache proxy is in synchronous mode, user thread may be interrupted during
> read from file page store file. This will cause closing of partition file
> with ClosedByInterruptException.
> Example stacktrace:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Runtime failure on lookup
> row:
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@717729d
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1070)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:1476)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:1276)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:394)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:371)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2952)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1012)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:868)
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1680)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:875)
> at
> org.apache.ignite.internal.processors.cache.persistence.db.RestartGridTest$TestService.execute(RestartGridTest.java:160)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$2.run(GridServiceProcessor.java:1160)
> 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: Read error
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:356)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:287)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:272)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:570)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:488)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:129)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.treeMeta(BPlusTree.java:822)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$7700(BPlusTree.java:81)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Get.init(BPlusTree.java:2392)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind(BPlusTree.java:1099)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.fi
[jira] [Updated] (IGNITE-6228) Avoid closing page store file with ClosedByInterruptException when user thread is interrupted
[
https://issues.apache.org/jira/browse/IGNITE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-6228:
---
Description:
If cache proxy is in synchronous mode, user thread may be interrupted during
read from file page store file. This will cause closing of partition file with
ClosedByInterruptException.
Example stacktrace:
{noformat}
class org.apache.ignite.IgniteCheckedException: Runtime failure on lookup row:
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@717729d
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1070)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:1476)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:1276)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:394)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:371)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2952)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at
org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1012)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:868)
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1680)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:875)
at
org.apache.ignite.internal.processors.cache.persistence.db.RestartGridTest$TestService.execute(RestartGridTest.java:160)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$2.run(GridServiceProcessor.java:1160)
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: Read error
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:356)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:287)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:272)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:570)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:488)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:129)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.treeMeta(BPlusTree.java:822)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$7700(BPlusTree.java:81)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Get.init(BPlusTree.java:2392)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind(BPlusTree.java:1099)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1065)
... 20 more
Caused by: java.nio.channels.ClosedByInterruptException
at
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
at sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:746)
at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:724)
at
org.apache.ignite.internal.processors.cache.persistence.file.RandomAccessFileIO.read(RandomAccessFileIO.java:67)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:319)
... 30 more
{noformat}
Any subse
[jira] [Created] (IGNITE-6228) Avoid closing page store file with ClosedByInterruptException when user thread is interrupted
Ivan Rakov created IGNITE-6228:
--
Summary: Avoid closing page store file with
ClosedByInterruptException when user thread is interrupted
Key: IGNITE-6228
URL: https://issues.apache.org/jira/browse/IGNITE-6228
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.1
Reporter: Ivan Rakov
Fix For: 2.3
If cache proxy is in synchronous mode, user thread may be interrupted during
read from file page store file. This will cause closing of partition file with
ClosedByInterruptException.
Example stacktrace:
{noformat}
class org.apache.ignite.IgniteCheckedException: Runtime failure on lookup row:
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@717729d
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1070)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:1476)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:1276)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:394)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:371)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:2952)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
at
org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1012)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:198)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:868)
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1680)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:875)
at
org.apache.ignite.internal.processors.cache.persistence.db.RestartGridTest$TestService.execute(RestartGridTest.java:160)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$2.run(GridServiceProcessor.java:1160)
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: Read error
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:356)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:287)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:272)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:570)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:488)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:129)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.treeMeta(BPlusTree.java:822)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$7700(BPlusTree.java:81)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Get.init(BPlusTree.java:2392)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind(BPlusTree.java:1099)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1065)
... 20 more
Caused by: java.nio.channels.ClosedByInterruptException
at
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
at sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:746)
at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:724)
at
org.apache.ig
[jira] [Created] (IGNITE-6227) Delete obsolete benchmarks for Ignite 1.9
Aleksei Zaitsev created IGNITE-6227: --- Summary: Delete obsolete benchmarks for Ignite 1.9 Key: IGNITE-6227 URL: https://issues.apache.org/jira/browse/IGNITE-6227 Project: Ignite Issue Type: Task Components: yardstick Reporter: Aleksei Zaitsev Assignee: Aleksei Zaitsev Priority: Minor Apache Ignite v2.0 and above delivers with benchmarks. So project https://github.com/apacheignite/yardstick-ignite/ with benchmarks for Ignite 1.9 became obsolete. To avoid confusion was decided to delete this code and add direct link to new version of Ignite in the description of the repo. See dev-list discussion: http://apache-ignite-developers.2346864.n4.nabble.com/Yardstick-framework-for-Ignite-2-1-td21087.html#none -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6212) Assertion error: Invalid node2part
[ https://issues.apache.org/jira/browse/IGNITE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147395#comment-16147395 ] Andrey Gura commented on IGNITE-6212: - Merged to master branch. > Assertion error: Invalid node2part > -- > > Key: IGNITE-6212 > URL: https://issues.apache.org/jira/browse/IGNITE-6212 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.3 > > > Reproduced by IgniteServiceDynamicCachesSelfTest with ~10% probability. Leads > to hang-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5813) Inconsistent cache store state when originating node fails on commit.
[ https://issues.apache.org/jira/browse/IGNITE-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-5813: Assignee: (was: Andrew Mashenkov) > Inconsistent cache store state when originating node fails on commit. > - > > Key: IGNITE-5813 > URL: https://issues.apache.org/jira/browse/IGNITE-5813 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov > Fix For: 2.3 > > Attachments: IgniteTxRecoveryAfterStoreCommitSelfTest.java > > > Same tx can be rolled back by cache and commited by CacheStore. > It is possible when originating tx node commit tx successfully, but fails to > notify other nodes. > PFA reproducer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147386#comment-16147386 ] Vyacheslav Daradur commented on IGNITE-5097: Hi, [~isapego], I've merged your changes to the common PR. Merge conflicts with the master-branch were resolved, please check it yourself. Thanks! Sent to [ci.tests|https://ci.ignite.apache.org/viewQueued.html?itemId=800239]. > BinaryMarshaller should write ints in "varint" encoding where it makes sense > > > Key: IGNITE-5097 > URL: https://issues.apache.org/jira/browse/IGNITE-5097 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur > Labels: important, performance > Fix For: 2.3 > > > There are a lot of places in the code where we write integers for some > special purposes. Quite often their value will be vary small, so that > applying "varint" format could save a lot of space at the cost of very low > additional CPU overhead. > Specifically: > 1) Array/collection/map lengths > 2) BigDecimal's (usually will save ~6 bytes) > 3) Strings > 4) Enum ordinals -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6081) .NET: Cannot get from cache values which were stored in cache with PutAll
[
https://issues.apache.org/jira/browse/IGNITE-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-6081:
---
Summary: .NET: Cannot get from cache values which were stored in cache with
PutAll (was: .NET: Cannot get from cache values which were stored in cache
with PutAll.)
> .NET: Cannot get from cache values which were stored in cache with PutAll
> -
>
> Key: IGNITE-6081
> URL: https://issues.apache.org/jira/browse/IGNITE-6081
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 2.3
>
>
> If you try to put multiple non-primitive values with dictionary property to
> cache using {{PutAll}}, you'd get an exception on attempt to read those
> values. Code example below:
> {code}
> var entries = new Dictionary();
> for (int i = 0; i < 100; i++)
> entries.Add(i, new SomeType { Id = i });
> var cache = Ignition.GetIgnite().GetCache("CacheName");
> cache.PutAll(entries);
> cache.Get(42);
> {code}
> Pay attention, that {{SomeType}} should have dictionary property.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6226) Review docs for integration with Apache Zeppelin
Ilya Suntsov created IGNITE-6226: Summary: Review docs for integration with Apache Zeppelin Key: IGNITE-6226 URL: https://issues.apache.org/jira/browse/IGNITE-6226 Project: Ignite Issue Type: Bug Components: documentation Affects Versions: 2.1 Reporter: Ilya Suntsov Assignee: Ilya Suntsov Fix For: 2.3 Now we have non actual documentation for Apache Zeppelin integration: https://apacheignite.readme.io/v1.1/docs/data-analysis-with-apache-zeppelin?edits=true -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6225) Improve tests of WAL iterator with checking DataRecord entries and TxRecords
Dmitriy Pavlov created IGNITE-6225: -- Summary: Improve tests of WAL iterator with checking DataRecord entries and TxRecords Key: IGNITE-6225 URL: https://issues.apache.org/jira/browse/IGNITE-6225 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.1 Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Fix For: 2.3 There is WAL Iterator implemented under [IGNITE-5558] which allows to iterate over WAL log records without Ignite instance up and running. This feature was covered by test IgniteWalReaderTest#testFillWalAndReadRecords() It is required to cover transactional put and check of this transaction results from test code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6225) Improve tests of WAL iterator with checking DataRecord entries and TxRecords
[ https://issues.apache.org/jira/browse/IGNITE-6225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6225: --- Issue Type: Test (was: Bug) > Improve tests of WAL iterator with checking DataRecord entries and TxRecords > > > Key: IGNITE-6225 > URL: https://issues.apache.org/jira/browse/IGNITE-6225 > Project: Ignite > Issue Type: Test > Components: persistence >Affects Versions: 2.1 >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov > Fix For: 2.3 > > > There is WAL Iterator implemented under [IGNITE-5558] which allows to iterate > over WAL log records without Ignite instance up and running. > This feature was covered by test > IgniteWalReaderTest#testFillWalAndReadRecords() > It is required to cover transactional put and check of this transaction > results from test code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6139) JDBC driver should return actual values for get*Version()
[ https://issues.apache.org/jira/browse/IGNITE-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-6139: Fix Version/s: 2.3 Component/s: jdbc > JDBC driver should return actual values for get*Version() > - > > Key: IGNITE-6139 > URL: https://issues.apache.org/jira/browse/IGNITE-6139 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > Fix For: 2.3 > > > Right now it returns: > Database version 1.0 (suggested - actual version from server nodes) > JDBC version 1.0 (suggested - 4.1, that's what's in Java 7) > Driver version 1.0 (suggested - actual version of running Ignite code) > Database product name is "Ignite Cache", probably keep that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5931) .NET: Incorrect conflicting type error
[
https://issues.apache.org/jira/browse/IGNITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147316#comment-16147316
]
Pavel Tupitsyn edited comment on IGNITE-5931 at 8/30/17 2:32 PM:
-
Fixed race condition and affinity attribute issues. Ideally entire
{{Marshaller}} class should be refactored later.
was (Author: ptupitsyn):
Race condition and affinity attribute issues. Ideally entire {{Marshaller}}
class should be refactored later.
> .NET: Incorrect conflicting type error
> --
>
> Key: IGNITE-5931
> URL: https://issues.apache.org/jira/browse/IGNITE-5931
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.3
>
>
> Incorrect conflicting type error can occur when registering the same time
> from multiple threads simultaneously:
> {code}
> Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
> {code}
> {{Marshaller.AddType}} should check if existing type is the same as new one
> (as we do it in {{AddUserType}}, see other usages of
> {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5931) .NET: Incorrect conflicting type error
[
https://issues.apache.org/jira/browse/IGNITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147316#comment-16147316
]
Pavel Tupitsyn commented on IGNITE-5931:
Race condition and affinity attribute issues. Ideally entire {{Marshaller}}
class should be refactored later.
> .NET: Incorrect conflicting type error
> --
>
> Key: IGNITE-5931
> URL: https://issues.apache.org/jira/browse/IGNITE-5931
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.3
>
>
> Incorrect conflicting type error can occur when registering the same time
> from multiple threads simultaneously:
> {code}
> Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
> {code}
> {{Marshaller.AddType}} should check if existing type is the same as new one
> (as we do it in {{AddUserType}}, see other usages of
> {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5931) .NET: Incorrect conflicting type error
[
https://issues.apache.org/jira/browse/IGNITE-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147305#comment-16147305
]
ASF GitHub Bot commented on IGNITE-5931:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/2553
IGNITE-5931 .NET: Fix type registration race condition
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-5931
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2553.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 #2553
commit 0b4a79e282cc568fc9327eade112021763cabafe
Author: Pavel Tupitsyn
Date: 2017-08-04T12:52:06Z
IGNITE-5931 .NET: Incorrect conflicting type error
commit 9791e5603e65ec9cd9b885a29764d6c1e6a38b02
Author: Pavel Tupitsyn
Date: 2017-08-04T13:13:21Z
wip TODOs
commit c5f056d5830238c62cf0f5f5e7ac27bbee1047c2
Author: Pavel Tupitsyn
Date: 2017-08-04T13:51:24Z
wip
commit 09140819cae37e3b5476796c1881547cefcbb724
Author: Pavel Tupitsyn
Date: 2017-08-04T13:59:04Z
Fix the bug
commit 3fd2b4e43e9001c287846f005a8bcceeea7b64a0
Author: Pavel Tupitsyn
Date: 2017-08-04T14:07:01Z
Update affkey test
commit 06518f402d3da1eb85d01a5fb6ce00e2ed89b519
Author: Pavel Tupitsyn
Date: 2017-08-04T14:30:43Z
wip
commit 87052c9854d9d62262d7b77a35f0238029c4a7ac
Author: Pavel Tupitsyn
Date: 2017-08-04T14:32:12Z
wip
commit 7bed61cedc1964c358431a5aee91f690786febb7
Author: Pavel Tupitsyn
Date: 2017-08-04T14:59:01Z
wip refactoring
commit 3553b42444f531617376864b3f3990ef5247557e
Author: Pavel Tupitsyn
Date: 2017-08-04T15:13:29Z
wip
commit 96e1118ea0cff1137a22afa12282f6d4ad351026
Author: Pavel Tupitsyn
Date: 2017-08-04T16:04:30Z
wip
commit 91c58c3259373e2e1e170ce523b42d91b3257654
Author: Pavel Tupitsyn
Date: 2017-08-29T14:39:43Z
Merge branch 'master' into ignite-5931
commit 1196082d45ca23c13e74e4c3701ff58d213fb71e
Author: Pavel Tupitsyn
Date: 2017-08-29T15:40:59Z
Merge branch 'master' into ignite-5931
commit ca93028a0400e7d0a3a780e4b7c13af216bcb20d
Author: Pavel Tupitsyn
Date: 2017-08-29T16:45:37Z
wip
commit ad9717fa263316a9e7a48cd4615c2abbdb7e3992
Author: Pavel Tupitsyn
Date: 2017-08-29T16:57:51Z
wip
commit 2e952243bf343fdc1a32ef7c705817e758a27cf9
Author: Pavel Tupitsyn
Date: 2017-08-29T16:59:31Z
wip
commit 1ffd89fb7bdca9f4958078d982fb96da3d89092b
Author: Pavel Tupitsyn
Date: 2017-08-29T17:04:44Z
wip
commit f4d265f7599c63d672f410553053046a6bfa1814
Author: Pavel Tupitsyn
Date: 2017-08-29T17:06:03Z
wip
commit f284248f2b4c78d546028501dc7d8b33f67b1350
Author: Pavel Tupitsyn
Date: 2017-08-29T17:18:01Z
wip
commit 77e66c6b41bcfe8f1bbabfd7e34bab00d6a098b4
Author: Pavel Tupitsyn
Date: 2017-08-30T06:25:49Z
Add multithreaded registration test
commit 416def32a3cda5710dfe8a2603cb4424fdbc7889
Author: Pavel Tupitsyn
Date: 2017-08-30T06:40:11Z
Fix multithreaded test
commit 54a6f52cf31944144269760aaa8ac437558366a8
Author: Pavel Tupitsyn
Date: 2017-08-30T07:37:32Z
Fix multithreaded test
commit 4b75c67702247f8109cd6c1baa5e682749b51860
Author: Pavel Tupitsyn
Date: 2017-08-30T13:59:21Z
Remove unnecessary type name check
commit 1eff0ab4a71e7f490b4d1dc9cdfdbc6883266260
Author: Pavel Tupitsyn
Date: 2017-08-30T14:06:23Z
Revert some changes
commit 7035023be9d83286d52c825eb68b6973c169c91f
Author: Pavel Tupitsyn
Date: 2017-08-30T14:15:47Z
Improve tests
commit 5e11cbeee10db9caa5ea72cd11e41efb4027deec
Author: Pavel Tupitsyn
Date: 2017-08-30T14:21:32Z
Fix affinity key field name
commit d0135e02115be57e70bb02e6a040d7976d18bc6d
Author: Pavel Tupitsyn
Date: 2017-08-30T14:26:17Z
Remove incorrect registration test
> .NET: Incorrect conflicting type error
> --
>
> Key: IGNITE-5931
> URL: https://issues.apache.org/jira/browse/IGNITE-5931
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.3
>
>
> Incorrect conflicting type error can occur when registering the same time
> from multiple threads simultaneously:
> {code}
> Conflicting type IDs [type1='Row', type2='Row', typeId=113114]
> {code}
> {{Marshaller.AddType}} should check if existing type is the same as new one
> (as we do it in {{AddUserType}}, see other usages of
> {{ThrowConflictingTypeError}}).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6139) JDBC driver should return actual values for get*Version()
[ https://issues.apache.org/jira/browse/IGNITE-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147304#comment-16147304 ] ASF GitHub Bot commented on IGNITE-6139: GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/2552 IGNITE-6139 Actual version info in Thick JDBC metadata queries. Also fix Product Name to "Apache Ignite" You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6139 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2552.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 #2552 commit d3e8e3f5015e00f1162ea0f16e7acc5656eb5b47 Author: Ilya Kasnacheev Date: 2017-08-30T14:25:31Z IGNITE-6139 Actual version info in Thick JDBC metadata queries. Also fix Product Name to "Apache Ignite" > JDBC driver should return actual values for get*Version() > - > > Key: IGNITE-6139 > URL: https://issues.apache.org/jira/browse/IGNITE-6139 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > > Right now it returns: > Database version 1.0 (suggested - actual version from server nodes) > JDBC version 1.0 (suggested - 4.1, that's what's in Java 7) > Driver version 1.0 (suggested - actual version of running Ignite code) > Database product name is "Ignite Cache", probably keep that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5879) .NET: Move TestPlatformPlugin to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147246#comment-16147246 ] Pavel Tupitsyn commented on IGNITE-5879: Sounds good to me. > .NET: Move TestPlatformPlugin to a separate module > -- > > Key: IGNITE-5879 > URL: https://issues.apache.org/jira/browse/IGNITE-5879 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.1 >Reporter: Pavel Tupitsyn >Assignee: Vyacheslav Daradur > Labels: .NET > Fix For: 2.3 > > > Move test plugin to a separate module and load it only for .NET tests so we > don't interfere with other tests. > Dev list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Plugins-in-tests-td20167.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147239#comment-16147239 ] ASF GitHub Bot commented on IGNITE-5097: GitHub user daradurvs opened a pull request: https://github.com/apache/ignite/pull/2549 IGNITE-5097 BinaryMarshaller should write ints in "varint" encoding where it makes sense You can merge this pull request into a Git repository by running: $ git pull https://github.com/daradurvs/ignite ignite-5097-release Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2549.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 #2549 commit 779b607a783bbbedca7b9b42a915e968aa4027eb Author: Vyacheslav Daradur Date: 2017-08-30T11:40:59Z IGNITE-5097 BinaryMarshaller should write ints in "varint" encoding where it makes sense commit aa5f957c9a01dcb962b1df6be2f5ba8db94e491a Author: Igor Sapego Date: 2017-08-30T13:16:06Z IGNITE-5153 CPP: Introduced varint encoding in C++ > BinaryMarshaller should write ints in "varint" encoding where it makes sense > > > Key: IGNITE-5097 > URL: https://issues.apache.org/jira/browse/IGNITE-5097 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur > Labels: important, performance > Fix For: 2.3 > > > There are a lot of places in the code where we write integers for some > special purposes. Quite often their value will be vary small, so that > applying "varint" format could save a lot of space at the cost of very low > additional CPU overhead. > Specifically: > 1) Array/collection/map lengths > 2) BigDecimal's (usually will save ~6 bytes) > 3) Strings > 4) Enum ordinals -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense
[ https://issues.apache.org/jira/browse/IGNITE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147240#comment-16147240 ] ASF GitHub Bot commented on IGNITE-5097: Github user daradurvs closed the pull request at: https://github.com/apache/ignite/pull/2043 > BinaryMarshaller should write ints in "varint" encoding where it makes sense > > > Key: IGNITE-5097 > URL: https://issues.apache.org/jira/browse/IGNITE-5097 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur > Labels: important, performance > Fix For: 2.3 > > > There are a lot of places in the code where we write integers for some > special purposes. Quite often their value will be vary small, so that > applying "varint" format could save a lot of space at the cost of very low > additional CPU overhead. > Specifically: > 1) Array/collection/map lengths > 2) BigDecimal's (usually will save ~6 bytes) > 3) Strings > 4) Enum ordinals -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6125) Improve robustness for JDBC driver metadata queries
[ https://issues.apache.org/jira/browse/IGNITE-6125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6125: Component/s: (was: clients) > Improve robustness for JDBC driver metadata queries > --- > > Key: IGNITE-6125 > URL: https://issues.apache.org/jira/browse/IGNITE-6125 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > Fix For: 2.3 > > > org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata is in worrysome state: > - Makes frivolous use of toUpperCase() to address former. > - getPrimaryKeys() never returns anything because of defective use of > toUpperCase(). > - No tests on indexes, primary keys, schemas or parameters metadata retrieval. > - Ignores "catalog" parameter instead of checking if it matches empty catalog. > - See also IGNITE-6138, IGNITE-6139 > That should be fixes without compromising backwards compatibility too much. > Tests may be borrowed from thin client implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6125) Improve robustness for JDBC driver metadata queries
[ https://issues.apache.org/jira/browse/IGNITE-6125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147234#comment-16147234 ] ASF GitHub Bot commented on IGNITE-6125: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2506 > Improve robustness for JDBC driver metadata queries > --- > > Key: IGNITE-6125 > URL: https://issues.apache.org/jira/browse/IGNITE-6125 > Project: Ignite > Issue Type: Task > Components: clients, jdbc >Affects Versions: 2.1 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev > Fix For: 2.3 > > > org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata is in worrysome state: > - Makes frivolous use of toUpperCase() to address former. > - getPrimaryKeys() never returns anything because of defective use of > toUpperCase(). > - No tests on indexes, primary keys, schemas or parameters metadata retrieval. > - Ignores "catalog" parameter instead of checking if it matches empty catalog. > - See also IGNITE-6138, IGNITE-6139 > That should be fixes without compromising backwards compatibility too much. > Tests may be borrowed from thin client implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6219) IgniteCache#loadCache executes local load in caller thread
[
https://issues.apache.org/jira/browse/IGNITE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-6219:
Fix Version/s: (was: 2.2)
2.3
> IgniteCache#loadCache executes local load in caller thread
> --
>
> Key: IGNITE-6219
> URL: https://issues.apache.org/jira/browse/IGNITE-6219
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>Priority: Critical
> Fix For: 2.3
>
>
> {{IgniteCache#loadCache}} method broadcasts an internal task under the hood.
> If one of the jobs are local (i.e. if {{loadCache}} is invoked on server
> node), this job is executed in a caller thread, potentially *before all or
> some remote requests are sent*. Since data loading is generally long running
> process, its duration doubles in this scenario.
> Possible solution is to check the list of nodes before task execution, and if
> local node is there, execute on remote nodes first, and only then submit to
> local node. This way we make sure that remote nodes never wait for the local
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6212) Assertion error: Invalid node2part
[ https://issues.apache.org/jira/browse/IGNITE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh updated IGNITE-6212: - Fix Version/s: 2.3 > Assertion error: Invalid node2part > -- > > Key: IGNITE-6212 > URL: https://issues.apache.org/jira/browse/IGNITE-6212 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.3 > > > Reproduced by IgniteServiceDynamicCachesSelfTest with ~10% probability. Leads > to hang-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6221) ContinuousQuery. Local listener notified if filter throws exception
[
https://issues.apache.org/jira/browse/IGNITE-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-6221:
Fix Version/s: (was: 2.2)
2.3
> ContinuousQuery. Local listener notified if filter throws exception
> ---
>
> Key: IGNITE-6221
> URL: https://issues.apache.org/jira/browse/IGNITE-6221
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.3
>
>
> Local listener of continuous query receives event if filter throw exception
> from `evaluate`.
> Steps to reproduce the bug:
> 1. Run continuous query with remote filter.
> 2. Throw exception from filter.
> Current behavior:
> 3. Local listener notified.
> Expected behavior:
> 3. Local listener doesn't notify.
> [Mail-list
> discussion|http://apache-ignite-developers.2346864.n4.nabble.com/ContinuousQueryWithTransformer-implementation-questions-2-td21418.html]
> Filter description from [jcache
> Javadoc|https://static.javadoc.io/javax.cache/cache-api/1.0.0/javax/cache/event/CacheEntryEventFilter.html#evaluate(javax.cache.event.CacheEntryEvent)]:
> {noformat}
> Returns:
>true if the evaluation passes, otherwise false.
>The effect of returning true is that listener will be invoked
> {noformat}
> Test to reproduce error:
> {code:java}
> package org.apache.ignite.internal.processors.cache.query.continuous;
> import java.io.Serializable;
> import javax.cache.Cache;
> import javax.cache.event.CacheEntryEvent;
> import javax.cache.event.CacheEntryUpdatedListener;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheEntryEventSerializableFilter;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.query.ContinuousQuery;
> import org.apache.ignite.cache.query.QueryCursor;
> public class GridCacheContinuousQueryFilterExceptionTest extends
> GridCacheContinuousQueryAbstractSelfTest implements Serializable {
> /**
> * @throws Exception If failed.
> */
> public void testListenerAfterFilterException() throws Exception {
> IgniteCache cache =
> grid(0).cache(DEFAULT_CACHE_NAME);
> ContinuousQuery qry = new ContinuousQuery<>();
> qry.setLocalListener(new CacheEntryUpdatedListener Integer>() {
> @Override public void onUpdated(Iterable extends Integer, ? extends Integer>> evts) {
> fail("Listener shouldn't be called");
> }
> });
> qry.setRemoteFilter(new CacheEntryEventSerializableFilter Integer>() {
> @Override public boolean evaluate(CacheEntryEvent Integer, ? extends Integer> evt) {
> throw new RuntimeException("Test error.");
> }
> });
> try (QueryCursor> ignored =
> cache.query(qry)) {
> for (int i = 0; i < 100; i++)
> cache.put(i, i);
> }
> }
> @Override protected CacheMode cacheMode() {
> return CacheMode.REPLICATED;
> }
> @Override protected int gridCount() {
> return 1;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-6146) JDBC thin: improve error handling, supports vendorCode and SQLState
[
https://issues.apache.org/jira/browse/IGNITE-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko resolved IGNITE-6146.
-
Resolution: Duplicate
Assignee: Alexander Paschenko
> JDBC thin: improve error handling, supports vendorCode and SQLState
> ---
>
> Key: IGNITE-6146
> URL: https://issues.apache.org/jira/browse/IGNITE-6146
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Alexander Paschenko
>
> {{SQLException}} must provide useful information about an error via the
> {{vendorCode}} and {{SQLState}} properties.
> See more: [SQLState
> messages|ftp://ftp.software.ibm.com/ps/products/db2/info/vr6/htm/db2m0/db2state.htm#HDRSTTMSG].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5905) .NET: Thin client: cache.Get for primitives
[
https://issues.apache.org/jira/browse/IGNITE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147162#comment-16147162
]
Vladimir Ozerov commented on IGNITE-5905:
-
[~ptupitsyn], looks good to me.
> .NET: Thin client: cache.Get for primitives
> ---
>
> Key: IGNITE-5905
> URL: https://issues.apache.org/jira/browse/IGNITE-5905
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.3
>
>
> IGNITE-5899 implements cache.Get on Java side and includes a simple raw
> socket test.
> Next step is to provide .NET thin client foundation, so that user can call
> something like
> {{Ignition.GetClient(ClientConfiguration).GetCache(string).Get(...)}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6212) Assertion error: Invalid node2part
[ https://issues.apache.org/jira/browse/IGNITE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh updated IGNITE-6212: - Fix Version/s: (was: 2.2) > Assertion error: Invalid node2part > -- > > Key: IGNITE-6212 > URL: https://issues.apache.org/jira/browse/IGNITE-6212 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Critical > Labels: MakeTeamcityGreenAgain > > Reproduced by IgniteServiceDynamicCachesSelfTest with ~10% probability. Leads > to hang-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5205) Optimize SQL messaging
[ https://issues.apache.org/jira/browse/IGNITE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147154#comment-16147154 ] Vladimir Ozerov commented on IGNITE-5205: - [~skalashnikov], solution was implemented in IGNITE-6034. Benchmarks shown no effect. Closing this ticket as duplicate. > Optimize SQL messaging > -- > > Key: IGNITE-5205 > URL: https://issues.apache.org/jira/browse/IGNITE-5205 > Project: Ignite > Issue Type: Task > Components: general, sql >Affects Versions: 2.0 >Reporter: Sergi Vladykin > Labels: important > > Currently we create Message object for each H2 Value being sent or received > over the wire. Lets write and read them directly without intermediate > conversions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-5205) Optimize SQL messaging
[ https://issues.apache.org/jira/browse/IGNITE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-5205. --- > Optimize SQL messaging > -- > > Key: IGNITE-5205 > URL: https://issues.apache.org/jira/browse/IGNITE-5205 > Project: Ignite > Issue Type: Task > Components: general, sql >Affects Versions: 2.0 >Reporter: Sergi Vladykin > Labels: important > > Currently we create Message object for each H2 Value being sent or received > over the wire. Lets write and read them directly without intermediate > conversions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-5205) Optimize SQL messaging
[ https://issues.apache.org/jira/browse/IGNITE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-5205. - Resolution: Duplicate > Optimize SQL messaging > -- > > Key: IGNITE-5205 > URL: https://issues.apache.org/jira/browse/IGNITE-5205 > Project: Ignite > Issue Type: Task > Components: general, sql >Affects Versions: 2.0 >Reporter: Sergi Vladykin > Labels: important > > Currently we create Message object for each H2 Value being sent or received > over the wire. Lets write and read them directly without intermediate > conversions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6193) ML profile is missing in 2.1 binary release
[ https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147150#comment-16147150 ] ASF GitHub Bot commented on IGNITE-6193: Github user oignatenko closed the pull request at: https://github.com/apache/ignite/pull/2537 > ML profile is missing in 2.1 binary release > --- > > Key: IGNITE-6193 > URL: https://issues.apache.org/jira/browse/IGNITE-6193 > Project: Ignite > Issue Type: Bug >Reporter: Denis Magda >Assignee: Oleg Ignatenko >Priority: Blocker > Fix For: 2.2 > > > In Apache Ignite 2.0 we added the ML profile to the binary release that > allowed activating this functionality and running the examples easily. The > getting started is written based on the profile presence: > https://apacheignite.readme.io/docs/machine-learning#section-getting-started > The profile is missing for 2.1 release. To reproduce the issue just download > 2.1 binary release and follow the getting started section, you'll stumble on > step 4: > https://apacheignite.readme.io/docs/machine-learning#section-getting-started > This has to be fixed as soon as possible and the fix should be merged both in > the master and in a branch of the urgent Ignite release that is discussed > here: > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6034) SQL: Optimize GridQueryNextPageResponse memory consumption
[
https://issues.apache.org/jira/browse/IGNITE-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6034:
Fix Version/s: (was: 2.3)
> SQL: Optimize GridQueryNextPageResponse memory consumption
> --
>
> Key: IGNITE-6034
> URL: https://issues.apache.org/jira/browse/IGNITE-6034
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Labels: performance
> Attachments: IGNITE_6034.patch
>
>
> Currently we store data in {{GridQueryNextPageResponse}} in message wrappers.
> This can be avoided easily, if we add custom converter interface which could
> be passed to our direct marshaller facility.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6034) SQL: Optimize GridQueryNextPageResponse memory consumption
[
https://issues.apache.org/jira/browse/IGNITE-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147146#comment-16147146
]
Vladimir Ozerov commented on IGNITE-6034:
-
Benchmarks didn't show any improvement. Closing the ticket as "Won't Fix".
Attaching patch in case we would like to resurrect it later.
> SQL: Optimize GridQueryNextPageResponse memory consumption
> --
>
> Key: IGNITE-6034
> URL: https://issues.apache.org/jira/browse/IGNITE-6034
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Labels: performance
> Attachments: IGNITE_6034.patch
>
>
> Currently we store data in {{GridQueryNextPageResponse}} in message wrappers.
> This can be avoided easily, if we add custom converter interface which could
> be passed to our direct marshaller facility.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (IGNITE-6034) SQL: Optimize GridQueryNextPageResponse memory consumption
[
https://issues.apache.org/jira/browse/IGNITE-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6034.
---
> SQL: Optimize GridQueryNextPageResponse memory consumption
> --
>
> Key: IGNITE-6034
> URL: https://issues.apache.org/jira/browse/IGNITE-6034
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Labels: performance
> Attachments: IGNITE_6034.patch
>
>
> Currently we store data in {{GridQueryNextPageResponse}} in message wrappers.
> This can be avoided easily, if we add custom converter interface which could
> be passed to our direct marshaller facility.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6034) SQL: Optimize GridQueryNextPageResponse memory consumption
[
https://issues.apache.org/jira/browse/IGNITE-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6034:
Attachment: IGNITE_6034.patch
> SQL: Optimize GridQueryNextPageResponse memory consumption
> --
>
> Key: IGNITE-6034
> URL: https://issues.apache.org/jira/browse/IGNITE-6034
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Labels: performance
> Fix For: 2.3
>
> Attachments: IGNITE_6034.patch
>
>
> Currently we store data in {{GridQueryNextPageResponse}} in message wrappers.
> This can be avoided easily, if we add custom converter interface which could
> be passed to our direct marshaller facility.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5879) .NET: Move TestPlatformPlugin to a separate module
[ https://issues.apache.org/jira/browse/IGNITE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147144#comment-16147144 ] Yakov Zhdanov commented on IGNITE-5879: --- [~ptupitsyn][~daradurvs] I would rename the module to "ignite-extdata-platform" and move it to "modules/extdata". We already have two modules there. Please have a look. Thanks! > .NET: Move TestPlatformPlugin to a separate module > -- > > Key: IGNITE-5879 > URL: https://issues.apache.org/jira/browse/IGNITE-5879 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.1 >Reporter: Pavel Tupitsyn >Assignee: Vyacheslav Daradur > Labels: .NET > Fix For: 2.3 > > > Move test plugin to a separate module and load it only for .NET tests so we > don't interfere with other tests. > Dev list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Plugins-in-tests-td20167.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6219) IgniteCache#loadCache executes local load in caller thread
[
https://issues.apache.org/jira/browse/IGNITE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147140#comment-16147140
]
ASF GitHub Bot commented on IGNITE-6219:
GitHub user dkarachentsev opened a pull request:
https://github.com/apache/ignite/pull/2548
IGNITE-6219 - IgniteCache#loadCache executes local load in caller thread
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6219
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2548.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 #2548
commit fcda4f1af212883f2b12f3185a5f897157f82a8d
Author: dkarachentsev
Date: 2017-08-30T10:39:05Z
IGNITE-6219 - IgniteCache#loadCache executes local load in caller thread
> IgniteCache#loadCache executes local load in caller thread
> --
>
> Key: IGNITE-6219
> URL: https://issues.apache.org/jira/browse/IGNITE-6219
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>Priority: Critical
> Fix For: 2.2
>
>
> {{IgniteCache#loadCache}} method broadcasts an internal task under the hood.
> If one of the jobs are local (i.e. if {{loadCache}} is invoked on server
> node), this job is executed in a caller thread, potentially *before all or
> some remote requests are sent*. Since data loading is generally long running
> process, its duration doubles in this scenario.
> Possible solution is to check the list of nodes before task execution, and if
> local node is there, execute on remote nodes first, and only then submit to
> local node. This way we make sure that remote nodes never wait for the local
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5813) Inconsistent cache store state when originating node fails on commit.
[ https://issues.apache.org/jira/browse/IGNITE-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147123#comment-16147123 ] Andrey Gura commented on IGNITE-5813: - We can't just invalidate entries because in this case store and cache states will be still inconsistent. It's ok for get operations with readThrough enabled but SQl queries will return wrong results. > Inconsistent cache store state when originating node fails on commit. > - > > Key: IGNITE-5813 > URL: https://issues.apache.org/jira/browse/IGNITE-5813 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Fix For: 2.3 > > Attachments: IgniteTxRecoveryAfterStoreCommitSelfTest.java > > > Same tx can be rolled back by cache and commited by CacheStore. > It is possible when originating tx node commit tx successfully, but fails to > notify other nodes. > PFA reproducer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6219) IgniteCache#loadCache executes local load in caller thread
[
https://issues.apache.org/jira/browse/IGNITE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev reassigned IGNITE-6219:
---
Assignee: Dmitry Karachentsev
> IgniteCache#loadCache executes local load in caller thread
> --
>
> Key: IGNITE-6219
> URL: https://issues.apache.org/jira/browse/IGNITE-6219
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>Priority: Critical
> Fix For: 2.2
>
>
> {{IgniteCache#loadCache}} method broadcasts an internal task under the hood.
> If one of the jobs are local (i.e. if {{loadCache}} is invoked on server
> node), this job is executed in a caller thread, potentially *before all or
> some remote requests are sent*. Since data loading is generally long running
> process, its duration doubles in this scenario.
> Possible solution is to check the list of nodes before task execution, and if
> local node is there, execute on remote nodes first, and only then submit to
> local node. This way we make sure that remote nodes never wait for the local
> node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution
[ https://issues.apache.org/jira/browse/IGNITE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-6217: - Fix Version/s: (was: 2.2) 2.3 > Add benchmark to compare JDBC drivers and native SQL execution > -- > > Key: IGNITE-6217 > URL: https://issues.apache.org/jira/browse/IGNITE-6217 > Project: Ignite > Issue Type: Task > Components: jdbc, sql, yardstick >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.3 > > > We have to compare performance of the native SQL execution (via Ignite SQL > API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC > thin client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6193) ML profile is missing in 2.1 binary release
[ https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147085#comment-16147085 ] Anton Vinogradov edited comment on IGNITE-6193 at 8/30/17 11:19 AM: [~oignatenko], Merged to 2.2 and master. Thanks for contribution. was (Author: avinogradov): Merged to 2.2 and master. Thanks for contribution. > ML profile is missing in 2.1 binary release > --- > > Key: IGNITE-6193 > URL: https://issues.apache.org/jira/browse/IGNITE-6193 > Project: Ignite > Issue Type: Bug >Reporter: Denis Magda >Assignee: Oleg Ignatenko >Priority: Blocker > Fix For: 2.2 > > > In Apache Ignite 2.0 we added the ML profile to the binary release that > allowed activating this functionality and running the examples easily. The > getting started is written based on the profile presence: > https://apacheignite.readme.io/docs/machine-learning#section-getting-started > The profile is missing for 2.1 release. To reproduce the issue just download > 2.1 binary release and follow the getting started section, you'll stumble on > step 4: > https://apacheignite.readme.io/docs/machine-learning#section-getting-started > This has to be fixed as soon as possible and the fix should be merged both in > the master and in a branch of the urgent Ignite release that is discussed > here: > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6212) Assertion error: Invalid node2part
[ https://issues.apache.org/jira/browse/IGNITE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov reassigned IGNITE-6212: Assignee: Ilya Lantukh (was: Semen Boikov) Looks ok. Thanks > Assertion error: Invalid node2part > -- > > Key: IGNITE-6212 > URL: https://issues.apache.org/jira/browse/IGNITE-6212 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.2 > > > Reproduced by IgniteServiceDynamicCachesSelfTest with ~10% probability. Leads > to hang-up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5855) SQL: BigInteger support broken in SQL queries.
[ https://issues.apache.org/jira/browse/IGNITE-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147061#comment-16147061 ] Ilya Kasnacheev commented on IGNITE-5855: - I have updated my pull request. Now fixes the specific issue only without other changes. > SQL: BigInteger support broken in SQL queries. > -- > > Key: IGNITE-5855 > URL: https://issues.apache.org/jira/browse/IGNITE-5855 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.0, 2.1 >Reporter: Andrew Mashenkov >Assignee: Ilya Kasnacheev > Attachments: BigIntegerKeySqlTest.java > > > Looks like BigInteger support in SQL was broken. > It works fine on ignite-1.9 > PFA reproducer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147063#comment-16147063 ] ASF GitHub Bot commented on IGNITE-4645: Github user gvvinblade closed the pull request at: https://github.com/apache/ignite/pull/1488 > Best effort to avoid extra copying in binary marshaller > --- > > Key: IGNITE-4645 > URL: https://issues.apache.org/jira/browse/IGNITE-4645 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Yakov Zhdanov >Assignee: Igor Seliverstov > Fix For: 2.3 > > > If we marshal a class that contain only primitives then we can predict the > final byte array size and avoid copies to grow array and final trimming. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6224) Node stoping does not wait all transactions completion
[
https://issues.apache.org/jira/browse/IGNITE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-6224:
--
Attachment: TransactionBehindStopNodeTest.java
> Node stoping does not wait all transactions completion
> --
>
> Key: IGNITE-6224
> URL: https://issues.apache.org/jira/browse/IGNITE-6224
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
> Attachments: TransactionBehindStopNodeTest.java
>
>
> I have started grid node and executing transaction over some cache. After I
> stopped the node in the middle execution of transaction. I got transaction
> execution exception:
> {noformat}
> java.lang.IllegalStateException: class
> org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
> perform cache operation (cache is stopped): cache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
> at
> org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
> 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:2000)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> although I stopped node with _false_ {{cancel}} flag.
> {code}
> G.stop(getTestIgniteInstanceName(0), false);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6224) Node stoping does not wait all transactions completion
[
https://issues.apache.org/jira/browse/IGNITE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-6224:
--
Description:
I have started grid node and executing transaction over some cache. After I
stopped the node in the middle execution of transaction. I got transaction
execution exception:
{noformat}
java.lang.IllegalStateException: class
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
perform cache operation (cache is stopped): cache
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
at
org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
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:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}
although I stopped node with _false_ {{cancel}} flag.
{code}
G.stop(getTestIgniteInstanceName(0), false);
{code}
was:
I have started grid node and executing transaction over some cache. After I
stopped the node in the middle execution of transaction. I got transaction
execution exception:
{noformat}
java.lang.IllegalStateException: class
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
perform cache operation (cache is stopped): cache
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
at
org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
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:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}
although I stopped node with _false_ {{canceled}} flag.
{code}
G.stop(getTestIgniteInstanceName(0), false);
{code}
> Node stoping does not wait all transactions completion
> --
>
> Key: IGNITE-6224
> URL: https://issues.apache.org/jira/browse/IGNITE-6224
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
> Attachments: TransactionBehindStopNodeTest.java
>
>
> I have started grid node and executing transaction over some cache. After I
> stopped the node in the middle execution of transaction. I got transaction
> execution exception:
> {noformat}
> java.lang.IllegalStateException: class
> org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
> perform cache operation (cache is stopped): cache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
> at
> org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodA
[jira] [Updated] (IGNITE-6224) Node stoping does not wait all transactions completion
[
https://issues.apache.org/jira/browse/IGNITE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-6224:
--
Description:
I have started grid node and executing transaction over some cache. After I
stopped the node in the middle execution of transaction. I got transaction
execution exception:
{noformat}
java.lang.IllegalStateException: class
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
perform cache operation (cache is stopped): cache
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
at
org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
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:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}
although I stopped node with _false_ {{canceled}} flag.
{code}
G.stop(getTestIgniteInstanceName(0), false);
{code}
was:
I have started grid node and executing transaction over some cache. After I
stopped the node in the middle execution of transaction. I have got transaction
execution exception:
{noformat}
java.lang.IllegalStateException: class
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
perform cache operation (cache is stopped): cache
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
at
org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
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:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}
also I stopped node with _false_ {{canceled}} flag.
{code}
G.stop(getTestIgniteInstanceName(0), false);
{code}
> Node stoping does not wait all transactions completion
> --
>
> Key: IGNITE-6224
> URL: https://issues.apache.org/jira/browse/IGNITE-6224
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>
> I have started grid node and executing transaction over some cache. After I
> stopped the node in the middle execution of transaction. I got transaction
> execution exception:
> {noformat}
> java.lang.IllegalStateException: class
> org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
> perform cache operation (cache is stopped): cache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
> at
> org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
[jira] [Created] (IGNITE-6224) Node stoping does not wait all transactions completion
Vladislav Pyatkov created IGNITE-6224:
-
Summary: Node stoping does not wait all transactions completion
Key: IGNITE-6224
URL: https://issues.apache.org/jira/browse/IGNITE-6224
Project: Ignite
Issue Type: Bug
Affects Versions: 2.1
Reporter: Vladislav Pyatkov
I have started grid node and executing transaction over some cache. After I
stopped the node in the middle execution of transaction. I have got transaction
execution exception:
{noformat}
java.lang.IllegalStateException: class
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
perform cache operation (cache is stopped): cache
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
at
org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
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:2000)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}
also I stopped node with _false_ {{canceled}} flag.
{code}
G.stop(getTestIgniteInstanceName(0), false);
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6182) Change default max memory size from 80% to 20%
[
https://issues.apache.org/jira/browse/IGNITE-6182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147052#comment-16147052
]
Pavel Tupitsyn commented on IGNITE-6182:
[~gvvinblade] .NET is not updated, and
{{IgniteConfigurationTest.TestSpringXml}} fails because of this. Make sure .NET
suites are all green.
> Change default max memory size from 80% to 20%
> --
>
> Key: IGNITE-6182
> URL: https://issues.apache.org/jira/browse/IGNITE-6182
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Blocker
> Fix For: 2.2
>
>
> Currently we can allocate up to 80% of available RAM by default. It could
> lead to swap with potential risk of hang.
> In order to improve user experience, we need to do the following:
> 1) Decrease default to 20%
> ({{MemoryConfiguration.DFLT_MEMORY_POLICY_FRACTION}})
> 2) When node starts it should sum max sizes of all memory regions plus Java's
> XMX. If result is greater than 50% of total RAM, we should issue a warning
> about potential swap.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6182) Change default max memory size from 80% to 20%
[
https://issues.apache.org/jira/browse/IGNITE-6182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147052#comment-16147052
]
Pavel Tupitsyn edited comment on IGNITE-6182 at 8/30/17 10:50 AM:
--
[~gvvinblade] .NET is not updated, and
{{IgniteConfigurationTest.TestSpringXml}} fails because of this. Make sure .NET
suites are all green.
See {{MemoryPolicyConfiguration.DefaultMaxSize}}.
was (Author: ptupitsyn):
[~gvvinblade] .NET is not updated, and
{{IgniteConfigurationTest.TestSpringXml}} fails because of this. Make sure .NET
suites are all green.
> Change default max memory size from 80% to 20%
> --
>
> Key: IGNITE-6182
> URL: https://issues.apache.org/jira/browse/IGNITE-6182
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Blocker
> Fix For: 2.2
>
>
> Currently we can allocate up to 80% of available RAM by default. It could
> lead to swap with potential risk of hang.
> In order to improve user experience, we need to do the following:
> 1) Decrease default to 20%
> ({{MemoryConfiguration.DFLT_MEMORY_POLICY_FRACTION}})
> 2) When node starts it should sum max sizes of all memory regions plus Java's
> XMX. If result is greater than 50% of total RAM, we should issue a warning
> about potential swap.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6182) Change default max memory size from 80% to 20%
[
https://issues.apache.org/jira/browse/IGNITE-6182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147014#comment-16147014
]
Vladimir Ozerov edited comment on IGNITE-6182 at 8/30/17 10:13 AM:
---
[~gvvinblade],
Looks overly complex to me. Thinking of it a little bit more, I would do the
following:
1) Exclude JVM heap. We never had such check before, even when we were on-heap
solution, and never had any problems with it. Moreover, we do not know how much
heap will be used by user application.
2) Share only total maximum of all memory regions + checkpoint buffer size. If
it exceeds 80% of machine's ram - print a warning.
was (Author: vozerov):
[~gvvinblade],
Looks overly complex to me. Thinking of it a little bit more, I would do the
following:
1) Exclude JVM heap. We never had such check before, even when we were on-heap
solution, and never had any problems with it. Moreover, we do not know how much
heap will be used by user application.
2) Share only total maximum of all memory regions + checkpoint buffer size. If
it exceeds 80% of machines ram - print a warning.
> Change default max memory size from 80% to 20%
> --
>
> Key: IGNITE-6182
> URL: https://issues.apache.org/jira/browse/IGNITE-6182
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Blocker
> Fix For: 2.2
>
>
> Currently we can allocate up to 80% of available RAM by default. It could
> lead to swap with potential risk of hang.
> In order to improve user experience, we need to do the following:
> 1) Decrease default to 20%
> ({{MemoryConfiguration.DFLT_MEMORY_POLICY_FRACTION}})
> 2) When node starts it should sum max sizes of all memory regions plus Java's
> XMX. If result is greater than 50% of total RAM, we should issue a warning
> about potential swap.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6193) ML profile is missing in 2.1 binary release
[ https://issues.apache.org/jira/browse/IGNITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145333#comment-16145333 ] Oleg Ignatenko edited comment on IGNITE-6193 at 8/30/17 10:11 AM: -- (/) TC: https://ci.ignite.apache.org/viewLog.html?buildId=799856&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteExamples (/) I managed to reproduce reported issue in branch ignite-6193 prior to the changes (missing ML in examples) and verify that it was resolved after the changes (ML appeared in examples and respective examples run as expected). (/) Verified that Ignite builds properly with the changes (build per DEVNOTES and per [readme.io|https://apacheignite.readme.io/docs/machine-learning]). was (Author: oignatenko): (/) TC: https://ci.ignite.apache.org/viewLog.html?buildId=797829&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteMl (/) I managed to reproduce reported issue in branch ignite-6193 prior to the changes (missing ML in examples) and verify that it was resolved after the changes (ML appeared in examples and respective examples run as expected). (/) Verified that Ignite builds properly with the changes (build per DEVNOTES and per [readme.io|https://apacheignite.readme.io/docs/machine-learning]). > ML profile is missing in 2.1 binary release > --- > > Key: IGNITE-6193 > URL: https://issues.apache.org/jira/browse/IGNITE-6193 > Project: Ignite > Issue Type: Bug >Reporter: Denis Magda >Assignee: Oleg Ignatenko >Priority: Blocker > Fix For: 2.2 > > > In Apache Ignite 2.0 we added the ML profile to the binary release that > allowed activating this functionality and running the examples easily. The > getting started is written based on the profile presence: > https://apacheignite.readme.io/docs/machine-learning#section-getting-started > The profile is missing for 2.1 release. To reproduce the issue just download > 2.1 binary release and follow the getting started section, you'll stumble on > step 4: > https://apacheignite.readme.io/docs/machine-learning#section-getting-started > This has to be fixed as soon as possible and the fix should be merged both in > the master and in a branch of the urgent Ignite release that is discussed > here: > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Urgent-Ignite-bug-fix-release-td21292.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6182) Change default max memory size from 80% to 20%
[
https://issues.apache.org/jira/browse/IGNITE-6182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147014#comment-16147014
]
Vladimir Ozerov commented on IGNITE-6182:
-
[~gvvinblade],
Looks overly complex to me. Thinking of it a little bit more, I would do the
following:
1) Exclude JVM heap. We never had such check before, even when we were on-heap
solution, and never had any problems with it. Moreover, we do not know how much
heap will be used by user application.
2) Share only total maximum of all memory regions + checkpoint buffer size. If
it exceeds 80% of machines ram - print a warning.
> Change default max memory size from 80% to 20%
> --
>
> Key: IGNITE-6182
> URL: https://issues.apache.org/jira/browse/IGNITE-6182
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Blocker
> Fix For: 2.2
>
>
> Currently we can allocate up to 80% of available RAM by default. It could
> lead to swap with potential risk of hang.
> In order to improve user experience, we need to do the following:
> 1) Decrease default to 20%
> ({{MemoryConfiguration.DFLT_MEMORY_POLICY_FRACTION}})
> 2) When node starts it should sum max sizes of all memory regions plus Java's
> XMX. If result is greater than 50% of total RAM, we should issue a warning
> about potential swap.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6089) SQL: Improve query parallelism architecture
[
https://issues.apache.org/jira/browse/IGNITE-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147010#comment-16147010
]
Andrew Mashenkov commented on IGNITE-6089:
--
Microsoft suggest next architecture of parallel query execution.
Just leave it here, may it will help.
https://technet.microsoft.com/en-us/library/ms175097(v=sql.105).aspx
> SQL: Improve query parallelism architecture
> ---
>
> Key: IGNITE-6089
> URL: https://issues.apache.org/jira/browse/IGNITE-6089
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
> Labels: performance
>
> Currently query parallelism implement with static split of all indexes
> (including PK) for cache. This approach has several major disadvantages:
> 1) It improves scans, but slows down index and range lookups
> 2) Tables with different DOP cannot be used in the same query
> We need to fix that. Proposed plan:
> 1) No more index splits, ever - there is one and only one index always
> 2) Use preliminary execution plan, statistics (IGNITE-6079), CPU cores count
> and CPU load to estimate whether query will benefit from parallelism.
> 3) if yes - split node-s single map query into several independent pieces.
> Splitting can be achieved in one of the following ways:
> 1) Partition-based: e.g. if node owns partitions A, B, C and D, then we can
> split it to two queries - one over (A, B), another over (C, D). This could be
> useful for pure scans (e.g. DWH)
> 2) Histogram-based: e.g. if we have a query {{SELECT ... WHERE salary > 50}},
> and we know salary distribution, we can split it into {{WHERE salary > 50 AND
> salary <= 200}} and {{WHERE salary > 200}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6175) JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite
[
https://issues.apache.org/jira/browse/IGNITE-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-6175:
---
Labels: MakeTeamcityGreenAgain (was: )
> JVM Crash in "Ignite Binary Objects Simple Mapper Basic" suite
> ---
>
> Key: IGNITE-6175
> URL: https://issues.apache.org/jira/browse/IGNITE-6175
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Andrey Gura
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> JVM crash dump and logs you could find here
> https://ci.ignite.apache.org/viewLog.html?buildTypeId=Ignite20Tests_IgniteBinarySImpleMapperBasic&buildId=785893&branch_Ignite20Tests_IgniteBinarySImpleMapperBasic=pull/2380/head
> {code}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7f6a0274a13f, pid=3507, tid=140092082124544
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build
> 1.7.0_80-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # J 10572 C2
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readLock(Lorg/apache/ignite/internal/pagemem/PageMemory;IJJLorg/apache/ignite/internal/processors/cache/persistence/tree/util/PageLockListener;)J
> (39 bytes) @ 0x7f6a0274a13f [0x7f6a02749ba0+0x59f]
> #
> # Core dump written. Default location:
> /data/teamcity/work/820be461cd64b574/core or core.3507
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> # {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6179) Test fail DynamicIndexReplicatedAtomicConcurrentSelfTest.testClientReconnectWithCacheRestart
[
https://issues.apache.org/jira/browse/IGNITE-6179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-6179:
---
Labels: MakeTeamcityGreenAgain (was: )
> Test fail
> DynamicIndexReplicatedAtomicConcurrentSelfTest.testClientReconnectWithCacheRestart
>
>
> Key: IGNITE-6179
> URL: https://issues.apache.org/jira/browse/IGNITE-6179
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Dmitriy Govorukhin
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
> Attachments: log
>
>
> Test fail with assertion
> {code}
> [2017-08-24
> 18:34:06,207][ERROR][tcp-client-disco-msg-worker-#61%index.DynamicIndexReplicatedAtomicConcurrentSelfTest4%][IgniteClientReconnectAbstractTest$TestTcpDiscoverySpi]
> Failed to unmarshal discovery custom message.
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onSchemaFinishDiscovery(GridQueryProcessor.java:498)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onDiscovery(GridQueryProcessor.java:894)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onCustomEvent(GridCacheProcessor.java:2906)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:660)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:560)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2391)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2297)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1874)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1758)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6223) Web console: Agent fail to send task result on job fail.
[ https://issues.apache.org/jira/browse/IGNITE-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-6223: - Assignee: Andrey Novikov (was: Vasiliy Sisko) > Web console: Agent fail to send task result on job fail. > > > Key: IGNITE-6223 > URL: https://issues.apache.org/jira/browse/IGNITE-6223 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.1 >Reporter: Vasiliy Sisko >Assignee: Andrey Novikov > Fix For: 2.3 > > > On job fail Web agent return NPE instead of reason exception. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6119) ODBC: Propagate "lazy" flag
[ https://issues.apache.org/jira/browse/IGNITE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146981#comment-16146981 ] Vladimir Ozerov commented on IGNITE-6119: - [~isapego], I think we should decouple ODBC and JDBC protocol versions. Their lifecycle should not be tied to each other. > ODBC: Propagate "lazy" flag > --- > > Key: IGNITE-6119 > URL: https://issues.apache.org/jira/browse/IGNITE-6119 > Project: Ignite > Issue Type: Task > Components: odbc >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Igor Sapego > Labels: usability > Fix For: 2.3 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6223) Web console: Agent fail to send task result on job fail.
[ https://issues.apache.org/jira/browse/IGNITE-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146983#comment-16146983 ] Vasiliy Sisko commented on IGNITE-6223: --- Fixed send of task result when job execution is failed. > Web console: Agent fail to send task result on job fail. > > > Key: IGNITE-6223 > URL: https://issues.apache.org/jira/browse/IGNITE-6223 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.1 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > Fix For: 2.3 > > > On job fail Web agent return NPE instead of reason exception. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6119) ODBC: Propagate "lazy" flag
[ https://issues.apache.org/jira/browse/IGNITE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145795#comment-16145795 ] Igor Sapego edited comment on IGNITE-6119 at 8/30/17 9:41 AM: -- Ready for review. [~tledkov-gridgain], [~vozerov], take a look please. was (Author: isapego): Ready for review. [~tledkov-gridgain], take a look please. > ODBC: Propagate "lazy" flag > --- > > Key: IGNITE-6119 > URL: https://issues.apache.org/jira/browse/IGNITE-6119 > Project: Ignite > Issue Type: Task > Components: odbc >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Igor Sapego > Labels: usability > Fix For: 2.3 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6223) Web console: Agent fail to send task result on job fail.
[ https://issues.apache.org/jira/browse/IGNITE-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-6223: -- Summary: Web console: Agent fail to send task result on job fail. (was: Web console: Agent faile to send task result on job fail.) > Web console: Agent fail to send task result on job fail. > > > Key: IGNITE-6223 > URL: https://issues.apache.org/jira/browse/IGNITE-6223 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.1 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > Fix For: 2.3 > > > On job fail Web agent return NPE instead of reason exception. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6223) Web console: Agent faile to send task result on job fail.
Vasiliy Sisko created IGNITE-6223: - Summary: Web console: Agent faile to send task result on job fail. Key: IGNITE-6223 URL: https://issues.apache.org/jira/browse/IGNITE-6223 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 2.1 Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Fix For: 2.3 On job fail Web agent return NPE instead of reason exception. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (IGNITE-6119) ODBC: Propagate "lazy" flag
[
https://issues.apache.org/jira/browse/IGNITE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-6119:
Comment: was deleted
(was: [~tledkov-gridgain]
1. There is {{VER_2_3_0}}, see SqlListenerNioListener.java:55
2. {{SUPPORTED_VERS}} contains {{CURRENT_VER}}, so everything is fine. Of
course, tests pass.)
> ODBC: Propagate "lazy" flag
> ---
>
> Key: IGNITE-6119
> URL: https://issues.apache.org/jira/browse/IGNITE-6119
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Labels: usability
> Fix For: 2.3
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Issue Comment Deleted] (IGNITE-6119) ODBC: Propagate "lazy" flag
[
https://issues.apache.org/jira/browse/IGNITE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-6119:
-
Comment: was deleted
(was: [~isapego], my commets:
1. Why final field isn't used for new protocol version (see {{VER_2_1_0}} &
{{CURRENT_VER}})?
2. Looks like protocol is broken. Listener awaits 2.3 version but
{{SUPPORTED_VERS}} doesn't contain version 2.3. Are the tests OK?)
> ODBC: Propagate "lazy" flag
> ---
>
> Key: IGNITE-6119
> URL: https://issues.apache.org/jira/browse/IGNITE-6119
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Labels: usability
> Fix For: 2.3
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5337) CPP: linux examples: names of executable files should be the same type
[ https://issues.apache.org/jira/browse/IGNITE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Chetaev updated IGNITE-5337: Description: C++ linux examples: make executable file names the same type: ignate--example now names are: ignite-continuous-query-example ignite-odbcexample ignite-putgetexample ignite-queryexample was: C++ linux examples: make executable file names the same type: ignate--example now names are: ignite-continuous-query-example ignite-odbcexample ignite-putgetexample ignite-queryexample > CPP: linux examples: names of executable files should be the same type > -- > > Key: IGNITE-5337 > URL: https://issues.apache.org/jira/browse/IGNITE-5337 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.0 >Reporter: Irina Zaporozhtseva >Assignee: Igor Sapego >Priority: Minor > Labels: cpp, examples > Fix For: 2.1 > > > C++ linux examples: make executable file names the same type: > ignate--example > now names are: > ignite-continuous-query-example > ignite-odbcexample > ignite-putgetexample > ignite-queryexample -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4720) Sporadically fails for Hadoop
[ https://issues.apache.org/jira/browse/IGNITE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Chetaev updated IGNITE-4720: Description: hadoop example aggregatewordcount under apache ignite hadoop edition grid with 4 nodes for hadoop-2_6_4 and hadoop-2_7_2: aggregatewordcount returns 999712 instead of 100 was: hadoop example aggregatewordcount under apache ignite hadoop edition grid with 4 nodes for hadoop-2_6_4 and hadoop-2_7_2: aggregatewordcount returns 999712 instead of 100 > Sporadically fails for Hadoop > - > > Key: IGNITE-4720 > URL: https://issues.apache.org/jira/browse/IGNITE-4720 > Project: Ignite > Issue Type: Bug > Components: hadoop >Affects Versions: 1.8 >Reporter: Irina Zaporozhtseva >Assignee: Ivan Veselovsky > Fix For: 1.9 > > > hadoop example aggregatewordcount under apache ignite hadoop edition grid > with 4 nodes for hadoop-2_6_4 and hadoop-2_7_2: > aggregatewordcount returns 999712 instead of 100 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4898) Add path to ODBC driver installers to platforms\cpp\odbc\README.txt
[ https://issues.apache.org/jira/browse/IGNITE-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Chetaev updated IGNITE-4898: Description: Add path to ODBC driver installers (/cpp/bin/odbc/) to platforms\cpp\odbc\README.txt: "There are two ways to install ODBC driver currently. The first one is to use 32-bit or 64-bit installer. This is the most simple way and you are recommended to stick to it by default." was: Add path to ODBC driver installers (/cpp/bin/odbc/) to platforms\cpp\odbc\README.txt: "There are two ways to install ODBC driver currently. The first one is to use 32-bit or 64-bit installer. This is the most simple way and you are recommended to stick to it by default." > Add path to ODBC driver installers to platforms\cpp\odbc\README.txt > --- > > Key: IGNITE-4898 > URL: https://issues.apache.org/jira/browse/IGNITE-4898 > Project: Ignite > Issue Type: Bug > Components: documentation, platforms >Reporter: Irina Zaporozhtseva >Assignee: Denis Magda > Fix For: 2.0 > > > Add path to ODBC driver installers (/cpp/bin/odbc/) to > platforms\cpp\odbc\README.txt: > "There are two ways to install ODBC driver currently. The first one is to use > 32-bit or 64-bit installer. This is the most simple way and you are > recommended to stick to it by default." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5506) Datagrid.StoreExample fails when run with standalone Apache Ignite.NET node
[
https://issues.apache.org/jira/browse/IGNITE-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Chetaev updated IGNITE-5506:
Description:
{{Datagrid.StoreExample}} fails when run with standalone Apache Ignite.NET node
{code}
Apache.Ignite.Core.Cache.CacheException was unhandled
HResult=-2146233088
Message=class org.apache.ignite.IgniteCheckedException: Could not load file
or assembly 'Apache.Ignite.ExamplesDll, Version=1.0.6375.29467,
Culture=neutral, PublicKeyToken=c27524977cb332ce' or one of its dependencies.
The system cannot find the file specified.
Source=Apache.Ignite.Core
StackTrace:
at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void*
target, Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte*
errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32
stackTraceCharsLen, Void* errData, Int32 errDataLen)
at
Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.TargetInLongOutLong(Void*
ctx, Void* target, Int32 opType, Int64 val)
at
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInLongOutLong(IUnmanagedTarget
target, Int32 opType, Int64 memPtr)
at Apache.Ignite.Core.Impl.Cache.CacheImpl`2.Clear()
at Apache.Ignite.Examples.Datagrid.StoreExample.Main() in
C:\work\gridgain-professional-fabric-2.1.1.b3_23\platforms\dotnet\examples\Apache.Ignite.Examples\Datagrid\StoreExample.cs:line
67
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[]
args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence
assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:
HResult=-2146233088
Message=Could not load file or assembly 'Apache.Ignite.ExamplesDll,
Version=1.0.6375.29467, Culture=neutral, PublicKeyToken=c27524977cb332ce' or
one of its dependencies. The system cannot find the file specified.
InnerException:
HResult=-2146233088
JavaClassName=javax.cache.CacheException
JavaMessage=class org.apache.ignite.IgniteCheckedException: Could
not load file or assembly 'Apache.Ignite.ExamplesDll, Version=1.0.6375.29467,
Culture=neutral, PublicKeyToken=c27524977cb332ce' or one of its dependencies.
The system cannot find the file specified.
Message=javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Could not load file or assembly
'Apache.Ignite.ExamplesDll, Version=1.0.6375.29467, Culture=neutral,
PublicKeyToken=c27524977cb332ce' or one of its dependencies. The system cannot
find the file specified.
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1323)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2629)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.clear(IgniteCacheProxy.java:2049)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInLongOutLong(PlatformCache.java:1088)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:53)
Caused by: class org.apache.ignite.IgniteCheckedException: Could not load file
or assembly 'Apache.Ignite.ExamplesDll, Version=1.0.6375.29467,
Culture=neutral, PublicKeyToken=c27524977cb332ce' or one of its dependencies.
The system cannot find the file specified.
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7229)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:166)
at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.clearLocally(GridCacheProxyImpl.java:974)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$GlobalClearAllJob.localExecute(GridCacheAdapter.java:5142)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$TopologyVersionAwareJob.execute(GridCacheAdapter.java:6099)
at
org.apache.ignite.internal.proc
[jira] [Updated] (IGNITE-5898) .NET: Datagrid.QueryDmlExample: Incorrect result if run example with standalone Apache Ignite.NET node
[
https://issues.apache.org/jira/browse/IGNITE-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Chetaev updated IGNITE-5898:
Description:
{{Datagrid.QueryDmlExample}}: Incorrect result if run example with standalone
Apache Ignite.NET node
without standalone node:
{code}
>>> Inserted data
>>> 1: John Doe, ASF, 4000
>>> 2: Jane Roe, ASF, 5000
>>> 3: Mary Major, Eclipse, 2000
>>> 4: Richard Miles, Eclipse, 3000
>>> Update salary for ASF employees
>>> 1: John Doe, ASF, 4400
>>> 2: Jane Roe, ASF, 5500
>>> 3: Mary Major, Eclipse, 2000
>>> 4: Richard Miles, Eclipse, 3000
>>> Delete non-ASF employees
>>> 1: John Doe, ASF, 4400
>>> 2: Jane Roe, ASF, 5500
{code}
with standalone node:
{code}
>>> Inserted data
>>> 1: John Doe, ASF, 4000
>>> 3: Mary Major, Eclipse, 2000
>>> Update salary for ASF employees
>>> 1: John Doe, ASF, 4400
>>> 3: Mary Major, Eclipse, 2000
>>> Delete non-ASF employees
>>> 1: John Doe, ASF, 4400
{code}
was:
{{Datagrid.QueryDmlExample}}: Incorrect result if run example with standalone
Apache Ignite.NET node
without standalone node:
{code}
>>> Inserted data
>>> 1: John Doe, ASF, 4000
>>> 2: Jane Roe, ASF, 5000
>>> 3: Mary Major, Eclipse, 2000
>>> 4: Richard Miles, Eclipse, 3000
>>> Update salary for ASF employees
>>> 1: John Doe, ASF, 4400
>>> 2: Jane Roe, ASF, 5500
>>> 3: Mary Major, Eclipse, 2000
>>> 4: Richard Miles, Eclipse, 3000
>>> Delete non-ASF employees
>>> 1: John Doe, ASF, 4400
>>> 2: Jane Roe, ASF, 5500
{code}
with standalone node:
{code}
>>> Inserted data
>>> 1: John Doe, ASF, 4000
>>> 3: Mary Major, Eclipse, 2000
>>> Update salary for ASF employees
>>> 1: John Doe, ASF, 4400
>>> 3: Mary Major, Eclipse, 2000
>>> Delete non-ASF employees
>>> 1: John Doe, ASF, 4400
{code}
> .NET: Datagrid.QueryDmlExample: Incorrect result if run example with
> standalone Apache Ignite.NET node
> ---
>
> Key: IGNITE-5898
> URL: https://issues.apache.org/jira/browse/IGNITE-5898
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.9, 2.1
>Reporter: Irina Zaporozhtseva
>Priority: Minor
> Labels: .NET
>
> {{Datagrid.QueryDmlExample}}: Incorrect result if run example with standalone
> Apache Ignite.NET node
> without standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 2: Jane Roe, ASF, 5000
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> >>> 3: Mary Major, Eclipse, 2000
> >>> 4: Richard Miles, Eclipse, 3000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 2: Jane Roe, ASF, 5500
> {code}
> with standalone node:
> {code}
> >>> Inserted data
> >>> 1: John Doe, ASF, 4000
> >>> 3: Mary Major, Eclipse, 2000
> >>> Update salary for ASF employees
> >>> 1: John Doe, ASF, 4400
> >>> 3: Mary Major, Eclipse, 2000
> >>> Delete non-ASF employees
> >>> 1: John Doe, ASF, 4400
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5919) .NET: EntryProcessorExample closes immediately after execution
[
https://issues.apache.org/jira/browse/IGNITE-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Chetaev updated IGNITE-5919:
Description:
EntryProcessorExample closes immediately after execution. Please, add:
Console.WriteLine();
Console.WriteLine(">>> Example finished, press any key to exit ...");
Console.ReadKey();
was:
EntryProcessorExample closes immediately after execution. Please, add:
Console.WriteLine();
Console.WriteLine(">>> Example finished, press any key to exit ...");
Console.ReadKey();
> .NET: EntryProcessorExample closes immediately after execution
> --
>
> Key: IGNITE-5919
> URL: https://issues.apache.org/jira/browse/IGNITE-5919
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 1.9
>Reporter: Irina Zaporozhtseva
>Priority: Minor
> Labels: .NET
>
> EntryProcessorExample closes immediately after execution. Please, add:
> Console.WriteLine();
> Console.WriteLine(">>> Example finished, press any key to exit ...");
> Console.ReadKey();
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5525) C++ ODBC example fails
[ https://issues.apache.org/jira/browse/IGNITE-5525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Chetaev updated IGNITE-5525: Description: C++ ODBC example fails: >>> Cache ODBC example started. [15:12:08,620][SEVERE][sql-connector-#38%null%][OdbcRequestHandler] Failed to execute SQL query [reqId=1, req=OdbcQueryExecuteRequest [schema=PUBLIC, sqlQry=INSERT INTO Person (_key, orgId, firstName, lastName, resume, salary) VALUES (?, ?, ?, ?, ?, ?)�, args=[1, 1, John, Doe, Master Degree., 2200.0]]] class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse query: INSERT INTO Person (_key, orgId, firstName, lastName, resume, salary) VALUES (?, ?, ?, ?, ?, ?) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293) at org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1856) at org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1852) at org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36) at org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293) at org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1860) at org.apache.ignite.internal.processors.odbc.odbc.OdbcRequestHandler.executeQuery(OdbcRequestHandler.java:177) at org.apache.ignite.internal.processors.odbc.odbc.OdbcRequestHandler.handle(OdbcRequestHandler.java:116) at org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:152) at org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.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:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON" not found; SQL statement: INSERT INTO Person (_key, orgId, firstName, lastName, resume, salary) VALUES (?, ?, ?, ?, ?, ?) [42102-195] at org.h2.message.DbException.getJdbcSQLException(DbException.java:345) at org.h2.message.DbException.get(DbException.java:179) at org.h2.message.DbException.get(DbException.java:155) at org.h2.command.Parser.readTableOrView(Parser.java:5506) at org.h2.command.Parser.readTableOrView(Parser.java:5483) at org.h2.command.Parser.parseInsert(Parser.java:1056) at org.h2.command.Parser.parsePrepared(Parser.java:416) at org.h2.command.Parser.parse(Parser.java:320) at org.h2.command.Parser.parse(Parser.java:292) at org.h2.command.Parser.prepareCommand(Parser.java:257) at org.h2.engine.Session.prepareLocal(Session.java:573) at org.h2.engine.Session.prepareCommand(Session.java:514) at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1204) at org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:73) at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:288) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:398) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1273) ... 17 more An error occurred: Failed to execute prepared statement: HY000: class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse query: INSERT INTO Person (_key, orgId, firstName, lastName, resume, salary) VALUES (?, ?, ?, ?, ?, ?) >>> Example finished, press 'Enter' to exit ... was: C++ ODBC example fails: >>> Cache ODBC example started. [15:12:08,620][SEVERE][sql-connector-#38%null%][OdbcRequestHandler] Failed to execute SQL query [reqId=1, req=OdbcQueryExecuteRequest [schema=PUBLIC, sqlQry=INSERT INTO Person (_key, orgId, firstName, lastName, resume, salary) VALUES (?, ?, ?, ?, ?, ?)�, args=[1, 1, John, Doe, Master Degree., 2200.0]]] class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse query: INSERT INTO Pers
[jira] [Updated] (IGNITE-6157) C++: Query example: Incorrect output if run example with standalone node
[
https://issues.apache.org/jira/browse/IGNITE-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Chetaev updated IGNITE-6157:
Description:
C++: Query example: Incorrect output if run example with standalone node
without standalone node:
{code}
Following people have 'Master' in their resumes:
1 : Person [orgId=1, lastName=Doe, firstName=John, salary=2000, resume=John Doe
has Master Degree.]
4 : Person [orgId=2, lastName=Smith, firstName=Jane, salary=2000, resume=Jane
Smith has Master Degree.]
Following people have 'Bachelor' in their resumes:
2 : Person [orgId=1, lastName=Doe, firstName=Jane, salary=1000, resume=Jane Doe
has Bachelor Degree.]
3 : Person [orgId=2, lastName=Smith, firstName=John, salary=1000, resume=John
Smith has Bachelor Degree.]
{code}
with standalone node (rows are repeated):
{code}
Following people have 'Master' in their resumes:
1 : Person [orgId=1, lastName=Doe, firstName=John, salary=2000, resume=John Doe
has Master Degree.]
1 : Person [orgId=1, lastName=Doe, firstName=John, salary=2000, resume=John Doe
has Master Degree.]
4 : Person [orgId=2, lastName=Smith, firstName=Jane, salary=2000, resume=Jane
Smith has Master Degree.]
Following people have 'Bachelor' in their resumes:
2 : Person [orgId=1, lastName=Doe, firstName=Jane, salary=1000, resume=Jane Doe
has Bachelor Degree.]
3 : Person [orgId=2, lastName=Smith, firstName=John, salary=1000, resume=John
Smith has Bachelor Degree.]
2 : Person [orgId=1, lastName=Doe, firstName=Jane, salary=1000, resume=Jane Doe
has Bachelor Degree.]
3 : Person [orgId=2, lastName=Smith, firstName=John, salary=1000, resume=John
Smith has Bachelor Degree.]
{code}
was:
C++: Query example: Incorrect output if run example with standalone node
without standalone node:
{code}
Following people have 'Master' in their resumes:
1 : Person [orgId=1, lastName=Doe, firstName=John, salary=2000, resume=John Doe
has Master Degree.]
4 : Person [orgId=2, lastName=Smith, firstName=Jane, salary=2000, resume=Jane
Smith has Master Degree.]
Following people have 'Bachelor' in their resumes:
2 : Person [orgId=1, lastName=Doe, firstName=Jane, salary=1000, resume=Jane Doe
has Bachelor Degree.]
3 : Person [orgId=2, lastName=Smith, firstName=John, salary=1000, resume=John
Smith has Bachelor Degree.]
{code}
with standalone node (rows are repeated):
{code}
Following people have 'Master' in their resumes:
1 : Person [orgId=1, lastName=Doe, firstName=John, salary=2000, resume=John Doe
has Master Degree.]
1 : Person [orgId=1, lastName=Doe, firstName=John, salary=2000, resume=John Doe
has Master Degree.]
4 : Person [orgId=2, lastName=Smith, firstName=Jane, salary=2000, resume=Jane
Smith has Master Degree.]
Following people have 'Bachelor' in their resumes:
2 : Person [orgId=1, lastName=Doe, firstName=Jane, salary=1000, resume=Jane Doe
has Bachelor Degree.]
3 : Person [orgId=2, lastName=Smith, firstName=John, salary=1000, resume=John
Smith has Bachelor Degree.]
2 : Person [orgId=1, lastName=Doe, firstName=Jane, salary=1000, resume=Jane Doe
has Bachelor Degree.]
3 : Person [orgId=2, lastName=Smith, firstName=John, salary=1000, resume=John
Smith has Bachelor Degree.]
{code}
> C++: Query example: Incorrect output if run example with standalone node
>
>
> Key: IGNITE-6157
> URL: https://issues.apache.org/jira/browse/IGNITE-6157
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.9
>Reporter: Irina Zaporozhtseva
>Priority: Minor
> Labels: c++
>
> C++: Query example: Incorrect output if run example with standalone node
> without standalone node:
> {code}
> Following people have 'Master' in their resumes:
> 1 : Person [orgId=1, lastName=Doe, firstName=John, salary=2000, resume=John
> Doe has Master Degree.]
> 4 : Person [orgId=2, lastName=Smith, firstName=Jane, salary=2000, resume=Jane
> Smith has Master Degree.]
> Following people have 'Bachelor' in their resumes:
> 2 : Person [orgId=1, lastName=Doe, firstName=Jane, salary=1000, resume=Jane
> Doe has Bachelor Degree.]
> 3 : Person [orgId=2, lastName=Smith, firstName=John, salary=1000, resume=John
> Smith has Bachelor Degree.]
> {code}
> with standalone node (rows are repeated):
> {code}
> Following people have 'Master' in their resumes:
> 1 : Person [orgId=1, lastName=Doe, firstName=John, salary=2000, resume=John
> Doe has Master Degree.]
> 1 : Person [orgId=1, lastName=Doe, firstName=John, salary=2000, resume=John
> Doe has Master Degree.]
> 4 : Person [orgId=2, lastName=Smith, firstName=Jane, salary=2000, resume=Jane
> Smith has Master Degree.]
> Following people have 'Bachelor' in their resumes:
> 2 : Person [orgId=1, lastName=Doe, firstName=Jane, salary=1000, resume=Jane
> Doe has Bachelor Degree.]
>
[jira] [Commented] (IGNITE-6119) ODBC: Propagate "lazy" flag
[
https://issues.apache.org/jira/browse/IGNITE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146957#comment-16146957
]
Igor Sapego commented on IGNITE-6119:
-
[~tledkov-gridgain]
1. There is {{VER_2_3_0}}, see SqlListenerNioListener.java:55
2. {{SUPPORTED_VERS}} contains {{CURRENT_VER}}, so everything is fine. Of
course, tests pass.
> ODBC: Propagate "lazy" flag
> ---
>
> Key: IGNITE-6119
> URL: https://issues.apache.org/jira/browse/IGNITE-6119
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Labels: usability
> Fix For: 2.3
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6119) ODBC: Propagate "lazy" flag
[
https://issues.apache.org/jira/browse/IGNITE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146908#comment-16146908
]
Taras Ledkov edited comment on IGNITE-6119 at 8/30/17 9:29 AM:
---
[~isapego], my commets:
1. Why final field isn't used for new protocol version (see {{VER_2_1_0}} &
{{CURRENT_VER}})?
2. Looks like protocol is broken. Listener awaits 2.3 version but
{{SUPPORTED_VERS}} doesn't contain version 2.3. Are the tests OK?
was (Author: tledkov-gridgain):
[~isapego], my commets:
1. Why final field isn't used for new protocol version.
2. Looks like protocol is broken. Listener awaits 2.3 version but
{{SUPPORTED_VERS}} doesn't contain version 2.3. Are the tests OK?
> ODBC: Propagate "lazy" flag
> ---
>
> Key: IGNITE-6119
> URL: https://issues.apache.org/jira/browse/IGNITE-6119
> Project: Ignite
> Issue Type: Task
> Components: odbc
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Labels: usability
> Fix For: 2.3
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6213) Unexpected setting local deployment owner anyone node
[
https://issues.apache.org/jira/browse/IGNITE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146941#comment-16146941
]
Vladislav Pyatkov edited comment on IGNITE-6213 at 8/30/17 9:23 AM:
I have prepared a solution with will be allow to workarounded the issue.
All server nodes should add a JVM flag:
{code}
-DIGNITE_DISABLE_P2P_DEPLOYMENT_OWNERSHIP=true
{code}
by default value is _false_ (standard behavior).
It will not allow any server assign {{locDepOwner}} flag as _true_.
Look at upper PR.
was (Author: v.pyatkov):
I have prepared a solution with will be allow to workarounded the issue.
All server nodes should add a JVM flag:
{code}
-DIGNITE_DISABLE_P2P_DEPLOYMENT_OWNERSHIP=true
{code}
by default value is false (standard behavior).
It will not allow any server assign {{locDepOwner}} flag as true.
Look at upper PR.
> Unexpected setting local deployment owner anyone node
> -
>
> Key: IGNITE-6213
> URL: https://issues.apache.org/jira/browse/IGNITE-6213
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>
> In my test I have seen, when one node tune up {{locDepOwner}} flag suddenly.
> {noformat}
> 16:55:47.868
> [ DEBUG]
> [ o.a.i.i.p.c.GridCacheDeploymentManager]
> [ T:] - Prepared grid cache deployable
> [ dep=GridDeploymentInfoBean
> [ clsLdrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553, depMode=SHARED,
> userVer=0, locDepOwner=true, participants=null],
> deployable=GridNearAtomicSingleUpdateRequest
> [ key=UserKeyCacheObjectImpl
> [ part=111, val=4翿翿, hasValBytes=true],
> super=GridNearAtomicSingleUpdateRequest
> [ key=UserKeyCacheObjectImpl
> [ part=111, val=4翿翿, hasValBytes=true],
> parent=GridNearAtomicAbstractSingleUpdateRequest
> [ nodeId=45acc827-8a2d-47d3-aa04-94936ad25ac2, futId=81921,
> topVer=AffinityTopologyVersion
> [ topVer=4, minorTopVer=0], parent=GridNearAtomicAbstractUpdateRequest
> [ res=null, flags=]
> {noformat}
> By the reason global participant was been registered:
> {noformat}
> 16:55:47.871
> [ DEBUG]
> [ o.a.i.i.m.d.GridDeploymentPerVersionStore]
> [ T:] - Explicitly added participant
> [ dep=SharedDeployment
> [ rmv=false, super=GridDeployment
> [ ts=1503050146264, depMode=SHARED, clsLdr=GridDeploymentClassLoader
> [ id=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, singleNode=false,
> nodeLdrMap={12bb727e-4815-4ab2-8f8c-cc6fd52c8553=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
>
> 101abc71-83b4-4a87-bb07-14e4cbc7226e=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
>
> 9d30737f-44d2-4414-b84d-25f032484290=e70b3c4fd51-9d30737f-44d2-4414-b84d-25f032484290},
> p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
> clsLdrId=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, userVer=0,
> loc=false, sampleClsName=com.sbt.dpl.gridgain.index.InvokeIndexAdder,
> pendingUndeploy=false, undeployed=false, usage=0]],
> nodeId=12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
> ldrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553]
> {noformat}
> And after that I am geting the Exception when try to get class from node
> where the class was not located:
> {noformat}
> 16:55:50.684 [ERROR] [o.a.i.i.p.job.GridJobProcessor] [T:] - Task was not
> deployed or was redeployed since task execution
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
> codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
> seqNum=1503050088642, depMode=SHARED, dep=null]
> org.apache.ignite.IgniteDeploymentException: Task was not deployed or was
> redeployed since task execution
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
> codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
> seqNum=1503050088642, depMode=SHARED, dep=null]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1160)
> ~[ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoMan
[jira] [Comment Edited] (IGNITE-6149) Create mvcc prototype application
[ https://issues.apache.org/jira/browse/IGNITE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146943#comment-16146943 ] Semen Boikov edited comment on IGNITE-6149 at 8/30/17 9:22 AM: --- Attached prototype application simulating cache.getAll, index scan query and committed versions cleanup. was (Author: sboikov): Attached prototype application simulating cache.getAll and index scan query. > Create mvcc prototype application > - > > Key: IGNITE-6149 > URL: https://issues.apache.org/jira/browse/IGNITE-6149 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 2.3 > > Attachments: MvccTestApp.java > > > Need create simple prototype application to verify major concepts: > - which data should be stored on coordinator and on data nodes > - filtering algorithm for getAll and sql operations > - clean up of committed versions -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6213) Unexpected setting local deployment owner anyone node
[
https://issues.apache.org/jira/browse/IGNITE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146941#comment-16146941
]
Vladislav Pyatkov edited comment on IGNITE-6213 at 8/30/17 9:22 AM:
I have prepared a solution with will be allow to workarounded the issue.
All server nodes should add a JVM flag:
{code}
-DIGNITE_DISABLE_P2P_DEPLOYMENT_OWNERSHIP=true
{code}
by default value is false (standard behavior).
It will not allow any server assign {{locDepOwner}} flag as true.
Look at upper PR.
was (Author: v.pyatkov):
I have prepared a solution with will be allow to workarounded the issue.
All server nodes should add a JVM flag:
{code}
-DIGNITE_DISABLE_P2P_DEPLOYMENT_OWNERSHIP=true
{code}
It will not allow any server assign {{locDepOwner}} flag as true.
Look at upper PR.
> Unexpected setting local deployment owner anyone node
> -
>
> Key: IGNITE-6213
> URL: https://issues.apache.org/jira/browse/IGNITE-6213
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>
> In my test I have seen, when one node tune up {{locDepOwner}} flag suddenly.
> {noformat}
> 16:55:47.868
> [ DEBUG]
> [ o.a.i.i.p.c.GridCacheDeploymentManager]
> [ T:] - Prepared grid cache deployable
> [ dep=GridDeploymentInfoBean
> [ clsLdrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553, depMode=SHARED,
> userVer=0, locDepOwner=true, participants=null],
> deployable=GridNearAtomicSingleUpdateRequest
> [ key=UserKeyCacheObjectImpl
> [ part=111, val=4翿翿, hasValBytes=true],
> super=GridNearAtomicSingleUpdateRequest
> [ key=UserKeyCacheObjectImpl
> [ part=111, val=4翿翿, hasValBytes=true],
> parent=GridNearAtomicAbstractSingleUpdateRequest
> [ nodeId=45acc827-8a2d-47d3-aa04-94936ad25ac2, futId=81921,
> topVer=AffinityTopologyVersion
> [ topVer=4, minorTopVer=0], parent=GridNearAtomicAbstractUpdateRequest
> [ res=null, flags=]
> {noformat}
> By the reason global participant was been registered:
> {noformat}
> 16:55:47.871
> [ DEBUG]
> [ o.a.i.i.m.d.GridDeploymentPerVersionStore]
> [ T:] - Explicitly added participant
> [ dep=SharedDeployment
> [ rmv=false, super=GridDeployment
> [ ts=1503050146264, depMode=SHARED, clsLdr=GridDeploymentClassLoader
> [ id=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, singleNode=false,
> nodeLdrMap={12bb727e-4815-4ab2-8f8c-cc6fd52c8553=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
>
> 101abc71-83b4-4a87-bb07-14e4cbc7226e=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
>
> 9d30737f-44d2-4414-b84d-25f032484290=e70b3c4fd51-9d30737f-44d2-4414-b84d-25f032484290},
> p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
> clsLdrId=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, userVer=0,
> loc=false, sampleClsName=com.sbt.dpl.gridgain.index.InvokeIndexAdder,
> pendingUndeploy=false, undeployed=false, usage=0]],
> nodeId=12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
> ldrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553]
> {noformat}
> And after that I am geting the Exception when try to get class from node
> where the class was not located:
> {noformat}
> 16:55:50.684 [ERROR] [o.a.i.i.p.job.GridJobProcessor] [T:] - Task was not
> deployed or was redeployed since task execution
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
> codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
> seqNum=1503050088642, depMode=SHARED, dep=null]
> org.apache.ignite.IgniteDeploymentException: Task was not deployed or was
> redeployed since task execution
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
> codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
> seqNum=1503050088642, depMode=SHARED, dep=null]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1160)
> ~[ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [ignite
[jira] [Updated] (IGNITE-6149) Create mvcc prototype application
[ https://issues.apache.org/jira/browse/IGNITE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-6149: - Attachment: MvccTestApp.java Attached prototype application simulating cache.getAll and index scan query. > Create mvcc prototype application > - > > Key: IGNITE-6149 > URL: https://issues.apache.org/jira/browse/IGNITE-6149 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov > Fix For: 2.3 > > Attachments: MvccTestApp.java > > > Need create simple prototype application to verify major concepts: > - which data should be stored on coordinator and on data nodes > - filtering algorithm for getAll and sql operations > - clean up of committed versions -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6213) Unexpected setting local deployment owner anyone node
[
https://issues.apache.org/jira/browse/IGNITE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146941#comment-16146941
]
Vladislav Pyatkov commented on IGNITE-6213:
---
I have prepared a solution with will be allow to workarounded the issue.
All server nodes should add a JVM flag:
{code}
-DIGNITE_DISABLE_P2P_DEPLOYMENT_OWNERSHIP=true
{code}
It will not allow any server assign {{locDepOwner}} flag as true.
Look at upper PR.
> Unexpected setting local deployment owner anyone node
> -
>
> Key: IGNITE-6213
> URL: https://issues.apache.org/jira/browse/IGNITE-6213
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>
> In my test I have seen, when one node tune up {{locDepOwner}} flag suddenly.
> {noformat}
> 16:55:47.868
> [ DEBUG]
> [ o.a.i.i.p.c.GridCacheDeploymentManager]
> [ T:] - Prepared grid cache deployable
> [ dep=GridDeploymentInfoBean
> [ clsLdrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553, depMode=SHARED,
> userVer=0, locDepOwner=true, participants=null],
> deployable=GridNearAtomicSingleUpdateRequest
> [ key=UserKeyCacheObjectImpl
> [ part=111, val=4翿翿, hasValBytes=true],
> super=GridNearAtomicSingleUpdateRequest
> [ key=UserKeyCacheObjectImpl
> [ part=111, val=4翿翿, hasValBytes=true],
> parent=GridNearAtomicAbstractSingleUpdateRequest
> [ nodeId=45acc827-8a2d-47d3-aa04-94936ad25ac2, futId=81921,
> topVer=AffinityTopologyVersion
> [ topVer=4, minorTopVer=0], parent=GridNearAtomicAbstractUpdateRequest
> [ res=null, flags=]
> {noformat}
> By the reason global participant was been registered:
> {noformat}
> 16:55:47.871
> [ DEBUG]
> [ o.a.i.i.m.d.GridDeploymentPerVersionStore]
> [ T:] - Explicitly added participant
> [ dep=SharedDeployment
> [ rmv=false, super=GridDeployment
> [ ts=1503050146264, depMode=SHARED, clsLdr=GridDeploymentClassLoader
> [ id=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, singleNode=false,
> nodeLdrMap={12bb727e-4815-4ab2-8f8c-cc6fd52c8553=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
>
> 101abc71-83b4-4a87-bb07-14e4cbc7226e=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
>
> 9d30737f-44d2-4414-b84d-25f032484290=e70b3c4fd51-9d30737f-44d2-4414-b84d-25f032484290},
> p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
> clsLdrId=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, userVer=0,
> loc=false, sampleClsName=com.sbt.dpl.gridgain.index.InvokeIndexAdder,
> pendingUndeploy=false, undeployed=false, usage=0]],
> nodeId=12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
> ldrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553]
> {noformat}
> And after that I am geting the Exception when try to get class from node
> where the class was not located:
> {noformat}
> 16:55:50.684 [ERROR] [o.a.i.i.p.job.GridJobProcessor] [T:] - Task was not
> deployed or was redeployed since task execution
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
> codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
> seqNum=1503050088642, depMode=SHARED, dep=null]
> org.apache.ignite.IgniteDeploymentException: Task was not deployed or was
> redeployed since task execution
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
> codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
> seqNum=1503050088642, depMode=SHARED, dep=null]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1160)
> ~[ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.
[jira] [Commented] (IGNITE-5385) Get rid of discovery custom message on exchange completion
[ https://issues.apache.org/jira/browse/IGNITE-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146939#comment-16146939 ] Semen Boikov commented on IGNITE-5385: -- Implemented as part of changes related to IGNITE-6124. > Get rid of discovery custom message on exchange completion > -- > > Key: IGNITE-5385 > URL: https://issues.apache.org/jira/browse/IGNITE-5385 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.0 >Reporter: Yakov Zhdanov >Assignee: Alexei Scherbakov >Priority: Blocker > Labels: performance > Fix For: 2.3 > > > Currently if late affinity assignment is on we send full partition map as a > custom message to make sure all nodes get it. With greater number of nodes > and caches this can cause significant slowdowns. > We suggest to move sending to communication. In this case scenario with > coordinator failure requires special handling, since in this case some nodes > may receive full map, complete exchange and proceed with cache operations, > while others may not received full map yet. In this case full map should be > resend from new coordinator - it should be recalculated if none has received > one from former coordinator or should be requested from one of the lucky > receivers to get forwarded to other nodes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5578) Discovery events coalescing
[ https://issues.apache.org/jira/browse/IGNITE-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov reassigned IGNITE-5578: Assignee: (was: Semen Boikov) > Discovery events coalescing > --- > > Key: IGNITE-5578 > URL: https://issues.apache.org/jira/browse/IGNITE-5578 > Project: Ignite > Issue Type: Improvement > Components: cache, general >Affects Versions: 1.0 >Reporter: Alexey Goncharuk > Fix For: 2.3 > > > There is an issue that has been in Ignite long ago and with the growing > community and growing cluster sizes, it becomes more tangible. > When a bunch of nodes leave or join cluster, we generate a separate discovery > event for each node, and each discovery event generates a partition map > exchange. > The first idea that came to my mind was to coalesce the partition map > exchanges, but this is extremely difficult to implement on unstable topology. > Instead, we can introduce NODES_JOINED / NODES_FAILED events and batch > multiple events on discovery level when possible. In this case, very few > extra partition map exchanges are possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6213) Unexpected setting local deployment owner anyone node
[
https://issues.apache.org/jira/browse/IGNITE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146929#comment-16146929
]
ASF GitHub Bot commented on IGNITE-6213:
GitHub user vldpyatkov opened a pull request:
https://github.com/apache/ignite/pull/2546
IGNITE-6213
Unexpected setting local deployment owner anyone node
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6213
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2546.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 #2546
commit 9c4754ad7935e4696df841629c728b993f59c95d
Author: vd-pyatkov
Date: 2017-08-30T09:04:55Z
IGNITE-6213
Unexpected setting local deployment owner anyone node
> Unexpected setting local deployment owner anyone node
> -
>
> Key: IGNITE-6213
> URL: https://issues.apache.org/jira/browse/IGNITE-6213
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>
> In my test I have seen, when one node tune up {{locDepOwner}} flag suddenly.
> {noformat}
> 16:55:47.868
> [ DEBUG]
> [ o.a.i.i.p.c.GridCacheDeploymentManager]
> [ T:] - Prepared grid cache deployable
> [ dep=GridDeploymentInfoBean
> [ clsLdrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553, depMode=SHARED,
> userVer=0, locDepOwner=true, participants=null],
> deployable=GridNearAtomicSingleUpdateRequest
> [ key=UserKeyCacheObjectImpl
> [ part=111, val=4翿翿, hasValBytes=true],
> super=GridNearAtomicSingleUpdateRequest
> [ key=UserKeyCacheObjectImpl
> [ part=111, val=4翿翿, hasValBytes=true],
> parent=GridNearAtomicAbstractSingleUpdateRequest
> [ nodeId=45acc827-8a2d-47d3-aa04-94936ad25ac2, futId=81921,
> topVer=AffinityTopologyVersion
> [ topVer=4, minorTopVer=0], parent=GridNearAtomicAbstractUpdateRequest
> [ res=null, flags=]
> {noformat}
> By the reason global participant was been registered:
> {noformat}
> 16:55:47.871
> [ DEBUG]
> [ o.a.i.i.m.d.GridDeploymentPerVersionStore]
> [ T:] - Explicitly added participant
> [ dep=SharedDeployment
> [ rmv=false, super=GridDeployment
> [ ts=1503050146264, depMode=SHARED, clsLdr=GridDeploymentClassLoader
> [ id=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, singleNode=false,
> nodeLdrMap={12bb727e-4815-4ab2-8f8c-cc6fd52c8553=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
>
> 101abc71-83b4-4a87-bb07-14e4cbc7226e=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
>
> 9d30737f-44d2-4414-b84d-25f032484290=e70b3c4fd51-9d30737f-44d2-4414-b84d-25f032484290},
> p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
> clsLdrId=acaa3c4fd51-45acc827-8a2d-47d3-aa04-94936ad25ac2, userVer=0,
> loc=false, sampleClsName=com.sbt.dpl.gridgain.index.InvokeIndexAdder,
> pendingUndeploy=false, undeployed=false, usage=0]],
> nodeId=12bb727e-4815-4ab2-8f8c-cc6fd52c8553,
> ldrId=aefa3c4fd51-12bb727e-4815-4ab2-8f8c-cc6fd52c8553]
> {noformat}
> And after that I am geting the Exception when try to get class from node
> where the class was not located:
> {noformat}
> 16:55:50.684 [ERROR] [o.a.i.i.p.job.GridJobProcessor] [T:] - Task was not
> deployed or was redeployed since task execution
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
> codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
> seqNum=1503050088642, depMode=SHARED, dep=null]
> org.apache.ignite.IgniteDeploymentException: Task was not deployed or was
> redeployed since task execution
> [taskName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
>
> taskClsName=com.sbt.azimuth_psi.publisher.forms.computing.parallelBatchCollectForm$TestMapFunction,
> codeVer=0, clsLdrId=2c044c4fd51-101abc71-83b4-4a87-bb07-14e4cbc7226e,
> seqNum=1503050088642, depMode=SHARED, dep=null]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1160)
> ~[ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> [ignite-core-2.1.3.jar:2.1.3]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> [ignite-core-2.1.3.jar:2.1.3]
>
