[jira] [Commented] (IGNITE-3665) Update KafkaStreamer dependencies
[ https://issues.apache.org/jira/browse/IGNITE-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15476009#comment-15476009 ] Saikat Maitra commented on IGNITE-3665: --- [~roman_s] Hi Roman, Changes looks good to merge. Regards Saikat > Update KafkaStreamer dependencies > - > > Key: IGNITE-3665 > URL: https://issues.apache.org/jira/browse/IGNITE-3665 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Fix For: 1.8 > > > Update for Kafka 0.10 > https://archive.apache.org/dist/kafka/0.10.0.0/RELEASE_NOTES.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3774) Web Console: Move logic from public route to AuthService
[ https://issues.apache.org/jira/browse/IGNITE-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-3774. -- Assignee: (was: Andrey Novikov) > Web Console: Move logic from public route to AuthService > > > Key: IGNITE-3774 > URL: https://issues.apache.org/jira/browse/IGNITE-3774 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov > Fix For: 1.8 > > > Move logic from public route to AuthService for better testing and clean > architecture. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3774) Web Console: Move logic from public route to AuthService
[ https://issues.apache.org/jira/browse/IGNITE-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475990#comment-15475990 ] Andrey Novikov commented on IGNITE-3774: Reviewed. Merged. > Web Console: Move logic from public route to AuthService > > > Key: IGNITE-3774 > URL: https://issues.apache.org/jira/browse/IGNITE-3774 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > Fix For: 1.8 > > > Move logic from public route to AuthService for better testing and clean > architecture. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3172) Ignite-Cassandra serializers
[ https://issues.apache.org/jira/browse/IGNITE-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475963#comment-15475963 ] Igor Rudyak commented on IGNITE-3172: - Alexey, I guess you are proposing to use this: https://maven.apache.org/guides/mini/guide-attached-tests.html right? For this solution to work you should first do "mvn install" and then "mvn deploy" to build tests jar for "ignite-cassandra-store" module (according to the doc and I also checked this as well). It looks bad - you can't compile and build Ignite project until you do this two steps which are only needing for this tiny serialisers module. Thus I just created two simple unit tests for Kryo serializer - think this will be enough. Regarding your concern that somebody already using Cassandra module and have special logic to handle IgniteException. It looks very unlikely to me, cause it's server code which is running on Ignite server nodes, while users just using IgniteCache API on client side to talk with Ignite. Besides that, I don't think that it's a good approach to prevent fixing issues in design (even if they rather minor) just to support backward compatibility with previous versions. Anyway I pushed unit tests for serializers module to "ignite-3172" branch and they are available for your review. > Ignite-Cassandra serializers > > > Key: IGNITE-3172 > URL: https://issues.apache.org/jira/browse/IGNITE-3172 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Igor Rudyak >Assignee: Igor Rudyak > > Ignite-Cassandra module should contain only "standard" serializer based on > Java serialization mechanism. > It should be a separate module in Ignite project for all other alternative > implementations of serializers (based on Kryo, providing compression, > encryption and etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3665) Update KafkaStreamer dependencies
[
https://issues.apache.org/jira/browse/IGNITE-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475599#comment-15475599
]
Roman Shtykh commented on IGNITE-3665:
--
[~samaitra]
Hi Saikat,
Thanks you for reviewing!
1. Yes, CONFIG_DEF is needed for implementing abstract {{config()}}, even if it
is empty (we don't use it in our implementation).
2. They were used in {{modules/osgi-karaf/src/main/resources/features.xml}}
before, but not any more.
> Update KafkaStreamer dependencies
> -
>
> Key: IGNITE-3665
> URL: https://issues.apache.org/jira/browse/IGNITE-3665
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 1.8
>
>
> Update for Kafka 0.10
> https://archive.apache.org/dist/kafka/0.10.0.0/RELEASE_NOTES.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3207) Rename IgniteConfiguration.gridName
[ https://issues.apache.org/jira/browse/IGNITE-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3207: Labels: important (was: ) > Rename IgniteConfiguration.gridName > --- > > Key: IGNITE-3207 > URL: https://issues.apache.org/jira/browse/IGNITE-3207 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Biao Ma > Labels: important > Fix For: 2.0 > > > We have got a TON of questions on gridName property. Everyone thinks that > clusters are formed based on the gridName, that is, nodes with the same grid > name will join one cluster, and nodes with a different name will be in a > separate cluster. > Let's do the following: > * Deprecate IgniteConfiguration.gridName > * Add IgniteConfiguration.localInstanceName > * Rename related parameters in Ignition class (and other places, if present) > * Update Javadoc: clearly state that this name only works locally and has no > effect on topology. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3207) Rename IgniteConfiguration.gridName
[ https://issues.apache.org/jira/browse/IGNITE-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3207: Fix Version/s: (was: 1.8) 2.0 > Rename IgniteConfiguration.gridName > --- > > Key: IGNITE-3207 > URL: https://issues.apache.org/jira/browse/IGNITE-3207 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Biao Ma > Labels: important > Fix For: 2.0 > > > We have got a TON of questions on gridName property. Everyone thinks that > clusters are formed based on the gridName, that is, nodes with the same grid > name will join one cluster, and nodes with a different name will be in a > separate cluster. > Let's do the following: > * Deprecate IgniteConfiguration.gridName > * Add IgniteConfiguration.localInstanceName > * Rename related parameters in Ignition class (and other places, if present) > * Update Javadoc: clearly state that this name only works locally and has no > effect on topology. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3862) GridServiceProxy invocation never times out
[
https://issues.apache.org/jira/browse/IGNITE-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-3862:
Description:
{{GridServiceProxy}} uses compute for remote invocation. In some cases an
exception on server side can cause the closure execution never finish. For
example, this happens when the exception is thrown during the serialization of
the result.
Need to add additional {{IgniteServices.serviceProxy(..)}} method that will
additionally allow to specify custom timeout.
This timeout should limit the number of retries (there is an infinite loop now)
and also be passed to {{callAsyncNoFailover}} to avoid hangs.
was:
{{GridServiceProxy}} uses compute for remote invocation. In some cases an
exception on server side can cause the closure execution never finish. For
example, this happens when the exception is thrown during the serialization of
the result.
Need to add additional {{IgniteServices.serviceProxy(..)}} method that will
additionally allow to specify custom timeout.
> GridServiceProxy invocation never times out
> ---
>
> Key: IGNITE-3862
> URL: https://issues.apache.org/jira/browse/IGNITE-3862
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.8
>
>
> {{GridServiceProxy}} uses compute for remote invocation. In some cases an
> exception on server side can cause the closure execution never finish. For
> example, this happens when the exception is thrown during the serialization
> of the result.
> Need to add additional {{IgniteServices.serviceProxy(..)}} method that will
> additionally allow to specify custom timeout.
> This timeout should limit the number of retries (there is an infinite loop
> now) and also be passed to {{callAsyncNoFailover}} to avoid hangs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3872) Clarify #blockSize() behabviour in LocalFileSystemIgfsFile
Ivan Veselovsky created IGNITE-3872: --- Summary: Clarify #blockSize() behabviour in LocalFileSystemIgfsFile Key: IGNITE-3872 URL: https://issues.apache.org/jira/browse/IGNITE-3872 Project: Ignite Issue Type: Bug Components: IGFS Affects Versions: 1.6 Reporter: Ivan Veselovsky Assignee: Vladimir Ozerov Fix For: 1.8 LocalFileSystemIgfsFile constructor accepts blockSize parameter and there is a field to store the value, but zero always passed in, so LocalFileSystemIgfsFile#blockSize() is always zero. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3871) Document adaptive load balancing
Valentin Kulichenko created IGNITE-3871: --- Summary: Document adaptive load balancing Key: IGNITE-3871 URL: https://issues.apache.org/jira/browse/IGNITE-3871 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 1.7 Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko The page [1] describes only round robin and weighted SPIs. [1] https://apacheignite.readme.io/docs/load-balancing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3869) Reduce number of temporary objects produced by H2
[ https://issues.apache.org/jira/browse/IGNITE-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-3869: -- Summary: Reduce number of temporary objects produced by H2 (was: Reduce number of temporal objects produced by H2) > Reduce number of temporary objects produced by H2 > - > > Key: IGNITE-3869 > URL: https://issues.apache.org/jira/browse/IGNITE-3869 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.4 >Reporter: Denis Magda >Assignee: Sergi Vladykin > Fix For: 2.1 > > > Presently during the execution of a query H2 generates significant number of > temporal objects (kind of wrappers) that eventually exhaust the heap and > trigger long GC pauses. > Need to revisit present implementation improving Ignite SQL engine and/or H2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3870) Keeping SQL query result set in off heap tier
[ https://issues.apache.org/jira/browse/IGNITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-3870: -- Summary: Keeping SQL query result set in off heap tier (was: Keeping SQL query result set in off heap tire) > Keeping SQL query result set in off heap tier > - > > Key: IGNITE-3870 > URL: https://issues.apache.org/jira/browse/IGNITE-3870 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Dmitriy Setrakyan > > With the new off heap storage architectures (IGNITE-3477) it makes sense to > improve a part of the system that prepares an SQL query result set in a such > a way: > - result set should consist of wrappers objects that incorporate off heap > pointers to fields and values stored off heap; > - during the time the result set is being sent over the wire we shouldn't > move fields and values from off heap to Java heap but rather implement a > solution that will allow us to pass an off heap pointer to a sockets output > stream. Probably this can be done by leveraging Java's DirectBuffers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3870) Keeping SQL query result set in off heap tier
[ https://issues.apache.org/jira/browse/IGNITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-3870: -- Assignee: Sergi Vladykin (was: Dmitriy Setrakyan) > Keeping SQL query result set in off heap tier > - > > Key: IGNITE-3870 > URL: https://issues.apache.org/jira/browse/IGNITE-3870 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Sergi Vladykin > > With the new off heap storage architectures (IGNITE-3477) it makes sense to > improve a part of the system that prepares an SQL query result set in a such > a way: > - result set should consist of wrappers objects that incorporate off heap > pointers to fields and values stored off heap; > - during the time the result set is being sent over the wire we shouldn't > move fields and values from off heap to Java heap but rather implement a > solution that will allow us to pass an off heap pointer to a sockets output > stream. Probably this can be done by leveraging Java's DirectBuffers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3870) Keeping SQL query result set in off heap tire
[ https://issues.apache.org/jira/browse/IGNITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan reassigned IGNITE-3870: - Assignee: Dmitriy Setrakyan (was: Sergi Vladykin) > Keeping SQL query result set in off heap tire > - > > Key: IGNITE-3870 > URL: https://issues.apache.org/jira/browse/IGNITE-3870 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Dmitriy Setrakyan > > With the new off heap storage architectures (IGNITE-3477) it makes sense to > improve a part of the system that prepares an SQL query result set in a such > a way: > - result set should consist of wrappers objects that incorporate off heap > pointers to fields and values stored off heap; > - during the time the result set is being sent over the wire we shouldn't > move fields and values from off heap to Java heap but rather implement a > solution that will allow us to pass an off heap pointer to a sockets output > stream. Probably this can be done by leveraging Java's DirectBuffers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3867) ScanQuery ignores pageSize propertry
[
https://issues.apache.org/jira/browse/IGNITE-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Tikhonov updated IGNITE-3867:
-
Description:
See
{{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
IgniteClosure, ClusterGroup)}} method.
In this place we loose page size which set by user and use default value:
{{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(),
isKeepBinary)}}
was:
See
{{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
IgniteClosure, ClusterGroup)}} method.
In this place we loose page size which set by user and use default value
{{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(),
isKeepBinary)}}
> ScanQuery ignores pageSize propertry
>
>
> Key: IGNITE-3867
> URL: https://issues.apache.org/jira/browse/IGNITE-3867
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>
> See
> {{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
> IgniteClosure, ClusterGroup)}} method.
> In this place we loose page size which set by user and use default value:
> {{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(),
> isKeepBinary)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3867) ScanQuery ignores pageSize propertry
[
https://issues.apache.org/jira/browse/IGNITE-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Tikhonov updated IGNITE-3867:
-
Description:
See
{{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
IgniteClosure, ClusterGroup)}} method.
In this place we loose page size which set by user and use default value
{{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(),
isKeepBinary)}}
was:
See
{{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
IgniteClosure, ClusterGroup)}} method. In this place we loose page size
which set by user and use default value
{{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(),
isKeepBinary)}}
> ScanQuery ignores pageSize propertry
>
>
> Key: IGNITE-3867
> URL: https://issues.apache.org/jira/browse/IGNITE-3867
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>
> See
> {{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
> IgniteClosure, ClusterGroup)}} method.
> In this place we loose page size which set by user and use default value
> {{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(),
> isKeepBinary)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3869) Reduce number of temporal objects produced by H2
[ https://issues.apache.org/jira/browse/IGNITE-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3869: Fix Version/s: (was: 2.2) 2.1 > Reduce number of temporal objects produced by H2 > > > Key: IGNITE-3869 > URL: https://issues.apache.org/jira/browse/IGNITE-3869 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.4 >Reporter: Denis Magda >Assignee: Sergi Vladykin > Fix For: 2.1 > > > Presently during the execution of a query H2 generates significant number of > temporal objects (kind of wrappers) that eventually exhaust the heap and > trigger long GC pauses. > Need to revisit present implementation improving Ignite SQL engine and/or H2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3869) Reduce number of temporal objects produced by H2
[ https://issues.apache.org/jira/browse/IGNITE-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3869: Fix Version/s: (was: 2.1) 2.2 > Reduce number of temporal objects produced by H2 > > > Key: IGNITE-3869 > URL: https://issues.apache.org/jira/browse/IGNITE-3869 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.4 >Reporter: Denis Magda >Assignee: Sergi Vladykin > Fix For: 2.1 > > > Presently during the execution of a query H2 generates significant number of > temporal objects (kind of wrappers) that eventually exhaust the heap and > trigger long GC pauses. > Need to revisit present implementation improving Ignite SQL engine and/or H2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3870) Keeping SQL query result set in off heap tire
[ https://issues.apache.org/jira/browse/IGNITE-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474513#comment-15474513 ] Denis Magda commented on IGNITE-3870: - [~sergi.vladykin], please provide your thoughts and expand/modify the description if needed. > Keeping SQL query result set in off heap tire > - > > Key: IGNITE-3870 > URL: https://issues.apache.org/jira/browse/IGNITE-3870 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Sergi Vladykin > > With the new off heap storage architectures (IGNITE-3477) it makes sense to > improve a part of the system that prepares an SQL query result set in a such > a way: > - result set should consist of wrappers objects that incorporate off heap > pointers to fields and values stored off heap; > - during the time the result set is being sent over the wire we shouldn't > move fields and values from off heap to Java heap but rather implement a > solution that will allow us to pass an off heap pointer to a sockets output > stream. Probably this can be done by leveraging Java's DirectBuffers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3870) Keeping SQL query result set in off heap tire
Denis Magda created IGNITE-3870: --- Summary: Keeping SQL query result set in off heap tire Key: IGNITE-3870 URL: https://issues.apache.org/jira/browse/IGNITE-3870 Project: Ignite Issue Type: Task Reporter: Denis Magda Assignee: Sergi Vladykin With the new off heap storage architectures (IGNITE-3477) it makes sense to improve a part of the system that prepares an SQL query result set in a such a way: - result set should consist of wrappers objects that incorporate off heap pointers to fields and values stored off heap; - during the time the result set is being sent over the wire we shouldn't move fields and values from off heap to Java heap but rather implement a solution that will allow us to pass an off heap pointer to a sockets output stream. Probably this can be done by leveraging Java's DirectBuffers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3869) Reduce number of temporal objects produced by H2
[ https://issues.apache.org/jira/browse/IGNITE-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474510#comment-15474510 ] Denis Magda commented on IGNITE-3869: - [~sergi.vladykin], please provide your thoughts and expand/modify the description if needed. > Reduce number of temporal objects produced by H2 > > > Key: IGNITE-3869 > URL: https://issues.apache.org/jira/browse/IGNITE-3869 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.4 >Reporter: Denis Magda >Assignee: Sergi Vladykin > Fix For: 2.1 > > > Presently during the execution of a query H2 generates significant number of > temporal objects (kind of wrappers) that eventually exhaust the heap and > trigger long GC pauses. > Need to revisit present implementation improving Ignite SQL engine and/or H2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3869) Reduce number of temporal objects produced by H2
[ https://issues.apache.org/jira/browse/IGNITE-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3869: Description: Presently during the execution of a query H2 generates significant number of temporal objects (kind of wrappers) that eventually exhaust the heap and trigger long GC pauses. Need to revisit present implementation improving Ignite SQL engine and/or H2. was: Presently during the execution of a query H2 generates huge number of temporal objects (kind of wrappers) that eventually exhaust the heap and trigger long GC pauses. Need to revisit present implementation improving Ignite SQL engine and/or H2. > Reduce number of temporal objects produced by H2 > > > Key: IGNITE-3869 > URL: https://issues.apache.org/jira/browse/IGNITE-3869 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.4 >Reporter: Denis Magda >Assignee: Sergi Vladykin > Fix For: 2.1 > > > Presently during the execution of a query H2 generates significant number of > temporal objects (kind of wrappers) that eventually exhaust the heap and > trigger long GC pauses. > Need to revisit present implementation improving Ignite SQL engine and/or H2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3869) Reduce number of temporal objects produced by H2
Denis Magda created IGNITE-3869: --- Summary: Reduce number of temporal objects produced by H2 Key: IGNITE-3869 URL: https://issues.apache.org/jira/browse/IGNITE-3869 Project: Ignite Issue Type: Task Components: cache Affects Versions: 1.4 Reporter: Denis Magda Assignee: Sergi Vladykin Fix For: 2.1 Presently during the execution of a query H2 generates huge number of temporal objects (kind of wrappers) that eventually exhaust the heap and trigger long GC pauses. Need to revisit present implementation improving Ignite SQL engine and/or H2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3868) ODBC: DNS support for Windows works incorrectly
[
https://issues.apache.org/jira/browse/IGNITE-3868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasilisa Sidorova updated IGNITE-3868:
---
Description:
-
DESCRIPTION
-
Some keys aren't registered in the registry during odbc driver installation and
during DSN user data source adding:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite
DSN\{port,protocol_version}
-
STEPS FOR REPRODUCE
-
# Build and install odbc driver according to instruction from product binaries
# Go to Control Panel\System and Security\Administrative Tools\ODBC Data Source
Administrator (or run "odbcad32" command)
# Try to add Apache Ignite DSN source
-
ACTUAL RESULT
-
Error message appear. Source isn't adding. There isn't
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup key in the
registry
-
EXPECTED RESULT
-
Source is installed without any exception
-
NEXT STEPS FOR REPRODUCE
-
# Add HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache
Ignite\Setup=[path_to_ignite_odbc_driver] into registry
# Add Apache Ignite DSN source in the ODBC Data Source Administrator
# Start some cache
# Run Tableau
# Try to connect to the cache using DSN
-
ACTUAL RESULT
-
Connection error message appears. There aren't
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite
DSN\{port,protocol_version} keys in the registry
-
EXPECTED RESULT
-
Connection is successful
-
ADDITIONAL INFO
-
Keys HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite
DSN\{port,protocol_version} are registered in the registry after user run
"Configure" command (without any changes) for Apache Ignite DSN source
was:
-
DESCRIPTION
-
Some keys aren't registered in the registry during odbc driver installation and
during DSN user data source adding:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite
DSN\{port,protocol_version}
-
STEPS FOR REPRODUCE
-
# Build and install odbc driver according to instruction from product binaries
# Go to Control Panel\System and Security\Administrative Tools\ODBC Data Source
Administrator (or run "odbcad32" command)
# Try to add Apache Ignite DSN source
-
ACTUAL RESULT
-
Error message appear. Source isn't adding. There isn't
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup key in the
registry
-
EXPECTED RESULT
-
Source is installed without any exception
-
NEXT STEPS FOR REPRODUCE
-
# Add HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache
Ignite\Setup=[path_to_ignite_odbc_driver] into registry
# Add Apache Ignite DSN source in the ODBC Data Source Administrator
# Start some cache
# Run Tableau
# Try to connect to the cache using DSN
-
ACTUAL RESULT
-
Connection error message appear. There aren't
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite
DSN\{port,protocol_version} keys in the registry
-
EXPECTED RESULT
-
Connection is successful
-
ADDITIONAL INFO
-
Keys HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite
DSN\{port,protocol_version} are registered in the registry after user run
"Configure" command (without any changes) for Apache Ignite DSN source
> ODBC: DNS support for Windows works incorrectly
> ---
>
> Key: IGNITE-3868
> URL: https://issues.apache.org/jira/browse/IGNITE-3868
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 1.6
> Environment: Win 8, Apa
[jira] [Created] (IGNITE-3868) ODBC: DNS support for Windows works incorrectly
Vasilisa Sidorova created IGNITE-3868:
--
Summary: ODBC: DNS support for Windows works incorrectly
Key: IGNITE-3868
URL: https://issues.apache.org/jira/browse/IGNITE-3868
Project: Ignite
Issue Type: Bug
Components: odbc
Affects Versions: 1.6
Environment: Win 8, Apache Ignite 1.6.7
Reporter: Vasilisa Sidorova
-
DESCRIPTION
-
Some keys aren't registered in the registry during odbc driver installation and
during DSN user data source adding:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite
DSN\{port,protocol_version}
-
STEPS FOR REPRODUCE
-
# Build and install odbc driver according to instruction from product binaries
# Go to Control Panel\System and Security\Administrative Tools\ODBC Data Source
Administrator (or run "odbcad32" command)
# Try to add Apache Ignite DSN source
-
ACTUAL RESULT
-
Error message appear. Source isn't adding. There isn't
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup key in the
registry
-
EXPECTED RESULT
-
Source is installed without any exception
-
NEXT STEPS FOR REPRODUCE
-
# Add HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache
Ignite\Setup=[path_to_ignite_odbc_driver] into registry
# Add Apache Ignite DSN source in the ODBC Data Source Administrator
# Start some cache
# Run Tableau
# Try to connect to the cache using DSN
-
ACTUAL RESULT
-
Connection error message appear. There aren't
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite
DSN\{port,protocol_version} keys in the registry
-
EXPECTED RESULT
-
Connection is successful
-
ADDITIONAL INFO
-
Keys HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite
DSN\{port,protocol_version} are registered in the registry after user run
"Configure" command (without any changes) for Apache Ignite DSN source
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3867) ScanQuery ignores pageSize propertry
[
https://issues.apache.org/jira/browse/IGNITE-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Tikhonov updated IGNITE-3867:
-
Summary: ScanQuery ignores pageSize propertry (was: ScanQuery ignore
pageSize propertry)
> ScanQuery ignores pageSize propertry
>
>
> Key: IGNITE-3867
> URL: https://issues.apache.org/jira/browse/IGNITE-3867
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>
> See
> {{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
> IgniteClosure, ClusterGroup)}} method. In this place we loose page size
> which set by user and use default value
> {{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(),
> isKeepBinary)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3867) ScanQuery ignore pageSize propertry
Nikolay Tikhonov created IGNITE-3867:
Summary: ScanQuery ignore pageSize propertry
Key: IGNITE-3867
URL: https://issues.apache.org/jira/browse/IGNITE-3867
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.7
Reporter: Nikolay Tikhonov
See
{{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
IgniteClosure, ClusterGroup)}} method. In this place we loose page size
which set by user and use default value
{{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(),
isKeepBinary)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3665) Update KafkaStreamer dependencies
[ https://issues.apache.org/jira/browse/IGNITE-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474345#comment-15474345 ] Saikat Maitra commented on IGNITE-3665: --- [~roman_s] Hi Roman I have reviewed the changes and wanted to discuss on the following. 1. Is CONFIG_DEF is required ? It is not used in the implementation. 2. Kafka 0.10.0.1 do not require bundle and client.bundle version? Regards Saikat > Update KafkaStreamer dependencies > - > > Key: IGNITE-3665 > URL: https://issues.apache.org/jira/browse/IGNITE-3665 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Fix For: 1.8 > > > Update for Kafka 0.10 > https://archive.apache.org/dist/kafka/0.10.0.0/RELEASE_NOTES.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3729) Web Console: Rework form layout
[ https://issues.apache.org/jira/browse/IGNITE-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin resolved IGNITE-3729. -- Resolution: Fixed Assignee: Alexey Kuznetsov (was: Dmitriy Shabalin) > Web Console: Rework form layout > --- > > Key: IGNITE-3729 > URL: https://issues.apache.org/jira/browse/IGNITE-3729 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Maxim Afanasiev >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 1.8 > > > Need to rework form layout. Abandon the use of col-xx classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3729) Web Console: Rework form layout
[ https://issues.apache.org/jira/browse/IGNITE-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-3729: Assignee: Dmitriy Shabalin > Web Console: Rework form layout > --- > > Key: IGNITE-3729 > URL: https://issues.apache.org/jira/browse/IGNITE-3729 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Maxim Afanasiev >Assignee: Dmitriy Shabalin >Priority: Minor > Fix For: 1.8 > > > Need to rework form layout. Abandon the use of col-xx classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3579) Message type should be short.
[
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandresh Pancholi reassigned IGNITE-3579:
--
Assignee: Chandresh Pancholi
> Message type should be short.
> -
>
> Key: IGNITE-3579
> URL: https://issues.apache.org/jira/browse/IGNITE-3579
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Chandresh Pancholi
>Priority: Critical
> Labels: important
> Fix For: 2.0
>
>
> Currently we encode internal messages with {{byte}}. It turns out that we
> almost exhausted possible IDs.
> We should change {{byte}} to {{short}} for message ID.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3579) Message type should be short.
[
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474017#comment-15474017
]
Chandresh Pancholi edited comment on IGNITE-3579 at 9/8/16 2:34 PM:
[~vozerov] Please provide starting point for this task so that i can pick it up
ASAP.
was (Author: chandresh pancholi):
Please provide starting point for this task so that i can pick it up ASAP.
> Message type should be short.
> -
>
> Key: IGNITE-3579
> URL: https://issues.apache.org/jira/browse/IGNITE-3579
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Chandresh Pancholi
>Priority: Critical
> Labels: important
> Fix For: 2.0
>
>
> Currently we encode internal messages with {{byte}}. It turns out that we
> almost exhausted possible IDs.
> We should change {{byte}} to {{short}} for message ID.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3579) Message type should be short.
[
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474017#comment-15474017
]
Chandresh Pancholi commented on IGNITE-3579:
Please provide starting point for this task so that i can pick it up ASAP.
> Message type should be short.
> -
>
> Key: IGNITE-3579
> URL: https://issues.apache.org/jira/browse/IGNITE-3579
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Critical
> Labels: important
> Fix For: 2.0
>
>
> Currently we encode internal messages with {{byte}}. It turns out that we
> almost exhausted possible IDs.
> We should change {{byte}} to {{short}} for message ID.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-949) Add Python API for Ignite RDD
[ https://issues.apache.org/jira/browse/IGNITE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandresh Pancholi updated IGNITE-949: -- Assignee: (was: Chandresh Pancholi) > Add Python API for Ignite RDD > - > > Key: IGNITE-949 > URL: https://issues.apache.org/jira/browse/IGNITE-949 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Alexey Goncharuk > > Should be close to the Java version: > https://apacheignite.readme.io/docs/ignitecontext--igniterdd -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2377) Docker image hangs on Mac OS
[ https://issues.apache.org/jira/browse/IGNITE-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473987#comment-15473987 ] Chandresh Pancholi edited comment on IGNITE-2377 at 9/8/16 2:23 PM: I have tested with Ignite latest master (1.7.1) and docker Version 1.12.0-a (build: 11213) and it works fine and its not hanging anywhere. I followed steps given on ignite docker page and in description of stackoverflow question. 1. sudo docker pull apacheignite/ignite-docker 2.docker run --expose=4700-4800 -it -p 47500-47600:47500-47600 -p 47100-47200:47100-47200 --net=host -e "CONFIG_URI=https://raw.githubusercontent.com/apache/ignite/master/examples/config/example-default.xml"; apacheignite/ignite-docker Log output inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.Examples/Properties/AssemblyInfo.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.Examples/Services/IMapService.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.Examples/Services/ServicesExample.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Apache.Ignite.ExamplesDll.csproj inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Apache.Ignite.ExamplesDll.snk inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/Account.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/Address.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/Employee.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/EmployeeKey.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/Organization.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/OrganizationType.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Compute/AverageSalaryJob.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Compute/AverageSalaryTask.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Compute/CharacterCountClosure.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Compute/CharacterCountReducer.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Datagrid/ContinuousQueryFilter.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Datagrid/EmployeeStore.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Datagrid/EmployeeStoreFactory.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Datagrid/EmployeeStorePredicate.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Events/LocalListener.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Messaging/LocalListener.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Messaging/RemoteOrderedListener.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Messaging/RemoteUnorderedListener.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Messaging/Topic.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Properties/AssemblyInfo.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Services/MapService.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/README.txt inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/licenses/apache-2.0.txt ignite/gridgain-professional-fabric-1.7.1/bin/ignite.sh, WARN: Failed to resolve JMX host (JMX will be disabled): moby [14:10:38]__ [14:10:38] / _/ ___/ |/ / _/_ __/ __/ [14:10:38] _/ // (7 7// / / / / _/ [14:10:38] /___/\___/_/|_
[jira] [Assigned] (IGNITE-2377) Docker image hangs on Mac OS
[
https://issues.apache.org/jira/browse/IGNITE-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandresh Pancholi reassigned IGNITE-2377:
--
Assignee: Chandresh Pancholi
> Docker image hangs on Mac OS
>
>
> Key: IGNITE-2377
> URL: https://issues.apache.org/jira/browse/IGNITE-2377
> Project: Ignite
> Issue Type: Wish
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Chandresh Pancholi
> Labels: newbie
> Fix For: 1.8
>
>
> Docker hangs at the point when {{CommandLineRandomNumberGenerator}} is being
> executed. The reason is that the current and previous Docker version has some
> bug that can be overcame if to put {{System.exit(0)}} at the end of
> {{main(...)}} function.
> More investigation details and steps to reproduce can be found here:
> http://stackoverflow.com/questions/34661934/ignite-running-in-docker-is-general-java-docker-issue
> It makes sense to add {{System.exit(0)}} to all our classes that are executed
> by {{ignite.bat}} or {{ignite.sh}} because it's not harmful in any case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2377) Docker image hangs on Mac OS
[ https://issues.apache.org/jira/browse/IGNITE-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473987#comment-15473987 ] Chandresh Pancholi commented on IGNITE-2377: I have tested with Ignite latest master (1.8) and docker Version 1.12.0-a (build: 11213) and it works fine and its not hanging anywhere. I followed steps given on ignite docker page and in description of stackoverflow question. 1. sudo docker pull apacheignite/ignite-docker 2.docker run --expose=4700-4800 -it -p 47500-47600:47500-47600 -p 47100-47200:47100-47200 --net=host -e "CONFIG_URI=https://raw.githubusercontent.com/apache/ignite/master/examples/config/example-default.xml"; apacheignite/ignite-docker Log output inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.Examples/Properties/AssemblyInfo.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.Examples/Services/IMapService.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.Examples/Services/ServicesExample.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Apache.Ignite.ExamplesDll.csproj inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Apache.Ignite.ExamplesDll.snk inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/Account.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/Address.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/Employee.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/EmployeeKey.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/Organization.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Binary/OrganizationType.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Compute/AverageSalaryJob.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Compute/AverageSalaryTask.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Compute/CharacterCountClosure.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Compute/CharacterCountReducer.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Datagrid/ContinuousQueryFilter.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Datagrid/EmployeeStore.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Datagrid/EmployeeStoreFactory.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Datagrid/EmployeeStorePredicate.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Events/LocalListener.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Messaging/LocalListener.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Messaging/RemoteOrderedListener.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Messaging/RemoteUnorderedListener.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Messaging/Topic.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Properties/AssemblyInfo.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Services/MapService.cs inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/examples/README.txt inflating: ignite/gridgain-professional-fabric-1.7.1/platforms/dotnet/licenses/apache-2.0.txt ignite/gridgain-professional-fabric-1.7.1/bin/ignite.sh, WARN: Failed to resolve JMX host (JMX will be disabled): moby [14:10:38]__ [14:10:38] / _/ ___/ |/ / _/_ __/ __/ [14:10:38] _/ // (7 7// / / / / _/ [14:10:38] /___/\___/_/|_/___/ /_/ /___/ [14:10:38] [14:10:38] ver. 1.7
[jira] [Commented] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send
[ https://issues.apache.org/jira/browse/IGNITE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473946#comment-15473946 ] Semen Boikov commented on IGNITE-3727: -- Also need add test to check that 'IgniteMessageing.sendOrdered' contract is not broken in async mode. > Support local listeners async execution for IgniteMessage.send > -- > > Key: IGNITE-3727 > URL: https://issues.apache.org/jira/browse/IGNITE-3727 > Project: Ignite > Issue Type: Task > Components: messaging >Affects Versions: 1.7 > Environment: windows 7 >Reporter: Yujue Li >Assignee: Dmitriy Govorukhin > Fix For: 1.8 > > > ignite.message() method not support async mode,withAsync() is invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2396) Dynamic cache changes are not tracked by service processor
[ https://issues.apache.org/jira/browse/IGNITE-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-2396: --- Assignee: Dmitriy Govorukhin (was: Alexey Goncharuk) > Dynamic cache changes are not tracked by service processor > -- > > Key: IGNITE-2396 > URL: https://issues.apache.org/jira/browse/IGNITE-2396 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Dmitriy Govorukhin > Labels: community > Fix For: 1.8 > > > Currently service processor handles only discovery node join/leave/fail > events. Now consider the following two scenarios: > - > - N nodes are started. Topology version is (N, 0) > - A dynamic cache is created. Topology version is (N, 1) > - An affinity singleton service is deployed. > On step (3), when assignment is calculated, service processor uses topology > version (N, 0) (see > org.apache.ignite.internal.processors.service.GridServiceProcessor.DeploymentListener#onDeployment). > As a result, no affinity nodes are returned for assignment and service is > not deployed. > - > - N nodes are started. Topology version is (N, 0) > - An affinity singleton service is deployed. > - A dynamic cache is created. Topology version is (N, 1) > On step (3) custom discovery event is generated, but it is not handled by > service processor, so no reassignment logic is triggered and service is not > deployed. > Proposed solution is as follows: > - Use a correct topology version for service deployment > (ctx.discovery().topologyVersionEx()). > - Event listener should handle custom events that trigger dynamic cache > start and stop. > - Additionally need to investigate whether reassignment logic should be in > any way synchronized with the partition exchange future completion. > org.apache.ignite.internal.processors.service.IgniteServiceDynamicCachesSelfTest > is added to master. Need to add it to the services test suite once the fix > is implemented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance
[
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-1678:
---
Assignee: Semen Boikov (was: Dmitriy Govorukhin)
> IgniteAtomicSequence: make following reservations in advance
>
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Semen Boikov
> Fix For: 1.8
>
>
> In current implementation a new reservation is made when the current local
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there
> can be a situation when all the nodes start doing a new reservation at the
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence
> slot in advance (in background), like when around 80% of current reservation
> has already been used. Probably we should add a special parameter to
> {{AtomicConfiguration}} that will manage such behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2539) NPE at RendezvousAffinityFunction
[ https://issues.apache.org/jira/browse/IGNITE-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-2539: --- Assignee: Semen Boikov (was: Dmitriy Govorukhin) > NPE at RendezvousAffinityFunction > - > > Key: IGNITE-2539 > URL: https://issues.apache.org/jira/browse/IGNITE-2539 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ershov >Assignee: Semen Boikov >Priority: Critical > Fix For: 1.8 > > Attachments: ignite.log > > Original Estimate: 4h > Remaining Estimate: 4h > > RendezvousAffinityFunction#assignPartition throws NPE, probably due to > simultaneous topology change and cache stop. We should write a test and fix > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send
[ https://issues.apache.org/jira/browse/IGNITE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-3727: --- Assignee: Semen Boikov (was: Dmitriy Govorukhin) > Support local listeners async execution for IgniteMessage.send > -- > > Key: IGNITE-3727 > URL: https://issues.apache.org/jira/browse/IGNITE-3727 > Project: Ignite > Issue Type: Task > Components: messaging >Affects Versions: 1.7 > Environment: windows 7 >Reporter: Yujue Li >Assignee: Semen Boikov > Fix For: 1.8 > > > ignite.message() method not support async mode,withAsync() is invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2539) NPE at RendezvousAffinityFunction
[ https://issues.apache.org/jira/browse/IGNITE-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473829#comment-15473829 ] Dmitriy Govorukhin commented on IGNITE-2539: Added test for reproduce, it occurs only in certain situations, so you can not get fail test straight. > NPE at RendezvousAffinityFunction > - > > Key: IGNITE-2539 > URL: https://issues.apache.org/jira/browse/IGNITE-2539 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ershov >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 1.8 > > Attachments: ignite.log > > Original Estimate: 4h > Remaining Estimate: 4h > > RendezvousAffinityFunction#assignPartition throws NPE, probably due to > simultaneous topology change and cache stop. We should write a test and fix > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send
[ https://issues.apache.org/jira/browse/IGNITE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473821#comment-15473821 ] Dmitriy Govorukhin commented on IGNITE-3727: [~sboikov] Please look my fix. > Support local listeners async execution for IgniteMessage.send > -- > > Key: IGNITE-3727 > URL: https://issues.apache.org/jira/browse/IGNITE-3727 > Project: Ignite > Issue Type: Task > Components: messaging >Affects Versions: 1.7 > Environment: windows 7 >Reporter: Yujue Li >Assignee: Dmitriy Govorukhin > Fix For: 1.8 > > > ignite.message() method not support async mode,withAsync() is invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send
[ https://issues.apache.org/jira/browse/IGNITE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473817#comment-15473817 ] Dmitriy Govorukhin edited comment on IGNITE-3727 at 9/8/16 1:06 PM: [~liyuj] i found problem. The issues with GridIoManager, he worked not through thread pool. was (Author: dmitriygovorukhin): [~liyuj] i find problem. The issues with GridIoManager, he worked not through thread pool. > Support local listeners async execution for IgniteMessage.send > -- > > Key: IGNITE-3727 > URL: https://issues.apache.org/jira/browse/IGNITE-3727 > Project: Ignite > Issue Type: Task > Components: messaging >Affects Versions: 1.7 > Environment: windows 7 >Reporter: Yujue Li >Assignee: Dmitriy Govorukhin > Fix For: 1.8 > > > ignite.message() method not support async mode,withAsync() is invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send
[ https://issues.apache.org/jira/browse/IGNITE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473817#comment-15473817 ] Dmitriy Govorukhin commented on IGNITE-3727: [~liyuj] i find problem. The issues with GridIoManager, he worked not through thread pool. > Support local listeners async execution for IgniteMessage.send > -- > > Key: IGNITE-3727 > URL: https://issues.apache.org/jira/browse/IGNITE-3727 > Project: Ignite > Issue Type: Task > Components: messaging >Affects Versions: 1.7 > Environment: windows 7 >Reporter: Yujue Li >Assignee: Dmitriy Govorukhin > Fix For: 1.8 > > > ignite.message() method not support async mode,withAsync() is invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance
[
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473807#comment-15473807
]
Dmitriy Govorukhin edited comment on IGNITE-1678 at 9/8/16 1:01 PM:
[~sboikov] I commit the changes, added small fixes, please look it.
was (Author: dmitriygovorukhin):
[~sboikov]] I commit the changes, added small fixes, please look it.
> IgniteAtomicSequence: make following reservations in advance
>
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
> Fix For: 1.8
>
>
> In current implementation a new reservation is made when the current local
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there
> can be a situation when all the nodes start doing a new reservation at the
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence
> slot in advance (in background), like when around 80% of current reservation
> has already been used. Probably we should add a special parameter to
> {{AtomicConfiguration}} that will manage such behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance
[
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473807#comment-15473807
]
Dmitriy Govorukhin commented on IGNITE-1678:
[~sboikov]] I commit the changes, added small fixes, please look it.
> IgniteAtomicSequence: make following reservations in advance
>
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
> Fix For: 1.8
>
>
> In current implementation a new reservation is made when the current local
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there
> can be a situation when all the nodes start doing a new reservation at the
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence
> slot in advance (in background), like when around 80% of current reservation
> has already been used. Probably we should add a special parameter to
> {{AtomicConfiguration}} that will manage such behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3855) IGFS: Support direct PROXY mode invocation in method: delete
[ https://issues.apache.org/jira/browse/IGNITE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3855: Affects Version/s: 1.7 > IGFS: Support direct PROXY mode invocation in method: delete > > > Key: IGNITE-3855 > URL: https://issues.apache.org/jira/browse/IGNITE-3855 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.7 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3856) IGFS: Support direct PROXY mode invocation in method: mkdirs
[ https://issues.apache.org/jira/browse/IGNITE-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3856: Fix Version/s: 1.8 > IGFS: Support direct PROXY mode invocation in method: mkdirs > > > Key: IGNITE-3856 > URL: https://issues.apache.org/jira/browse/IGNITE-3856 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.7 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3855) IGFS: Support direct PROXY mode invocation in method: delete
[ https://issues.apache.org/jira/browse/IGNITE-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3855: Fix Version/s: 1.8 > IGFS: Support direct PROXY mode invocation in method: delete > > > Key: IGNITE-3855 > URL: https://issues.apache.org/jira/browse/IGNITE-3855 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.7 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3857) IGFS: Support direct PROXY mode invocation in methods: listPaths / listFiles
[ https://issues.apache.org/jira/browse/IGNITE-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3857: Fix Version/s: 1.8 > IGFS: Support direct PROXY mode invocation in methods: listPaths / listFiles > > > Key: IGNITE-3857 > URL: https://issues.apache.org/jira/browse/IGNITE-3857 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.7 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3857) IGFS: Support direct PROXY mode invocation in methods: listPaths / listFiles
[ https://issues.apache.org/jira/browse/IGNITE-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3857: Affects Version/s: 1.7 > IGFS: Support direct PROXY mode invocation in methods: listPaths / listFiles > > > Key: IGNITE-3857 > URL: https://issues.apache.org/jira/browse/IGNITE-3857 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.7 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3856) IGFS: Support direct PROXY mode invocation in method: mkdirs
[ https://issues.apache.org/jira/browse/IGNITE-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3856: Affects Version/s: 1.7 > IGFS: Support direct PROXY mode invocation in method: mkdirs > > > Key: IGNITE-3856 > URL: https://issues.apache.org/jira/browse/IGNITE-3856 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.7 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3199) .NET: ASP.NET Session-State Store Provider
[ https://issues.apache.org/jira/browse/IGNITE-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473345#comment-15473345 ] Pavel Tupitsyn edited comment on IGNITE-3199 at 9/8/16 12:03 PM: - 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. 3) Good point, done. 4) Done. 5) This is according to the docs (see MSDN link above). 6) Done. 7) There are only 2 duplicated lines. Logic is very different, returned result is different. Merging these two will be a mess. Let's keep concerns separated. 8) Fixed. 9) I've extracted this logic to a separate class, but I'm not sure how do you want to inject it to PlatformCache. I mean, where do we inject it from? PlatformProcessor creates PlatformCache, but why should it know about these processors? 10) Fixed. was (Author: ptupitsyn): 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. 3) Good point, done. 4) Done. 5) This is according to the docs (see MSDN link above). 6) Done. 7) There are only 2 duplicated lines. Logic is very different, returned result is different. Merging these two will be a mess. Let's keep concerns separated. 8) Fixed. > .NET: ASP.NET Session-State Store Provider > -- > > Key: IGNITE-3199 > URL: https://issues.apache.org/jira/browse/IGNITE-3199 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net > Fix For: 1.8 > > > See https://msdn.microsoft.com/en-us/library/ms178587.aspx > Code should be put to Apache.Ignite.AspNet assembly (see IGNITE-2379) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Deleted] (IGNITE-3866) test
[ https://issues.apache.org/jira/browse/IGNITE-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov deleted IGNITE-3866: - > test > > > Key: IGNITE-3866 > URL: https://issues.apache.org/jira/browse/IGNITE-3866 > Project: Ignite > Issue Type: Bug >Reporter: Denis Kholodov > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3866) test
[ https://issues.apache.org/jira/browse/IGNITE-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3866: - > test > > > Key: IGNITE-3866 > URL: https://issues.apache.org/jira/browse/IGNITE-3866 > Project: Ignite > Issue Type: Bug >Reporter: Denis Kholodov > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3866) Junior Engineer
Semen Boikov created IGNITE-3866: Summary: Junior Engineer Key: IGNITE-3866 URL: https://issues.apache.org/jira/browse/IGNITE-3866 Project: Ignite Issue Type: Bug Reporter: Denis Kholodov -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3199) .NET: ASP.NET Session-State Store Provider
[ https://issues.apache.org/jira/browse/IGNITE-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473345#comment-15473345 ] Pavel Tupitsyn edited comment on IGNITE-3199 at 9/8/16 11:22 AM: - 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. 3) Good point, done. 4) Done. 5) This is according to the docs (see MSDN link above). 6) Done. 7) There are only 2 duplicated lines. Logic is very different, returned result is different. Merging these two will be a mess. Let's keep concerns separated. 8) Fixed. was (Author: ptupitsyn): 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. 3) Good point, done. 4) Done 5) This is according to the docs (see MSDN link above). 6) Done. 7) There are only 2 duplicated lines. Logic is very different, returned result is different. Merging these two will be a mess. Let's keep concerns separated. > .NET: ASP.NET Session-State Store Provider > -- > > Key: IGNITE-3199 > URL: https://issues.apache.org/jira/browse/IGNITE-3199 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net > Fix For: 1.8 > > > See https://msdn.microsoft.com/en-us/library/ms178587.aspx > Code should be put to Apache.Ignite.AspNet assembly (see IGNITE-2379) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3199) .NET: ASP.NET Session-State Store Provider
[ https://issues.apache.org/jira/browse/IGNITE-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473345#comment-15473345 ] Pavel Tupitsyn edited comment on IGNITE-3199 at 9/8/16 11:11 AM: - 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. 3) Good point, done. 4) Done 5) This is according to the docs (see MSDN link above). 6) Done. 7) There are only 2 duplicated lines. Logic is very different, returned result is different. Merging these two will be a mess. Let's keep concerns separated. was (Author: ptupitsyn): 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. 3) Good point, done. 4) Done 5) This is according to the docs (see MSDN link above). > .NET: ASP.NET Session-State Store Provider > -- > > Key: IGNITE-3199 > URL: https://issues.apache.org/jira/browse/IGNITE-3199 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net > Fix For: 1.8 > > > See https://msdn.microsoft.com/en-us/library/ms178587.aspx > Code should be put to Apache.Ignite.AspNet assembly (see IGNITE-2379) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3199) .NET: ASP.NET Session-State Store Provider
[ https://issues.apache.org/jira/browse/IGNITE-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473345#comment-15473345 ] Pavel Tupitsyn edited comment on IGNITE-3199 at 9/8/16 11:06 AM: - 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. 3) Good point, done. 4) Done 5) This is according to the docs (see MSDN link above). was (Author: ptupitsyn): 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. 3) Good point, done. > .NET: ASP.NET Session-State Store Provider > -- > > Key: IGNITE-3199 > URL: https://issues.apache.org/jira/browse/IGNITE-3199 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net > Fix For: 1.8 > > > See https://msdn.microsoft.com/en-us/library/ms178587.aspx > Code should be put to Apache.Ignite.AspNet assembly (see IGNITE-2379) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3865) ODBC: Investigate compatibility with PDO.
Igor Sapego created IGNITE-3865: --- Summary: ODBC: Investigate compatibility with PDO. Key: IGNITE-3865 URL: https://issues.apache.org/jira/browse/IGNITE-3865 Project: Ignite Issue Type: Task Components: odbc Affects Versions: 1.7 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 1.8 We should check if our ODBC implementation works with the [PDO|http://php.net/manual/en/intro.pdo.php]. This way we are going to be able be used from the PHP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3199) .NET: ASP.NET Session-State Store Provider
[ https://issues.apache.org/jira/browse/IGNITE-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473345#comment-15473345 ] Pavel Tupitsyn edited comment on IGNITE-3199 at 9/8/16 10:01 AM: - 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. 3) Good point, done. was (Author: ptupitsyn): 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. > .NET: ASP.NET Session-State Store Provider > -- > > Key: IGNITE-3199 > URL: https://issues.apache.org/jira/browse/IGNITE-3199 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net > Fix For: 1.8 > > > See https://msdn.microsoft.com/en-us/library/ms178587.aspx > Code should be put to Apache.Ignite.AspNet assembly (see IGNITE-2379) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3199) .NET: ASP.NET Session-State Store Provider
[ https://issues.apache.org/jira/browse/IGNITE-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473345#comment-15473345 ] Pavel Tupitsyn commented on IGNITE-3199: 1) I'm ok with LockInfo rename, but as for collection, I don't agree. This collection has nothing to do with WebSession per se. Classes should be named according to what they do, not where they are used. This collection can be used in any other scenario. 2) I've only added what is necessary. We normally don't add any platform things to BinaryContext (see filters, predicates, etc). But here we need these three classes because they are serialized from .NET, and Java won't understand them initially. > .NET: ASP.NET Session-State Store Provider > -- > > Key: IGNITE-3199 > URL: https://issues.apache.org/jira/browse/IGNITE-3199 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net > Fix For: 1.8 > > > See https://msdn.microsoft.com/en-us/library/ms178587.aspx > Code should be put to Apache.Ignite.AspNet assembly (see IGNITE-2379) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3864) Decreasing max memory of SortedEvictionPolicy during runtime
[
https://issues.apache.org/jira/browse/IGNITE-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Albrecht updated IGNITE-3864:
---
Description:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put into cache.
Tested with the following scenario (see also attached screenshot):
# Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
# Set {code}evictionPolicy.setMaxMemorySize(200){code}
# Put 1 entries into cache.
# Set {code}evictionPolicy.setMaxMemorySize(100){code}
# Put another entry into cache.
-> All cache entries are evicted -> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
In addition you can see that the CurrentMemory Size read from the
SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
decreasing the max memory size. Even after all cache entries are evicted and
the cache is complety empty
was:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
# Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
# Set {code}evictionPolicy.setMaxMemorySize(200){code}
# Put 1 entries into cache.
# Set {code}evictionPolicy.setMaxMemorySize(100){code}
# Put another entry into cache.
-> All cache entries are evicted -> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
In addition you can see that the CurrentMemory Size read from the
SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
decreasing the max memory size. Even after all cache entries are evicted and
the cache is complety empty
> Decreasing max memory of SortedEvictionPolicy during runtime
>
>
> Key: IGNITE-3864
> URL: https://issues.apache.org/jira/browse/IGNITE-3864
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: David Albrecht
> Attachments: Decrease SortedEvicitionPolicy MaxMemory.png
>
>
> Decreasing the maxMemory Size of the SortedEvicitionPolicy using
> SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an
> empty cache after another entry is put into cache.
> Tested with the following scenario (see also attached screenshot):
> # Initizalize SortedEvicitionPolicy with
> {code}SortedEvictionPolicy evictionPolicy = new
> SortedEvictionPolicy<>(500);{code}
> # Set {code}evictionPolicy.setMaxMemorySize(200){code}
> # Put 1 entries into cache.
> # Set {code}evictionPolicy.setMaxMemorySize(100){code}
> # Put another entry into cache.
> -> All cache entries are evicted -> 0 entries are in cache.
> Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
> via the mbean I would expect that decreasing the max memory size should work
> during runtime. (Increasing the max memory size works)
> In addition you can see that the CurrentMemory Size read from the
> SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
> decreasing the max memory size. Even after all cache entries are evicted and
> the cache is complety empty
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3864) Decreasing max memory of SortedEvictionPolicy during runtime
[
https://issues.apache.org/jira/browse/IGNITE-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Albrecht updated IGNITE-3864:
---
Description:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
# Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
# Set {code}evictionPolicy.setMaxMemorySize(200){code}
# Put 1 entries into cache.
# Set {code}evictionPolicy.setMaxMemorySize(100){code}
# Put another entry into cache.
-> All cache entries are evicted -> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
In addition you can see that the CurrentMemory Size read from the
SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
decreasing the max memory size. Even after all cache entries are evicted and
the cache is complety empty
was:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
# Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
# Set {code}evictionPolicy.setMaxMemorySize(200){code}
# Put 1 entries into cache.
# Set {code}evictionPolicy.setMaxMemorySize(100){code}
# Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
In addition you can see that the CurrentMemory Size read from the
SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
decreasing the max memory size. Even after all cache entries are evicted and
the cache is complety empty
> Decreasing max memory of SortedEvictionPolicy during runtime
>
>
> Key: IGNITE-3864
> URL: https://issues.apache.org/jira/browse/IGNITE-3864
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: David Albrecht
> Attachments: Decrease SortedEvicitionPolicy MaxMemory.png
>
>
> Decreasing the maxMemory Size of the SortedEvicitionPolicy using
> SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an
> empty cache after another entry is put inside.
> Tested with the following scenario (see also attached screenshot):
> # Initizalize SortedEvicitionPolicy with
> {code}SortedEvictionPolicy evictionPolicy = new
> SortedEvictionPolicy<>(500);{code}
> # Set {code}evictionPolicy.setMaxMemorySize(200){code}
> # Put 1 entries into cache.
> # Set {code}evictionPolicy.setMaxMemorySize(100){code}
> # Put another entry into cache.
> -> All cache entries are evicted -> 0 entries are in cache.
> Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
> via the mbean I would expect that decreasing the max memory size should work
> during runtime. (Increasing the max memory size works)
> In addition you can see that the CurrentMemory Size read from the
> SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
> decreasing the max memory size. Even after all cache entries are evicted and
> the cache is complety empty
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3864) Decreasing max memory of SortedEvictionPolicy during runtime
[
https://issues.apache.org/jira/browse/IGNITE-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Albrecht updated IGNITE-3864:
---
Description:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
# Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
# Set {code}evictionPolicy.setMaxMemorySize(200){code}
# Put 1 entries into cache.
# Set {code}evictionPolicy.setMaxMemorySize(100){code}
# Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
In addition you can see that the CurrentMemory Size read from the
SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
decreasing the max memory size. Even after all cache entries are evicted and
the cache is complety empty
was:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
1.
Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
2.
Set {code}evictionPolicy.setMaxMemorySize(200){code}
3.
Put 1 entries into cache.
4.
Set {code}evictionPolicy.setMaxMemorySize(100){code}
5.
Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
In addition you can see that the CurrentMemory Size read from the
SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
decreasing the max memory size. Even after all cache entries are evicted and
the cache is complety empty
> Decreasing max memory of SortedEvictionPolicy during runtime
>
>
> Key: IGNITE-3864
> URL: https://issues.apache.org/jira/browse/IGNITE-3864
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: David Albrecht
> Attachments: Decrease SortedEvicitionPolicy MaxMemory.png
>
>
> Decreasing the maxMemory Size of the SortedEvicitionPolicy using
> SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an
> empty cache after another entry is put inside.
> Tested with the following scenario (see also attached screenshot):
> # Initizalize SortedEvicitionPolicy with
> {code}SortedEvictionPolicy evictionPolicy = new
> SortedEvictionPolicy<>(500);{code}
> # Set {code}evictionPolicy.setMaxMemorySize(200){code}
> # Put 1 entries into cache.
> # Set {code}evictionPolicy.setMaxMemorySize(100){code}
> # Put another entry into cache.
> -> 0 entries are in cache.
> Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
> via the mbean I would expect that decreasing the max memory size should work
> during runtime. (Increasing the max memory size works)
> In addition you can see that the CurrentMemory Size read from the
> SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
> decreasing the max memory size. Even after all cache entries are evicted and
> the cache is complety empty
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3864) Decreasing max memory of SortedEvictionPolicy during runtime
[
https://issues.apache.org/jira/browse/IGNITE-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Albrecht updated IGNITE-3864:
---
Description:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
1.
Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
2.
Set {code}evictionPolicy.setMaxMemorySize(200){code}
3.
Put 1 entries into cache.
4.
Set {code}evictionPolicy.setMaxMemorySize(100){code}
5.
Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
In addition you can see that the CurrentMemory Size read from the
SortedEvictionPolicy mbean via {code}getCurrentMemorySize{code} doesn't change
after decreasing the max memory size. Even after all cache entries are evicted
and the cache is complety empty
was:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
1.
Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
2.
Set {code}evictionPolicy.setMaxMemorySize(200){code}
3.
Put 1 entries into cache.
4.
Set {code}evictionPolicy.setMaxMemorySize(100){code}
5.
Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
> Decreasing max memory of SortedEvictionPolicy during runtime
>
>
> Key: IGNITE-3864
> URL: https://issues.apache.org/jira/browse/IGNITE-3864
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: David Albrecht
> Attachments: Decrease SortedEvicitionPolicy MaxMemory.png
>
>
> Decreasing the maxMemory Size of the SortedEvicitionPolicy using
> SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an
> empty cache after another entry is put inside.
> Tested with the following scenario (see also attached screenshot):
> 1.
> Initizalize SortedEvicitionPolicy with
> {code}SortedEvictionPolicy evictionPolicy = new
> SortedEvictionPolicy<>(500);{code}
> 2.
> Set {code}evictionPolicy.setMaxMemorySize(200){code}
> 3.
> Put 1 entries into cache.
> 4.
> Set {code}evictionPolicy.setMaxMemorySize(100){code}
> 5.
> Put another entry into cache.
> -> 0 entries are in cache.
> Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
> via the mbean I would expect that decreasing the max memory size should work
> during runtime. (Increasing the max memory size works)
> In addition you can see that the CurrentMemory Size read from the
> SortedEvictionPolicy mbean via {code}getCurrentMemorySize{code} doesn't
> change after decreasing the max memory size. Even after all cache entries are
> evicted and the cache is complety empty
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3864) Decreasing max memory of SortedEvictionPolicy during runtime
[
https://issues.apache.org/jira/browse/IGNITE-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Albrecht updated IGNITE-3864:
---
Description:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
1.
Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
2.
Set {code}evictionPolicy.setMaxMemorySize(200){code}
3.
Put 1 entries into cache.
4.
Set {code}evictionPolicy.setMaxMemorySize(100){code}
5.
Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
In addition you can see that the CurrentMemory Size read from the
SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
decreasing the max memory size. Even after all cache entries are evicted and
the cache is complety empty
was:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
1.
Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
2.
Set {code}evictionPolicy.setMaxMemorySize(200){code}
3.
Put 1 entries into cache.
4.
Set {code}evictionPolicy.setMaxMemorySize(100){code}
5.
Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
In addition you can see that the CurrentMemory Size read from the
SortedEvictionPolicy mbean via {code}getCurrentMemorySize{code} doesn't change
after decreasing the max memory size. Even after all cache entries are evicted
and the cache is complety empty
> Decreasing max memory of SortedEvictionPolicy during runtime
>
>
> Key: IGNITE-3864
> URL: https://issues.apache.org/jira/browse/IGNITE-3864
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: David Albrecht
> Attachments: Decrease SortedEvicitionPolicy MaxMemory.png
>
>
> Decreasing the maxMemory Size of the SortedEvicitionPolicy using
> SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an
> empty cache after another entry is put inside.
> Tested with the following scenario (see also attached screenshot):
> 1.
> Initizalize SortedEvicitionPolicy with
> {code}SortedEvictionPolicy evictionPolicy = new
> SortedEvictionPolicy<>(500);{code}
> 2.
> Set {code}evictionPolicy.setMaxMemorySize(200){code}
> 3.
> Put 1 entries into cache.
> 4.
> Set {code}evictionPolicy.setMaxMemorySize(100){code}
> 5.
> Put another entry into cache.
> -> 0 entries are in cache.
> Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
> via the mbean I would expect that decreasing the max memory size should work
> during runtime. (Increasing the max memory size works)
> In addition you can see that the CurrentMemory Size read from the
> SortedEvictionPolicy mbean via getCurrentMemorySize doesn't change after
> decreasing the max memory size. Even after all cache entries are evicted and
> the cache is complety empty
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3864) Decreasing max memory of SortedEvictionPolicy during runtime
[
https://issues.apache.org/jira/browse/IGNITE-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Albrecht updated IGNITE-3864:
---
Description:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario (see also attached screenshot):
1.
Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
2.
Set {code}evictionPolicy.setMaxMemorySize(200){code}
3.
Put 1 entries into cache.
4.
Set {code}evictionPolicy.setMaxMemorySize(100){code}
5.
Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
was:
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario:
1.
Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
2.
Set {code}evictionPolicy.setMaxMemorySize(200){code}
3.
Put 1 entries into cache.
4.
Set {code}evictionPolicy.setMaxMemorySize(100){code}
5.
Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
> Decreasing max memory of SortedEvictionPolicy during runtime
>
>
> Key: IGNITE-3864
> URL: https://issues.apache.org/jira/browse/IGNITE-3864
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: David Albrecht
> Attachments: Decrease SortedEvicitionPolicy MaxMemory.png
>
>
> Decreasing the maxMemory Size of the SortedEvicitionPolicy using
> SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an
> empty cache after another entry is put inside.
> Tested with the following scenario (see also attached screenshot):
> 1.
> Initizalize SortedEvicitionPolicy with
> {code}SortedEvictionPolicy evictionPolicy = new
> SortedEvictionPolicy<>(500);{code}
> 2.
> Set {code}evictionPolicy.setMaxMemorySize(200){code}
> 3.
> Put 1 entries into cache.
> 4.
> Set {code}evictionPolicy.setMaxMemorySize(100){code}
> 5.
> Put another entry into cache.
> -> 0 entries are in cache.
> Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
> via the mbean I would expect that decreasing the max memory size should work
> during runtime. (Increasing the max memory size works)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3864) Decreasing max memory of SortedEvictionPolicy during runtime
[
https://issues.apache.org/jira/browse/IGNITE-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Albrecht updated IGNITE-3864:
---
Attachment: Decrease SortedEvicitionPolicy MaxMemory.png
> Decreasing max memory of SortedEvictionPolicy during runtime
>
>
> Key: IGNITE-3864
> URL: https://issues.apache.org/jira/browse/IGNITE-3864
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: David Albrecht
> Attachments: Decrease SortedEvicitionPolicy MaxMemory.png
>
>
> Decreasing the maxMemory Size of the SortedEvicitionPolicy using
> SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an
> empty cache after another entry is put inside.
> Tested with the following scenario:
> 1.
> Initizalize SortedEvicitionPolicy with
> {code}SortedEvictionPolicy evictionPolicy = new
> SortedEvictionPolicy<>(500);{code}
> 2.
> Set {code}evictionPolicy.setMaxMemorySize(200){code}
> 3.
> Put 1 entries into cache.
> 4.
> Set {code}evictionPolicy.setMaxMemorySize(100){code}
> 5.
> Put another entry into cache.
> -> 0 entries are in cache.
> Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
> via the mbean I would expect that decreasing the max memory size should work
> during runtime. (Increasing the max memory size works)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3864) Decreasing max memory of SortedEvictionPolicy during runtime
David Albrecht created IGNITE-3864:
--
Summary: Decreasing max memory of SortedEvictionPolicy during
runtime
Key: IGNITE-3864
URL: https://issues.apache.org/jira/browse/IGNITE-3864
Project: Ignite
Issue Type: Bug
Affects Versions: 1.7
Reporter: David Albrecht
Decreasing the maxMemory Size of the SortedEvicitionPolicy using
SortedEvicitionPolicy#setMaxMemorySize(long) during runtime results in an empty
cache after another entry is put inside.
Tested with the following scenario:
1.
Initizalize SortedEvicitionPolicy with
{code}SortedEvictionPolicy evictionPolicy = new
SortedEvictionPolicy<>(500);{code}
2.
Set {code}evictionPolicy.setMaxMemorySize(200){code}
3.
Put 1 entries into cache.
4.
Set {code}evictionPolicy.setMaxMemorySize(100){code}
5.
Put another entry into cache.
-> 0 entries are in cache.
Since the method SortedEvictionPolicy.setMaxMemorySize(long) is also exposed
via the mbean I would expect that decreasing the max memory size should work
during runtime. (Increasing the max memory size works)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
