[jira] [Resolved] (IGNITE-5009) Backport IGNITE-4932 optimization in 2.x release
[ https://issues.apache.org/jira/browse/IGNITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov resolved IGNITE-5009. -- Resolution: Fixed Assignee: (was: Semen Boikov) Merged into master (01671827411ed6043e6bfb80514e3ff57fb40b18). > Backport IGNITE-4932 optimization in 2.x release > > > Key: IGNITE-5009 > URL: https://issues.apache.org/jira/browse/IGNITE-5009 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Semen Boikov >Priority: Critical > Fix For: 2.1 > > > In IGNITE-4932 we implemented for 1.9 codebase optimization to avoid cache > entry creation for cache.get operation, need backport this optimization in > 2.x release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007273#comment-16007273 ] Denis Magda commented on IGNITE-1094: - [~Alexey Kuznetsov], here is a link that explains how to use Upsource for review: https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewWithUpsource > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Alexey Kuznetsov > Labels: Muted_test > Fix For: 2.1 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS
[ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007265#comment-16007265 ] Denis Magda commented on IGNITE-4052: - I'm trying to figure out what happened. > Add ability to set up users for MESOS > - > > Key: IGNITE-4052 > URL: https://issues.apache.org/jira/browse/IGNITE-4052 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.7 >Reporter: Nikolay Tikhonov >Assignee: Vadim Opolski >Priority: Trivial > > In current implementation Ignite Mesos Framework connects to MESOS cluster > via current user. Need to add ability to configure this parameters via system > env properties. Also need to add properties for mesos role. > See org/apache/ignite/mesos/IgniteFramework.java:537 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5204) The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception
[ https://issues.apache.org/jira/browse/IGNITE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007260#comment-16007260 ] Denis Magda commented on IGNITE-5204: - [~vozerov], [~sergi.vladykin], please look in here. > The Unicode character in the value of a field which are included in an > un-unique index will cause "stack overhead" exception > > > Key: IGNITE-5204 > URL: https://issues.apache.org/jira/browse/IGNITE-5204 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.0 > Environment: windows server 2012, JDK 1.8, X64 >Reporter: Chris Wang >Assignee: Vladimir Ozerov >Priority: Critical > > When put "草DX009090" as the value of BillId, which is a field of entity > Bill. If I define a index includes the BillId, and execute the query like > "select * from Bill where BillId=’草DX009090‘ in the H2 debug console, there > throws an exception by the H2 with a code 5000. > another scenario is, I have two entities, "Bill" and "Detail", both have > field "BillId". If either of them have value like "草DX009090" and execute the > query like "select bill.* from bill left join detail on > bill.billid=detail.billid", the whole ignite cache node will halt ( suppose > there should be an stack overhead exception, dead loop). > == > I think the issue should relate to hash computing on the unicode character. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-5204) The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception
[ https://issues.apache.org/jira/browse/IGNITE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-5204: --- Assignee: Vladimir Ozerov > The Unicode character in the value of a field which are included in an > un-unique index will cause "stack overhead" exception > > > Key: IGNITE-5204 > URL: https://issues.apache.org/jira/browse/IGNITE-5204 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.0 > Environment: windows server 2012, JDK 1.8, X64 >Reporter: Chris Wang >Assignee: Vladimir Ozerov >Priority: Critical > > When put "草DX009090" as the value of BillId, which is a field of entity > Bill. If I define a index includes the BillId, and execute the query like > "select * from Bill where BillId=’草DX009090‘ in the H2 debug console, there > throws an exception by the H2 with a code 5000. > another scenario is, I have two entities, "Bill" and "Detail", both have > field "BillId". If either of them have value like "草DX009090" and execute the > query like "select bill.* from bill left join detail on > bill.billid=detail.billid", the whole ignite cache node will halt ( suppose > there should be an stack overhead exception, dead loop). > == > I think the issue should relate to hash computing on the unicode character. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS
[ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006872#comment-16006872 ] Nikolay Tikhonov commented on IGNITE-4052: -- I've logout from there and have the same problem too. I'll to ask from theirs support. > Add ability to set up users for MESOS > - > > Key: IGNITE-4052 > URL: https://issues.apache.org/jira/browse/IGNITE-4052 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.7 >Reporter: Nikolay Tikhonov >Assignee: Vadim Opolski >Priority: Trivial > > In current implementation Ignite Mesos Framework connects to MESOS cluster > via current user. Need to add ability to configure this parameters via system > env properties. Also need to add properties for mesos role. > See org/apache/ignite/mesos/IgniteFramework.java:537 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5052) Implement CREATE/DROP TABLE parsing and execution
[
https://issues.apache.org/jira/browse/IGNITE-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006786#comment-16006786
]
Alexander Paschenko commented on IGNITE-5052:
-
Fixed pts. 4, 5
> Implement CREATE/DROP TABLE parsing and execution
> -
>
> Key: IGNITE-5052
> URL: https://issues.apache.org/jira/browse/IGNITE-5052
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Labels: important
> Fix For: 2.1
>
>
> Convert SQL string to relevant Igntie command. This could be:
> - {{createCache}}
> - {{getOrCreateCache}} (for {{IF NOT EXISTS}} case)
> - {{destroyCache}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-5193) Hadoop: Ignite node fails to start if some , but not all HADOOP_XXX_HOME variables are set.
[
https://issues.apache.org/jira/browse/IGNITE-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006452#comment-16006452
]
Ivan Veselovsky edited comment on IGNITE-5193 at 5/11/17 4:39 PM:
--
Pull Request https://github.com/apache/ignite/pull/1928 ,
Tests
http://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests_IgniteHadoop&branch_IgniteTests=pull%2F1928%2Fhead&tab=buildTypeStatusDiv
.
was (Author: iveselovskiy):
https://github.com/apache/ignite/pull/1928
> Hadoop: Ignite node fails to start if some , but not all HADOOP_XXX_HOME
> variables are set.
> ---
>
> Key: IGNITE-5193
> URL: https://issues.apache.org/jira/browse/IGNITE-5193
> Project: Ignite
> Issue Type: Bug
> Components: hadoop
>Affects Versions: 1.8
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Labels: easyfix
> Fix For: 2.1
>
>
> Ignite node fails to start if some , but not all 3 HADOOP_XXX_HOME variables
> are set (see trace below). This is caused by the following gap in Ignite
> logic:
> {{org.apache.ignite.internal.processors.hadoop.HadoopClasspathUtils#exists ,
> #isDirectory , #isReadable}} return {{true}} for empty String argument. For
> the unset location variables the value is empty String, but
> {{org.apache.ignite.internal.processors.hadoop.HadoopLocations#xExists}}
> gets {{true}}, so the location considered to be valid. This is the cause of
> the problem.
> {code}
> [06:09:42] Security status [authentication=off, tls/ssl=off]
> [06:17:23,822][ERROR][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> java.lang.RuntimeException: class org.apache.ignite.IgniteCheckedException:
> Failed to resolve Hadoop JAR locations: Failed to get directory files [dir=]
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.addHadoopUrls(HadoopClassLoader.java:422)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.(HadoopClassLoader.java:134)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopHelperImpl.commonClassLoader(HadoopHelperImpl.java:78)
> at
> org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem.start(IgniteHadoopIgfsSecondaryFileSystem.java:254)
> at
> org.apache.ignite.internal.processors.igfs.IgfsImpl.(IgfsImpl.java:186)
> at
> org.apache.ignite.internal.processors.igfs.IgfsContext.(IgfsContext.java:101)
> at
> org.apache.ignite.internal.processors.igfs.IgfsProcessor.start(IgfsProcessor.java:128)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1638)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:900)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1602)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:964)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:850)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:749)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:619)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> 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: Failed to resolve
> Hadoop JAR locations: Failed to get directory files [dir=]
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.hadoopUrls(HadoopClassLoader.java:456)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.addHadoopUrls(HadoopClassLoader.java:419)
> ... 18 more
> Caused by: java.io.IOException: Failed to get directory files [dir=]
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClasspathUtils$SearchDirectory.files(HadoopClasspathUtils.java:344)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClasspathUtils.classpathForClassLoader(HadoopClasspathUtils.java:68)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.hadoopUrls(HadoopClassLoader.java:453)
> ... 19 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4052) Add ability to set up users for MESOS
[ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Opolski updated IGNITE-4052: -- Added screen: https://www.dropbox.com/s/12wywposbhy6p4l/Documentation.docx?dl=0 Vadim > Add ability to set up users for MESOS > - > > Key: IGNITE-4052 > URL: https://issues.apache.org/jira/browse/IGNITE-4052 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.7 >Reporter: Nikolay Tikhonov >Assignee: Vadim Opolski >Priority: Trivial > > In current implementation Ignite Mesos Framework connects to MESOS cluster > via current user. Need to add ability to configure this parameters via system > env properties. Also need to add properties for mesos role. > See org/apache/ignite/mesos/IgniteFramework.java:537 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5175) Performance degradation using evictions in near-enabled caches
[ https://issues.apache.org/jira/browse/IGNITE-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006647#comment-16006647 ] ASF GitHub Bot commented on IGNITE-5175: GitHub user glukos opened a pull request: https://github.com/apache/ignite/pull/1931 IGNITE-5175: Performance degradation using evictions in near-enabled … You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5175 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1931.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 #1931 commit 9f2f30c4a5de21fb8108b97bcb03dbf91d6b3fdf Author: Ivan Rakov Date: 2017-05-11T15:37:45Z IGNITE-5175: Performance degradation using evictions in near-enabled caches > Performance degradation using evictions in near-enabled caches > -- > > Key: IGNITE-5175 > URL: https://issues.apache.org/jira/browse/IGNITE-5175 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.0 >Reporter: Igor Seliverstov >Assignee: Ivan Rakov > > Both RandomLruNearEnabledPageEvictionMultinodeTest.testPageEviction and > Random2LruNearEnabledPageEvictionMultinodeTest.testPageEviction fail with > timeout exceptions. > Seems that the execution time (eviction operation) is non-linearly dependent > on a count of elements in the cache (the more elements the longer the > operation). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-5175) Performance degradation using evictions in near-enabled caches
[ https://issues.apache.org/jira/browse/IGNITE-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov reassigned IGNITE-5175: -- Assignee: Alexey Goncharuk (was: Ivan Rakov) > Performance degradation using evictions in near-enabled caches > -- > > Key: IGNITE-5175 > URL: https://issues.apache.org/jira/browse/IGNITE-5175 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.0 >Reporter: Igor Seliverstov >Assignee: Alexey Goncharuk > > Both RandomLruNearEnabledPageEvictionMultinodeTest.testPageEviction and > Random2LruNearEnabledPageEvictionMultinodeTest.testPageEviction fail with > timeout exceptions. > Seems that the execution time (eviction operation) is non-linearly dependent > on a count of elements in the cache (the more elements the longer the > operation). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5175) Performance degradation using evictions in near-enabled caches
[ https://issues.apache.org/jira/browse/IGNITE-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006644#comment-16006644 ] Ivan Rakov commented on IGNITE-5175: Current test hang is expected. Entry can't be evicted on local node if it's present in near cache on another node (after some iterations, almost all entries have copies in near cache). Test is changed. > Performance degradation using evictions in near-enabled caches > -- > > Key: IGNITE-5175 > URL: https://issues.apache.org/jira/browse/IGNITE-5175 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.0 >Reporter: Igor Seliverstov >Assignee: Ivan Rakov > > Both RandomLruNearEnabledPageEvictionMultinodeTest.testPageEviction and > Random2LruNearEnabledPageEvictionMultinodeTest.testPageEviction fail with > timeout exceptions. > Seems that the execution time (eviction operation) is non-linearly dependent > on a count of elements in the cache (the more elements the longer the > operation). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS
[ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006629#comment-16006629 ] Nikolay Tikhonov commented on IGNITE-4052: -- [~javaller] Which kind of issue do you have? Could you share some screenshot? > Add ability to set up users for MESOS > - > > Key: IGNITE-4052 > URL: https://issues.apache.org/jira/browse/IGNITE-4052 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.7 >Reporter: Nikolay Tikhonov >Assignee: Vadim Opolski >Priority: Trivial > > In current implementation Ignite Mesos Framework connects to MESOS cluster > via current user. Need to add ability to configure this parameters via system > env properties. Also need to add properties for mesos role. > See org/apache/ignite/mesos/IgniteFramework.java:537 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5202) Default mem policy name is not changed after setting defaultMemoryPolicyName property
[
https://issues.apache.org/jira/browse/IGNITE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006521#comment-16006521
]
Sergey Chugunov commented on IGNITE-5202:
-
pull request is open: https://github.com/apache/ignite/pull/1930
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property
> -
>
> Key: IGNITE-5202
> URL: https://issues.apache.org/jira/browse/IGNITE-5202
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Ksenia Rybakova
>Assignee: Sergey Chugunov
>Priority: Minor
> Fix For: 2.1
>
>
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property.
> Config:
> {noformat}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
>
> class="org.apache.ignite.configuration.IgniteConfiguration"
> parent="base-ignite.cfg">
>
>
>
> ...
>
>
>
>parent="base-mem.cfg">
>
>
>
>
>
>
> {noformat}
> {noformat}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration" abstract="true">
> ...
>
> class="org.apache.ignite.configuration.MemoryConfiguration" abstract="true">
>...
>
>
>...
> class="org.apache.ignite.configuration.MemoryPolicyConfiguration">
>
>
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
>...
>
> {noformat}
> According to this config default memory policy should be "default2", but it
> remains "default" (while SystemCacheInitialSize was changed successfully to
> 50Mb as it's set in config).
> {noformat}
> [12:48:12,226][INFO ][main][IgniteKernal] System cache's MemoryPolicy size is
> configured to 50 MB. Use MemoryConfiguration.systemCacheMemorySize property
> to change the setting.
> [12:48:12,226][INFO ][main][IgniteKernal] Configured caches [in 'default'
> memoryPolicy: ['ignite-sys-cache', 'ignite-atomics-sys-cache', 'atomic-part',
> 'atomic-rplc', 'atomic-part-fat-values', 'atomic-part-onheap-evict-fifo',
> 'atomic-rplc-onheap-evict-lru', 'tx-part', 'tx-rplc', 'tx-part-fat-values',
> 'compute', 'tx-part-onheap-evict-lru', 'tx-rplc-onheap-evict-fifo',
> 'atomic-index', 'query', 'orgCache']]
> {noformat}
> Also it would be nice to have default policy name instead of "null" in logs
> when printing caches info:
> {noformat}
> <12:48:12> Cache configured with the following parameters:
> CacheConfiguration [name=atomic-part, memPlcName=null,
> storeConcurrentLoadAllThreshold=5, ...
> {noformat}
> {noformat}
> [12:48:13,239][INFO ][main][GridCacheProcessor] Started cache
> [name=atomic-part, memoryPolicyName=null, mode=PARTITIONED]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5206) Test mesos user and mesos role parameters on real mesos cluster.
Vadim Opolski created IGNITE-5206: - Summary: Test mesos user and mesos role parameters on real mesos cluster. Key: IGNITE-5206 URL: https://issues.apache.org/jira/browse/IGNITE-5206 Project: Ignite Issue Type: Task Reporter: Vadim Opolski In current implementation Ignite Mesos Framework connects to MESOS cluster via system env properties (user and role). Need to test this locally, on real mesos cluster. We need to understand which exception user will get if user name and/or role incorrect. Documentation: https://apacheignite.readme.io/docs/mesos-deployment http://mesos.apache.org/gettingstarted/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5163) JDBC Driver: implement handshake for thin jdbc driver based on common odbc/jdbc protocol
[ https://issues.apache.org/jira/browse/IGNITE-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006504#comment-16006504 ] Igor Sapego commented on IGNITE-5163: - It is not obvious to me as well, it was just a concern. Well, I guess, if JIT will compile code to always choose "else" branch there's going to be only one prediction fail which should be OK. > JDBC Driver: implement handshake for thin jdbc driver based on common > odbc/jdbc protocol > > > Key: IGNITE-5163 > URL: https://issues.apache.org/jira/browse/IGNITE-5163 > Project: Ignite > Issue Type: Task > Components: odbc, sql >Affects Versions: 1.9 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.1 > > > The GridClient must be removed from thin jdbc driver. > It is the first step to unify JDBC & ODBC protocols. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5193) Hadoop: Ignite node fails to start if some , but not all HADOOP_XXX_HOME variables are set.
[
https://issues.apache.org/jira/browse/IGNITE-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Veselovsky updated IGNITE-5193:
Labels: easyfix (was: )
> Hadoop: Ignite node fails to start if some , but not all HADOOP_XXX_HOME
> variables are set.
> ---
>
> Key: IGNITE-5193
> URL: https://issues.apache.org/jira/browse/IGNITE-5193
> Project: Ignite
> Issue Type: Bug
> Components: hadoop
>Affects Versions: 1.8
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Labels: easyfix
> Fix For: 2.1
>
>
> Ignite node fails to start if some , but not all 3 HADOOP_XXX_HOME variables
> are set (see trace below). This is caused by the following gap in Ignite
> logic:
> {{org.apache.ignite.internal.processors.hadoop.HadoopClasspathUtils#exists ,
> #isDirectory , #isReadable}} return {{true}} for empty String argument. For
> the unset location variables the value is empty String, but
> {{org.apache.ignite.internal.processors.hadoop.HadoopLocations#xExists}}
> gets {{true}}, so the location considered to be valid. This is the cause of
> the problem.
> {code}
> [06:09:42] Security status [authentication=off, tls/ssl=off]
> [06:17:23,822][ERROR][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> java.lang.RuntimeException: class org.apache.ignite.IgniteCheckedException:
> Failed to resolve Hadoop JAR locations: Failed to get directory files [dir=]
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.addHadoopUrls(HadoopClassLoader.java:422)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.(HadoopClassLoader.java:134)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopHelperImpl.commonClassLoader(HadoopHelperImpl.java:78)
> at
> org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem.start(IgniteHadoopIgfsSecondaryFileSystem.java:254)
> at
> org.apache.ignite.internal.processors.igfs.IgfsImpl.(IgfsImpl.java:186)
> at
> org.apache.ignite.internal.processors.igfs.IgfsContext.(IgfsContext.java:101)
> at
> org.apache.ignite.internal.processors.igfs.IgfsProcessor.start(IgfsProcessor.java:128)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1638)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:900)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1602)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:964)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:850)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:749)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:619)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> 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: Failed to resolve
> Hadoop JAR locations: Failed to get directory files [dir=]
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.hadoopUrls(HadoopClassLoader.java:456)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.addHadoopUrls(HadoopClassLoader.java:419)
> ... 18 more
> Caused by: java.io.IOException: Failed to get directory files [dir=]
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClasspathUtils$SearchDirectory.files(HadoopClasspathUtils.java:344)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClasspathUtils.classpathForClassLoader(HadoopClasspathUtils.java:68)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.hadoopUrls(HadoopClassLoader.java:453)
> ... 19 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5163) JDBC Driver: implement handshake for thin jdbc driver based on common odbc/jdbc protocol
[
https://issues.apache.org/jira/browse/IGNITE-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006450#comment-16006450
]
Taras Ledkov commented on IGNITE-5163:
--
[~isapego],
A HashMap is O(1) look up performance, but that doesn't mean it's
"instantaneous". Internally there are lots of if tests and hashcode
calculations etc.
I've not seen any benchmark {{HashMap}} vs {{if-else}}.
Now we have only ~30 comparisons of references. The fact that performance will
be with {{HashMap}} usage with the {{Class}} as a key is not obvious to me.
> JDBC Driver: implement handshake for thin jdbc driver based on common
> odbc/jdbc protocol
>
>
> Key: IGNITE-5163
> URL: https://issues.apache.org/jira/browse/IGNITE-5163
> Project: Ignite
> Issue Type: Task
> Components: odbc, sql
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>
> The GridClient must be removed from thin jdbc driver.
> It is the first step to unify JDBC & ODBC protocols.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5202) Default mem policy name is not changed after setting defaultMemoryPolicyName property
[
https://issues.apache.org/jira/browse/IGNITE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006438#comment-16006438
]
Sergey Chugunov commented on IGNITE-5202:
-
I lowered priority of the bug to Minor because it turned out that there were
some flaws in cache configuration logging caused incorrect messages to appear
in logs.
MemoryPolicy functionality is fine and works as expected.
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property
> -
>
> Key: IGNITE-5202
> URL: https://issues.apache.org/jira/browse/IGNITE-5202
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Ksenia Rybakova
>Assignee: Sergey Chugunov
>Priority: Minor
> Fix For: 2.1
>
>
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property.
> Config:
> {noformat}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
>
> class="org.apache.ignite.configuration.IgniteConfiguration"
> parent="base-ignite.cfg">
>
>
>
> ...
>
>
>
>parent="base-mem.cfg">
>
>
>
>
>
>
> {noformat}
> {noformat}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration" abstract="true">
> ...
>
> class="org.apache.ignite.configuration.MemoryConfiguration" abstract="true">
>...
>
>
>...
> class="org.apache.ignite.configuration.MemoryPolicyConfiguration">
>
>
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
>...
>
> {noformat}
> According to this config default memory policy should be "default2", but it
> remains "default" (while SystemCacheInitialSize was changed successfully to
> 50Mb as it's set in config).
> {noformat}
> [12:48:12,226][INFO ][main][IgniteKernal] System cache's MemoryPolicy size is
> configured to 50 MB. Use MemoryConfiguration.systemCacheMemorySize property
> to change the setting.
> [12:48:12,226][INFO ][main][IgniteKernal] Configured caches [in 'default'
> memoryPolicy: ['ignite-sys-cache', 'ignite-atomics-sys-cache', 'atomic-part',
> 'atomic-rplc', 'atomic-part-fat-values', 'atomic-part-onheap-evict-fifo',
> 'atomic-rplc-onheap-evict-lru', 'tx-part', 'tx-rplc', 'tx-part-fat-values',
> 'compute', 'tx-part-onheap-evict-lru', 'tx-rplc-onheap-evict-fifo',
> 'atomic-index', 'query', 'orgCache']]
> {noformat}
> Also it would be nice to have default policy name instead of "null" in logs
> when printing caches info:
> {noformat}
> <12:48:12> Cache configured with the following parameters:
> CacheConfiguration [name=atomic-part, memPlcName=null,
> storeConcurrentLoadAllThreshold=5, ...
> {noformat}
> {noformat}
> [12:48:13,239][INFO ][main][GridCacheProcessor] Started cache
> [name=atomic-part, memoryPolicyName=null, mode=PARTITIONED]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5202) Default mem policy name is not changed after setting defaultMemoryPolicyName property
[
https://issues.apache.org/jira/browse/IGNITE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-5202:
Priority: Minor (was: Major)
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property
> -
>
> Key: IGNITE-5202
> URL: https://issues.apache.org/jira/browse/IGNITE-5202
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Ksenia Rybakova
>Assignee: Sergey Chugunov
>Priority: Minor
> Fix For: 2.1
>
>
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property.
> Config:
> {noformat}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
>
> class="org.apache.ignite.configuration.IgniteConfiguration"
> parent="base-ignite.cfg">
>
>
>
> ...
>
>
>
>parent="base-mem.cfg">
>
>
>
>
>
>
> {noformat}
> {noformat}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration" abstract="true">
> ...
>
> class="org.apache.ignite.configuration.MemoryConfiguration" abstract="true">
>...
>
>
>...
> class="org.apache.ignite.configuration.MemoryPolicyConfiguration">
>
>
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
>...
>
> {noformat}
> According to this config default memory policy should be "default2", but it
> remains "default" (while SystemCacheInitialSize was changed successfully to
> 50Mb as it's set in config).
> {noformat}
> [12:48:12,226][INFO ][main][IgniteKernal] System cache's MemoryPolicy size is
> configured to 50 MB. Use MemoryConfiguration.systemCacheMemorySize property
> to change the setting.
> [12:48:12,226][INFO ][main][IgniteKernal] Configured caches [in 'default'
> memoryPolicy: ['ignite-sys-cache', 'ignite-atomics-sys-cache', 'atomic-part',
> 'atomic-rplc', 'atomic-part-fat-values', 'atomic-part-onheap-evict-fifo',
> 'atomic-rplc-onheap-evict-lru', 'tx-part', 'tx-rplc', 'tx-part-fat-values',
> 'compute', 'tx-part-onheap-evict-lru', 'tx-rplc-onheap-evict-fifo',
> 'atomic-index', 'query', 'orgCache']]
> {noformat}
> Also it would be nice to have default policy name instead of "null" in logs
> when printing caches info:
> {noformat}
> <12:48:12> Cache configured with the following parameters:
> CacheConfiguration [name=atomic-part, memPlcName=null,
> storeConcurrentLoadAllThreshold=5, ...
> {noformat}
> {noformat}
> [12:48:13,239][INFO ][main][GridCacheProcessor] Started cache
> [name=atomic-part, memoryPolicyName=null, mode=PARTITIONED]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5163) JDBC Driver: implement handshake for thin jdbc driver based on common odbc/jdbc protocol
[
https://issues.apache.org/jira/browse/IGNITE-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006393#comment-16006393
]
Igor Sapego commented on IGNITE-5163:
-
[~tledkov-gridgain],
I have concerns about
{{org.apache.ignite.internal.processors.odbc.SqlListenerMessageParserImpl#encode()}}
method. To be more clear, the lines from 200 to 255. There is huge number of
{{if-else}} pairs and I doubt branch prediction is going to work well on such
code. Can't we use something less "branchy" here? Something like hash-map or
switch?
> JDBC Driver: implement handshake for thin jdbc driver based on common
> odbc/jdbc protocol
>
>
> Key: IGNITE-5163
> URL: https://issues.apache.org/jira/browse/IGNITE-5163
> Project: Ignite
> Issue Type: Task
> Components: odbc, sql
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>
> The GridClient must be removed from thin jdbc driver.
> It is the first step to unify JDBC & ODBC protocols.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5205) Optimize SQL messaging
Sergi Vladykin created IGNITE-5205: -- Summary: Optimize SQL messaging Key: IGNITE-5205 URL: https://issues.apache.org/jira/browse/IGNITE-5205 Project: Ignite Issue Type: Bug Affects Versions: 2.0 Reporter: Sergi Vladykin Fix For: 2.1 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.3.15#6346)
[jira] [Closed] (IGNITE-5190) ArrayIndexOutOfBoundsException in GridMergeIndexSorted
[ https://issues.apache.org/jira/browse/IGNITE-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergi Vladykin closed IGNITE-5190. -- > ArrayIndexOutOfBoundsException in GridMergeIndexSorted > -- > > Key: IGNITE-5190 > URL: https://issues.apache.org/jira/browse/IGNITE-5190 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.0 >Reporter: Andrew Mashenkov >Assignee: Sergi Vladykin > Fix For: 2.1 > > Attachments: join-on-subquery-exception.txt, > JoinWithSubQueryFails.java > > > PFA stacktrace with query. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-5190) ArrayIndexOutOfBoundsException in GridMergeIndexSorted
[ https://issues.apache.org/jira/browse/IGNITE-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergi Vladykin resolved IGNITE-5190. Resolution: Fixed Fixed and merged to master 3a9dba5f86ad34736ccd278ebf91044e18cf9a6b > ArrayIndexOutOfBoundsException in GridMergeIndexSorted > -- > > Key: IGNITE-5190 > URL: https://issues.apache.org/jira/browse/IGNITE-5190 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.0 >Reporter: Andrew Mashenkov >Assignee: Sergi Vladykin > Fix For: 2.1 > > Attachments: join-on-subquery-exception.txt, > JoinWithSubQueryFails.java > > > PFA stacktrace with query. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-5190) ArrayIndexOutOfBoundsException in GridMergeIndexSorted
[ https://issues.apache.org/jira/browse/IGNITE-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergi Vladykin reassigned IGNITE-5190: -- Assignee: Sergi Vladykin > ArrayIndexOutOfBoundsException in GridMergeIndexSorted > -- > > Key: IGNITE-5190 > URL: https://issues.apache.org/jira/browse/IGNITE-5190 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.0 >Reporter: Andrew Mashenkov >Assignee: Sergi Vladykin > Fix For: 2.1 > > Attachments: join-on-subquery-exception.txt, > JoinWithSubQueryFails.java > > > PFA stacktrace with query. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-5204) The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception
Chris Wang created IGNITE-5204: -- Summary: The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception Key: IGNITE-5204 URL: https://issues.apache.org/jira/browse/IGNITE-5204 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.0 Environment: windows server 2012, JDK 1.8, X64 Reporter: Chris Wang Priority: Critical When put "草DX009090" as the value of BillId, which is a field of entity Bill. If I define a index includes the BillId, and execute the query like "select * from Bill where BillId=’草DX009090‘ in the H2 debug console, there throws an exception by the H2 with a code 5000. another scenario is, I have two entities, "Bill" and "Detail", both have field "BillId". If either of them have value like "草DX009090" and execute the query like "select bill.* from bill left join detail on bill.billid=detail.billid", the whole ignite cache node will halt ( suppose there should be an stack overhead exception, dead loop). == I think the issue should relate to hash computing on the unicode character. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-5202) Default mem policy name is not changed after setting defaultMemoryPolicyName property
[
https://issues.apache.org/jira/browse/IGNITE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov reassigned IGNITE-5202:
---
Assignee: Sergey Chugunov
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property
> -
>
> Key: IGNITE-5202
> URL: https://issues.apache.org/jira/browse/IGNITE-5202
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Ksenia Rybakova
>Assignee: Sergey Chugunov
> Fix For: 2.1
>
>
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property.
> Config:
> {noformat}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
>
> class="org.apache.ignite.configuration.IgniteConfiguration"
> parent="base-ignite.cfg">
>
>
>
> ...
>
>
>
>parent="base-mem.cfg">
>
>
>
>
>
>
> {noformat}
> {noformat}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration" abstract="true">
> ...
>
> class="org.apache.ignite.configuration.MemoryConfiguration" abstract="true">
>...
>
>
>...
> class="org.apache.ignite.configuration.MemoryPolicyConfiguration">
>
>
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
>...
>
> {noformat}
> According to this config default memory policy should be "default2", but it
> remains "default" (while SystemCacheInitialSize was changed successfully to
> 50Mb as it's set in config).
> {noformat}
> [12:48:12,226][INFO ][main][IgniteKernal] System cache's MemoryPolicy size is
> configured to 50 MB. Use MemoryConfiguration.systemCacheMemorySize property
> to change the setting.
> [12:48:12,226][INFO ][main][IgniteKernal] Configured caches [in 'default'
> memoryPolicy: ['ignite-sys-cache', 'ignite-atomics-sys-cache', 'atomic-part',
> 'atomic-rplc', 'atomic-part-fat-values', 'atomic-part-onheap-evict-fifo',
> 'atomic-rplc-onheap-evict-lru', 'tx-part', 'tx-rplc', 'tx-part-fat-values',
> 'compute', 'tx-part-onheap-evict-lru', 'tx-rplc-onheap-evict-fifo',
> 'atomic-index', 'query', 'orgCache']]
> {noformat}
> Also it would be nice to have default policy name instead of "null" in logs
> when printing caches info:
> {noformat}
> <12:48:12> Cache configured with the following parameters:
> CacheConfiguration [name=atomic-part, memPlcName=null,
> storeConcurrentLoadAllThreshold=5, ...
> {noformat}
> {noformat}
> [12:48:13,239][INFO ][main][GridCacheProcessor] Started cache
> [name=atomic-part, memoryPolicyName=null, mode=PARTITIONED]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4646) Try to unmarshall direct messages in striped pool
[
https://issues.apache.org/jira/browse/IGNITE-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006329#comment-16006329
]
Igor Seliverstov edited comment on IGNITE-4646 at 5/11/17 12:27 PM:
[~yzhdanov], Here are numbers:
|| ||ignite-4646 rev: bbabcbb||master rev: 46ff66||delta||
|*atomic-put*|85046.6|101168|{color:red}-18.96%{color}|
was (Author: gvvinblade):
[~yzhdanov] Here are numbers:
|| ||ignite-4646 rev: bbabcbb||master rev: 46ff66||delta||
|*atomic-put*|85046.6|101168|{color:red}-18.96%{color}|
> Try to unmarshall direct messages in striped pool
> -
>
> Key: IGNITE-4646
> URL: https://issues.apache.org/jira/browse/IGNITE-4646
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.1
>
>
> During marshalling in NIO thread the following should be added to the write
> buffer and sent to peer:
> 1. chunk size - 16 bits (this probably puts limitation on max write buffer
> size of 64k or will require some changes to direct writer)
> 2. last chunk - 1 bit
> 3. pool policy - 8 bits
> Here is the scheme to explain how this should work.
> {noformat}
> [chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more
> space in write buffer
> [next chunk size] [last flag] [chunk data] <<-- we write next chunk once some
> space is available in write buffer, but we skip partition and policy flags
> and maybe others that should be sent only once.
> ...
> ...
> [next chunk size] [last flag] [chunk data] <<-- last flag is true here
> {noformat}
> Examples
> Write buffer - 64k
> Message - 84k
> # sender reserves space for chunk size
> # reserves space for policy and last chunk flag
> # marshalls message to buffer while it has free space (64k - SPACE will be
> written to buffer)
> # puts size and flags to reserved space in the beginning
> # sends buffer or part of it which makes some space available to further
> writes
> # reserves space for next chunk size and flags
> # marshalls message to buffer while it has free space (lets assume the rest
> of message fits)
> # puts size and last=true to the reserved space and sends
> Receiver:
> # reads chunk size, stores the target pool and partition
> # allocates heap buffer and copies chunk data to it from read buffer
> # once all message chunks are fully read message should be submitted to a
> pool where it will be unmarshalled and processed
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4646) Try to unmarshall direct messages in striped pool
[
https://issues.apache.org/jira/browse/IGNITE-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006329#comment-16006329
]
Igor Seliverstov edited comment on IGNITE-4646 at 5/11/17 12:27 PM:
[~yzhdanov] Here are numbers:
|| ||ignite-4646 rev: bbabcbb||master rev: 46ff66||delta||
|*atomic-put*|85046.6|101168|{color:red}-18.96%{color}|
was (Author: gvvinblade):
[~yzhdanov]] Here are numbers:
|| ||ignite-4646 rev: bbabcbb||master rev: 46ff66||delta||
|*atomic-put*|85046.6|101168|{color:red}-18.96%{color}|
> Try to unmarshall direct messages in striped pool
> -
>
> Key: IGNITE-4646
> URL: https://issues.apache.org/jira/browse/IGNITE-4646
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.1
>
>
> During marshalling in NIO thread the following should be added to the write
> buffer and sent to peer:
> 1. chunk size - 16 bits (this probably puts limitation on max write buffer
> size of 64k or will require some changes to direct writer)
> 2. last chunk - 1 bit
> 3. pool policy - 8 bits
> Here is the scheme to explain how this should work.
> {noformat}
> [chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more
> space in write buffer
> [next chunk size] [last flag] [chunk data] <<-- we write next chunk once some
> space is available in write buffer, but we skip partition and policy flags
> and maybe others that should be sent only once.
> ...
> ...
> [next chunk size] [last flag] [chunk data] <<-- last flag is true here
> {noformat}
> Examples
> Write buffer - 64k
> Message - 84k
> # sender reserves space for chunk size
> # reserves space for policy and last chunk flag
> # marshalls message to buffer while it has free space (64k - SPACE will be
> written to buffer)
> # puts size and flags to reserved space in the beginning
> # sends buffer or part of it which makes some space available to further
> writes
> # reserves space for next chunk size and flags
> # marshalls message to buffer while it has free space (lets assume the rest
> of message fits)
> # puts size and last=true to the reserved space and sends
> Receiver:
> # reads chunk size, stores the target pool and partition
> # allocates heap buffer and copies chunk data to it from read buffer
> # once all message chunks are fully read message should be submitted to a
> pool where it will be unmarshalled and processed
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4646) Try to unmarshall direct messages in striped pool
[
https://issues.apache.org/jira/browse/IGNITE-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006329#comment-16006329
]
Igor Seliverstov edited comment on IGNITE-4646 at 5/11/17 12:27 PM:
[~yzhdanov]] Here are numbers:
|| ||ignite-4646 rev: bbabcbb||master rev: 46ff66||delta||
|*atomic-put*|85046.6|101168|{color:red}-18.96%{color}|
was (Author: gvvinblade):
Here are numbers:
|| ||ignite-4646 rev: bbabcbb||master rev: 46ff66||delta||
|*atomic-put*|85046.6|101168|{color:red}-18.96%{color}|
> Try to unmarshall direct messages in striped pool
> -
>
> Key: IGNITE-4646
> URL: https://issues.apache.org/jira/browse/IGNITE-4646
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.1
>
>
> During marshalling in NIO thread the following should be added to the write
> buffer and sent to peer:
> 1. chunk size - 16 bits (this probably puts limitation on max write buffer
> size of 64k or will require some changes to direct writer)
> 2. last chunk - 1 bit
> 3. pool policy - 8 bits
> Here is the scheme to explain how this should work.
> {noformat}
> [chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more
> space in write buffer
> [next chunk size] [last flag] [chunk data] <<-- we write next chunk once some
> space is available in write buffer, but we skip partition and policy flags
> and maybe others that should be sent only once.
> ...
> ...
> [next chunk size] [last flag] [chunk data] <<-- last flag is true here
> {noformat}
> Examples
> Write buffer - 64k
> Message - 84k
> # sender reserves space for chunk size
> # reserves space for policy and last chunk flag
> # marshalls message to buffer while it has free space (64k - SPACE will be
> written to buffer)
> # puts size and flags to reserved space in the beginning
> # sends buffer or part of it which makes some space available to further
> writes
> # reserves space for next chunk size and flags
> # marshalls message to buffer while it has free space (lets assume the rest
> of message fits)
> # puts size and last=true to the reserved space and sends
> Receiver:
> # reads chunk size, stores the target pool and partition
> # allocates heap buffer and copies chunk data to it from read buffer
> # once all message chunks are fully read message should be submitted to a
> pool where it will be unmarshalled and processed
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4646) Try to unmarshall direct messages in striped pool
[
https://issues.apache.org/jira/browse/IGNITE-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006329#comment-16006329
]
Igor Seliverstov commented on IGNITE-4646:
--
Here are numbers:
|| ||ignite-4646 rev: bbabcbb||master rev: 46ff66||delta||
|*atomic-put*|85046.6|101168|{color:red}-18.96%{color}|
> Try to unmarshall direct messages in striped pool
> -
>
> Key: IGNITE-4646
> URL: https://issues.apache.org/jira/browse/IGNITE-4646
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.1
>
>
> During marshalling in NIO thread the following should be added to the write
> buffer and sent to peer:
> 1. chunk size - 16 bits (this probably puts limitation on max write buffer
> size of 64k or will require some changes to direct writer)
> 2. last chunk - 1 bit
> 3. pool policy - 8 bits
> Here is the scheme to explain how this should work.
> {noformat}
> [chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more
> space in write buffer
> [next chunk size] [last flag] [chunk data] <<-- we write next chunk once some
> space is available in write buffer, but we skip partition and policy flags
> and maybe others that should be sent only once.
> ...
> ...
> [next chunk size] [last flag] [chunk data] <<-- last flag is true here
> {noformat}
> Examples
> Write buffer - 64k
> Message - 84k
> # sender reserves space for chunk size
> # reserves space for policy and last chunk flag
> # marshalls message to buffer while it has free space (64k - SPACE will be
> written to buffer)
> # puts size and flags to reserved space in the beginning
> # sends buffer or part of it which makes some space available to further
> writes
> # reserves space for next chunk size and flags
> # marshalls message to buffer while it has free space (lets assume the rest
> of message fits)
> # puts size and last=true to the reserved space and sends
> Receiver:
> # reads chunk size, stores the target pool and partition
> # allocates heap buffer and copies chunk data to it from read buffer
> # once all message chunks are fully read message should be submitted to a
> pool where it will be unmarshalled and processed
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5163) JDBC Driver: implement handshake for thin jdbc driver based on common odbc/jdbc protocol
[
https://issues.apache.org/jira/browse/IGNITE-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006313#comment-16006313
]
Taras Ledkov commented on IGNITE-5163:
--
[~isapego], please take a look again. I've refactored {{OdbcMessageParser}}
according with [~vozerov]'s comments.
> JDBC Driver: implement handshake for thin jdbc driver based on common
> odbc/jdbc protocol
>
>
> Key: IGNITE-5163
> URL: https://issues.apache.org/jira/browse/IGNITE-5163
> Project: Ignite
> Issue Type: Task
> Components: odbc, sql
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>
> The GridClient must be removed from thin jdbc driver.
> It is the first step to unify JDBC & ODBC protocols.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5203) JDBC driver should support BLOB fields
Andrey Gura created IGNITE-5203: --- Summary: JDBC driver should support BLOB fields Key: IGNITE-5203 URL: https://issues.apache.org/jira/browse/IGNITE-5203 Project: Ignite Issue Type: Bug Affects Versions: 2.0 Reporter: Andrey Gura JDBD driver doesn't support BLOB fields. Need to implement BLOBs, at least simple byte array based implementation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-5194) .NET: TryGetIgnite does not work with AutoGenerateIgniteInstanceName
[
https://issues.apache.org/jira/browse/IGNITE-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-5194.
Resolution: Fixed
> .NET: TryGetIgnite does not work with AutoGenerateIgniteInstanceName
>
>
> Key: IGNITE-5194
> URL: https://issues.apache.org/jira/browse/IGNITE-5194
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> {{Ignition.GetIgnite()}} has been reworked to return instance with any name
> if there is only one present. This is needed to work nicely with
> {{AutoGenerateIgniteInstanceName}}.
> {{TryGetIgnite()}}, however, was not updated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5194) .NET: TryGetIgnite does not work with AutoGenerateIgniteInstanceName
[
https://issues.apache.org/jira/browse/IGNITE-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006222#comment-16006222
]
Pavel Tupitsyn commented on IGNITE-5194:
Fixed in master: 57c6705050219e15e218fbc3c0e9f7d6bf8803f5
> .NET: TryGetIgnite does not work with AutoGenerateIgniteInstanceName
>
>
> Key: IGNITE-5194
> URL: https://issues.apache.org/jira/browse/IGNITE-5194
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> {{Ignition.GetIgnite()}} has been reworked to return instance with any name
> if there is only one present. This is needed to work nicely with
> {{AutoGenerateIgniteInstanceName}}.
> {{TryGetIgnite()}}, however, was not updated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5202) Default mem policy name is not changed after setting defaultMemoryPolicyName property
[
https://issues.apache.org/jira/browse/IGNITE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ksenia Rybakova updated IGNITE-5202:
Description:
Default mem policy name is not changed after setting defaultMemoryPolicyName
property.
Config:
{noformat}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
...
{noformat}
{noformat}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
...
...
...
...
{noformat}
According to this config default memory policy should be "default2", but it
remains "default" (while SystemCacheInitialSize was changed successfully to
50Mb as it's set in config).
{noformat}
[12:48:12,226][INFO ][main][IgniteKernal] System cache's MemoryPolicy size is
configured to 50 MB. Use MemoryConfiguration.systemCacheMemorySize property to
change the setting.
[12:48:12,226][INFO ][main][IgniteKernal] Configured caches [in 'default'
memoryPolicy: ['ignite-sys-cache', 'ignite-atomics-sys-cache', 'atomic-part',
'atomic-rplc', 'atomic-part-fat-values', 'atomic-part-onheap-evict-fifo',
'atomic-rplc-onheap-evict-lru', 'tx-part', 'tx-rplc', 'tx-part-fat-values',
'compute', 'tx-part-onheap-evict-lru', 'tx-rplc-onheap-evict-fifo',
'atomic-index', 'query', 'orgCache']]
{noformat}
Also it would be nice to have default policy name instead of "null" in logs
when printing caches info:
{noformat}
<12:48:12> Cache configured with the following parameters:
CacheConfiguration [name=atomic-part, memPlcName=null,
storeConcurrentLoadAllThreshold=5, ...
{noformat}
{noformat}
[12:48:13,239][INFO ][main][GridCacheProcessor] Started cache
[name=atomic-part, memoryPolicyName=null, mode=PARTITIONED]
{noformat}
was:
Default mem policy name is not changed after setting defaultMemoryPolicyName
property.
Config:
{noformat}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
...
{noformat}
{noformat}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
...
...
...
...
{noformat}
According to this config default memory policy should be "default2", but it
remains "default" (while SystemCacheInitialSize was changed successfully to
50Mb as it's set in config).
{noformat}
[12:48:12,226][INFO ][main][IgniteKernal] System cache's MemoryPolicy size is
configured to 50 MB. Use MemoryConfiguration.systemCacheMemorySize property to
change the setting.
[12:48:12,226][INFO ][main][IgniteKernal] Configured caches [in 'default'
memoryPolicy: ['ignite-sys-cache', 'ignite-atomics-sys-cache', 'atomic-part',
'atomic-rplc', 'atomic-part-fat-values', 'atomic-part-onheap-evict-fifo',
'atomic-rplc-onheap-evict-lru', 'tx-part', 'tx-rplc', 'tx-part-fat-values',
'compute', 'tx-part-onheap-evict-lru', 'tx-rplc-onheap-evict-fifo',
'atomic-index', 'query', 'orgCache']]
{noformat}
Also it would be nice to have default policy name instead of "null" in logs
when printing caches info:
{noformat}
<12:48:12> Cache configured with the following parameters:
CacheConfiguration [name=atomic-part, memPlcName=null,
storeConcurrentLoadAllThreshold=5, ...
{noformat}
{noformat}
[12:48:13,239][INFO ][main][GridCacheProcessor] Started cache
[name=atomic-part, memoryPolicyName=null, mode=PARTITIONED]
{noformat}
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property
> -
>
> Key: IGNITE-5202
> URL: https://issues.apache.org/jira/browse/IGNITE-5202
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Ksenia Rybakova
> Fix For: 2.1
>
>
> Default mem policy name
[jira] [Created] (IGNITE-5202) Default mem policy name is not changed after setting defaultMemoryPolicyName property
Ksenia Rybakova created IGNITE-5202:
---
Summary: Default mem policy name is not changed after setting
defaultMemoryPolicyName property
Key: IGNITE-5202
URL: https://issues.apache.org/jira/browse/IGNITE-5202
Project: Ignite
Issue Type: Bug
Affects Versions: 2.0
Reporter: Ksenia Rybakova
Fix For: 2.1
Default mem policy name is not changed after setting defaultMemoryPolicyName
property.
Config:
{noformat}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
...
{noformat}
{noformat}
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
...
...
...
...
{noformat}
According to this config default memory policy should be "default2", but it
remains "default" (while SystemCacheInitialSize was changed successfully to
50Mb as it's set in config).
{noformat}
[12:48:12,226][INFO ][main][IgniteKernal] System cache's MemoryPolicy size is
configured to 50 MB. Use MemoryConfiguration.systemCacheMemorySize property to
change the setting.
[12:48:12,226][INFO ][main][IgniteKernal] Configured caches [in 'default'
memoryPolicy: ['ignite-sys-cache', 'ignite-atomics-sys-cache', 'atomic-part',
'atomic-rplc', 'atomic-part-fat-values', 'atomic-part-onheap-evict-fifo',
'atomic-rplc-onheap-evict-lru', 'tx-part', 'tx-rplc', 'tx-part-fat-values',
'compute', 'tx-part-onheap-evict-lru', 'tx-rplc-onheap-evict-fifo',
'atomic-index', 'query', 'orgCache']]
{noformat}
Also it would be nice to have default policy name instead of "null" in logs
when printing caches info:
{noformat}
<12:48:12> Cache configured with the following parameters:
CacheConfiguration [name=atomic-part, memPlcName=null,
storeConcurrentLoadAllThreshold=5, ...
{noformat}
{noformat}
[12:48:13,239][INFO ][main][GridCacheProcessor] Started cache
[name=atomic-part, memoryPolicyName=null, mode=PARTITIONED]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-1264) Resource SPI
[ https://issues.apache.org/jira/browse/IGNITE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006193#comment-16006193 ] Ihor Parashynets commented on IGNITE-1264: -- hi all is there a plan to move on this topic? Thanks... > Resource SPI > > > Key: IGNITE-1264 > URL: https://issues.apache.org/jira/browse/IGNITE-1264 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Andrey Kornev > > As a user I'd like to be able to customize how resource injection is done by > Ignite: for example, I'd like to be able to process any custom annotations on > my application's class after its deserialization on a remote node. > Ideally, Ignite should expose an SPI that would be delegated to at specific > points of the dependency injection logic (as currently implemented in the > GridResourceProcessor class). > Once implemented, this feature would allow to make the injector support > pluggable: Spring, Guice, Dagger, whatever... Ultimately it'd be great to > replace all injection-related Ignite annotations by the standard javax.inject > API. > For references, here's the nabble thread: > http://apache-ignite-developers.2346864.n4.nabble.com/Resource-SPI-proposal-td2318.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[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=16006158#comment-16006158 ] Igor Sapego commented on IGNITE-5097: - Well, on the second thought, there will be always about 6 bytes when used for time types, which makes it not very profitable (only saving 2 bytes per value) but could badly slow down marshalling. So, I guess, we should not implement that. > 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.1 > > > 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.3.15#6346)
[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=16006153#comment-16006153
]
Pavel Tupitsyn commented on IGNITE-5097:
For {{UUID}} it does not make sense, since it is a pair of large values at most
cases.
As for {{Timestamp}}, I would at least write a microbenchmark to test how
current implementation compares with varint on values which represent current
time.
> 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.1
>
>
> 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.3.15#6346)
[jira] [Commented] (IGNITE-4205) CassandraCacheStore should start IgniteThread threads in loadCache() method
[
https://issues.apache.org/jira/browse/IGNITE-4205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006142#comment-16006142
]
Konstantin Dudkov commented on IGNITE-4205:
---
The weird moment: we can't get object from cache after loadAll(), because we
can't deserealize it due to absence of metadata in new ignite instance. But we
can get binary representation of it using .withKeepBinary().get()
> CassandraCacheStore should start IgniteThread threads in loadCache() method
> ---
>
> Key: IGNITE-4205
> URL: https://issues.apache.org/jira/browse/IGNITE-4205
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Konstantin Dudkov
>
> {{CassandraCacheStore.loadCache()}} method starts a generic thread pool for
> parallel data load. Threads in this thread pool can't deserialize Ignite
> internal objects (e.g. {{IgniteKernal}}) which can cause unexpected behavior.
> Here is one of the scenarios:
> * There is column in Cassandra which stores an object as BLOB using
> {{JavaSerializer}}.
> * {{CacheConfiguration.storeKeepBinary}} is {{true}}.
> * When an object is saved, it's passed to the store as an instance of
> {{BinaryObject}} which is converted to a byte array and saved in Cassandra.
> * When the same object is loaded in {{loadCache}}, the store takes the byte
> array and tries to convert it to {{BinaryObject}}. But it can't because this
> implies calling {{IgnitionEx.localIgnite()}} from non-Ignite thread.
> To fix this we need to provide a thread factory that will create instances of
> {{IgniteThread}} and use it in the pool that loads the data.
> Most likely the same issue exists in {{CacheAbstractJdbcStore}}.
> And in general, any threads created by Ignite internals should be
> {{IgniteThread}}-s. This should be revisited.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4597) CPP: Add mechanism to reset arguments for sql queries.
[
https://issues.apache.org/jira/browse/IGNITE-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006138#comment-16006138
]
Igor Sapego commented on IGNITE-4597:
-
[~vinx13], can you also fix C++ Query Example? You can find it at
{{cpp/examples/query-example/src/query_example.cpp}}. There you can find lines
like
{code}
SqlQuery qry(PERSON_TYPE, sql);
/...
qry = SqlQuery(PERSON_TYPE, sql);
{code}
That's where {{ClearArguments()}} call could be used. There are several places
like that in the example.
> CPP: Add mechanism to reset arguments for sql queries.
> --
>
> Key: IGNITE-4597
> URL: https://issues.apache.org/jira/browse/IGNITE-4597
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Wuwei Lin
> Labels: cpp, newbie
>
> Currently, there is method {{AddArgument}} for {{SqlQuery}} and
> {{SqlFieldsQuery}}, but there is no way to reset arguments for query once
> they are set. This leads to inconvenience when user want to call the same
> query with different arguments as they need to re-create exactly the same
> query but set different arguments for it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4597) CPP: Add mechanism to reset arguments for sql queries.
[
https://issues.apache.org/jira/browse/IGNITE-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006138#comment-16006138
]
Igor Sapego edited comment on IGNITE-4597 at 5/11/17 9:27 AM:
--
[~vinx13], can you also fix C++ Query Example? You can find it at
{{cpp/examples/query-example/src/query_example.cpp}}. There you can find lines
like
{code}
SqlQuery qry(PERSON_TYPE, sql);
//...
qry = SqlQuery(PERSON_TYPE, sql);
{code}
That's where {{ClearArguments()}} call could be used. There are several places
like that in the example.
was (Author: isapego):
[~vinx13], can you also fix C++ Query Example? You can find it at
{{cpp/examples/query-example/src/query_example.cpp}}. There you can find lines
like
{code}
SqlQuery qry(PERSON_TYPE, sql);
/...
qry = SqlQuery(PERSON_TYPE, sql);
{code}
That's where {{ClearArguments()}} call could be used. There are several places
like that in the example.
> CPP: Add mechanism to reset arguments for sql queries.
> --
>
> Key: IGNITE-4597
> URL: https://issues.apache.org/jira/browse/IGNITE-4597
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Wuwei Lin
> Labels: cpp, newbie
>
> Currently, there is method {{AddArgument}} for {{SqlQuery}} and
> {{SqlFieldsQuery}}, but there is no way to reset arguments for query once
> they are set. This leads to inconvenience when user want to call the same
> query with different arguments as they need to re-create exactly the same
> query but set different arguments for it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5201) .NET: SegmentationResolver
Pavel Tupitsyn created IGNITE-5201:
--
Summary: .NET: SegmentationResolver
Key: IGNITE-5201
URL: https://issues.apache.org/jira/browse/IGNITE-5201
Project: Ignite
Issue Type: New Feature
Components: platforms
Reporter: Pavel Tupitsyn
Fix For: 2.2
Support {{SegmentationResolver}} natively in .NET
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4052) Add ability to set up users for MESOS
[
https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Opolski updated IGNITE-4052:
--
Hello guys!
I want to update https://apacheignite.readme.io/docs/mesos-deployment with
new text according with
https://cwiki.apache.org/confluence/display/IGNITE/Documentation
But have a problem with authentication, registered login
vaopols...@gmail.com.
Help me, please.
New text:
3.Copy the following application definition (in JSON format) and save to
marathon.json file. Update any parameters which would like to change.
*A role name must be a valid directory name, so it cannot: • Be an empty
string • Be . or .. • Start with - • Contain any slash, backspace, or
whitespace character*
If doesn't set restriction on cluster then the framework will try to
occupy all resources in Mesos cluster. See Configuration section below.
JSON
{
"id": "ignition",
"instances": 1,
"cpus": 2,
"mem": 2048,
"ports": [0],
"uris": [
"http://host/ignite-mesos--jar-with-dependencies.jar"
],
"env": {
"IGNITE_NODE_COUNT": "4",
"MESOS_MASTER_URL": "zk://localhost:2181/mesos",
"IGNITE_RUN_CPU_PER_NODE": "2",
"IGNITE_MEMORY_PER_NODE": "2048",
"IGNITE_VERSION": "1.0.5",
*"MESOS_USER" : "userA","MESOS_ROLE" : "role1"* },
"cmd": "java -jar ignite-mesos--jar-with-dependencies.jar"
}
Vadim
> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster
> via current user. Need to add ability to configure this parameters via system
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-5174) Need to have opportunity to list only server nodes for specified topology version
[ https://issues.apache.org/jira/browse/IGNITE-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny reassigned IGNITE-5174: -- Assignee: Eduard Shangareev (was: Stanilovsky Evgeny) > Need to have opportunity to list only server nodes for specified topology > version > - > > Key: IGNITE-5174 > URL: https://issues.apache.org/jira/browse/IGNITE-5174 > Project: Ignite > Issue Type: Bug >Reporter: Stanilovsky Evgeny >Assignee: Eduard Shangareev >Priority: Minor > Fix For: 2.1 > > > Need to have common utility function which filters client nodes for specified > topology version. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4597) CPP: Add mechanism to reset arguments for sql queries.
[
https://issues.apache.org/jira/browse/IGNITE-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006068#comment-16006068
]
ASF GitHub Bot commented on IGNITE-4597:
GitHub user vinx13 opened a pull request:
https://github.com/apache/ignite/pull/1926
IGNITE-4597: CPP: Add mechanism to reset arguments for sql queries.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/vinx13/ignite ignite-4597
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/1926.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 #1926
commit 262a06abcb0d7b2588072985cf5f94f70e6c57da
Author: Wuwei Lin
Date: 2017-05-10T14:12:03Z
Add methods to reset arguments in sql query
> CPP: Add mechanism to reset arguments for sql queries.
> --
>
> Key: IGNITE-4597
> URL: https://issues.apache.org/jira/browse/IGNITE-4597
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Wuwei Lin
> Labels: cpp, newbie
>
> Currently, there is method {{AddArgument}} for {{SqlQuery}} and
> {{SqlFieldsQuery}}, but there is no way to reset arguments for query once
> they are set. This leads to inconvenience when user want to call the same
> query with different arguments as they need to re-create exactly the same
> query but set different arguments for it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[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=16006066#comment-16006066
]
Vyacheslav Daradur commented on IGNITE-5097:
[~isapego],
I didn't implement it, because it isn't described in the task.
If we implement a writing long/int64 in varint encoding, we will be able to use
it at serializing for following types: {{Long}} (1 long), {{Date}} (1 long),
{{Time}} (1 long), {{Timestamp}} (1 long), {{UUID}} (2 longs).
I think there will be less proffit than in implemented varint, because long
values usualy is big. ({{Date}}, {{Time}}, {{Timestamp}}, {{UUID}}).
But it will allow us to use memory more effectively, it is always cool)
[~vozerov], [~ptupitsyn], any thougths?
> 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.1
>
>
> 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.3.15#6346)
[jira] [Created] (IGNITE-5200) Web Console: Watch in ignite_modules works incorrect after migration on webpack2
Andrey Novikov created IGNITE-5200: -- Summary: Web Console: Watch in ignite_modules works incorrect after migration on webpack2 Key: IGNITE-5200 URL: https://issues.apache.org/jira/browse/IGNITE-5200 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 2.0 Reporter: Andrey Novikov Fix For: 2.1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005997#comment-16005997 ] Dmitriy Govorukhin edited comment on IGNITE-1094 at 5/11/17 7:28 AM: - Hi [~Alexey Kuznetsov], i did quick review, and i have some concern. It would be better if you create public review in [upsorce|http://reviews.ignite.apache.org], i will leave my comments there. One more think, could you please create only one pull request per one jira task. was (Author: dmitriygovorukhin): Hi [~Alexey Kuznetsov], i do quick review, and i have some concern. It would be better if you create public review in [upsorce|http://reviews.ignite.apache.org], i will leave my comments there. One more think, could you please create only one pull request per one jira task. > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Alexey Kuznetsov > Labels: Muted_test > Fix For: 2.1 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-5165) Web Console: Buttons redesign
[ https://issues.apache.org/jira/browse/IGNITE-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005998#comment-16005998 ] Ilya Borisov edited comment on IGNITE-5165 at 5/11/17 7:18 AM: --- [~anovikov] Please review. Attached patch has debug page with all new buttons demo. was (Author: klaster_1): Please review. > Web Console: Buttons redesign > --- > > Key: IGNITE-5165 > URL: https://issues.apache.org/jira/browse/IGNITE-5165 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Dmitriy Shabalin >Assignee: Andrey Novikov > Attachments: 5165 debug page.diff > > > Create common style to all buttons in project. > Refactoring current style for buttons in > web-console/frontend/public/stylesheets/style.scss > 1) Button with icon and text > 2) Button with only icon > 3) Button with only text > 4) Button group > 5) fill and stroke buttons for color Red, Blue, White > Implement class modificator .btn-ignite to apply this features -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005997#comment-16005997 ] Dmitriy Govorukhin commented on IGNITE-1094: Hi [~Alexey Kuznetsov], i do quick review, and i have some concern. It would be better if you create public review in [upsorce|http://reviews.ignite.apache.org], i will leave my comments there. One more think, could you please create only one pull request per one jira task. > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Alexey Kuznetsov > Labels: Muted_test > Fix For: 2.1 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-5165) Web Console: Buttons redesign
[ https://issues.apache.org/jira/browse/IGNITE-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-5165: Assignee: Andrey Novikov (was: Ilya Borisov) Please review. > Web Console: Buttons redesign > --- > > Key: IGNITE-5165 > URL: https://issues.apache.org/jira/browse/IGNITE-5165 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Dmitriy Shabalin >Assignee: Andrey Novikov > Attachments: 5165 debug page.diff > > > Create common style to all buttons in project. > Refactoring current style for buttons in > web-console/frontend/public/stylesheets/style.scss > 1) Button with icon and text > 2) Button with only icon > 3) Button with only text > 4) Button group > 5) fill and stroke buttons for color Red, Blue, White > Implement class modificator .btn-ignite to apply this features -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5165) Web Console: Buttons redesign
[ https://issues.apache.org/jira/browse/IGNITE-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-5165: - Attachment: 5165 debug page.diff Debug page to test new buttons. Access at `/debug`. > Web Console: Buttons redesign > --- > > Key: IGNITE-5165 > URL: https://issues.apache.org/jira/browse/IGNITE-5165 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Dmitriy Shabalin >Assignee: Ilya Borisov > Attachments: 5165 debug page.diff > > > Create common style to all buttons in project. > Refactoring current style for buttons in > web-console/frontend/public/stylesheets/style.scss > 1) Button with icon and text > 2) Button with only icon > 3) Button with only text > 4) Button group > 5) fill and stroke buttons for color Red, Blue, White > Implement class modificator .btn-ignite to apply this features -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-5125) Need to improve logging in case of hang
[
https://issues.apache.org/jira/browse/IGNITE-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny reassigned IGNITE-5125:
--
Assignee: Semen Boikov (was: Stanilovsky Evgeny)
> Need to improve logging in case of hang
> ---
>
> Key: IGNITE-5125
> URL: https://issues.apache.org/jira/browse/IGNITE-5125
> Project: Ignite
> Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 2.1
>
>
> 1. When cache operation hangs on node it is not reported as hanged although
> partition map exchange cannot finish.
> {noformat}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x7fdd260fd7c0> (a
> org.apache.ignite.internal.util.future.GridEmbeddedFuture)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2356)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2354)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4168)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2354)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2335)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2312)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379)
> {noformat}
> {noformat}
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x7fa0698fee50> (a
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:161)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4570)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4544)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1428)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.getAtomic(DataStructuresProcessor.java:589)
> at
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.sequence(DataStructuresProcessor.java:397)
> {noformat}
> 2. Partition exchnage future dumps objects only limited number of times. I
> would suggest to switch to mode when we double the delay between dumps each
> time, but no more than 30min
> 3. If exchange worker is stuck at
> GridDhtPartitionsExchangeFuture.waitPartitionRelease then unreleased
> partitions should be reported (same rules as of pt 2 apply)
> {noformat}
> "exchange-worker-#93%...%" #143 prio=5 os_prio=0 tid=0x7fd782df3000
> nid=0x1526 waiting on condition [0x7fc2dc9c5000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x7fcab30006b8> (a
> org.apache.ignite.internal.util.future.GridCompoundFuture)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer
