[jira] [Commented] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[
https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17062253#comment-17062253
]
RangerZhou commented on IGNITE-12798:
-
[~Pavlukhin]
Thanks for your answer, if I comment the line code (cache.query(qyr)), there is
no exception, and I had tried start new Thread like this:
{code:java}
new Thread(() -> System.out.println("test lambda...")).start();
{code}
no exception too, so it should not be referene to lambda.
I will try your first notes, thanks again !!!
> Failed to start continuous query when use client node in IDEA
> -
>
> Key: IGNITE-12798
> URL: https://issues.apache.org/jira/browse/IGNITE-12798
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: RangerZhou
>Priority: Major
> Attachments: Exception.log, Exception01.png, Exception02.png,
> Exception03.png, TOFListener.png
>
>
> I start ignite server by ./ignite.sh, start a ignite client by java code, and
> execute a continuous query with java in IDEA, but exception like this:
> Exception in thread "main" javax.cache.CacheException: Failed to start
> continuous query.
> Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener
> But if I start server node by java code in IDEA ( Ignition.start() ), the
> continuous query is ok.
> My client code as below:
>
> !TOFListener.png!
> The exception screenshots:
> !Exception01.png!
> !Exception02.png!
> !Exception03.png!
> The exception uploaded the attachment
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7136) .NET: IndexesAllocatedPages metrics
[ https://issues.apache.org/jira/browse/IGNITE-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17062094#comment-17062094 ] Sergey Stronchinskiy commented on IGNITE-7136: -- The parent ticket is marked as "Won't fix" is this one still relevant? > .NET: IndexesAllocatedPages metrics > --- > > Key: IGNITE-7136 > URL: https://issues.apache.org/jira/browse/IGNITE-7136 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Reporter: Nikolay Izhikov >Priority: Major > Labels: .NET, iep-6 > Fix For: 2.9 > > > New JMX metric implemented in IGNITE-6903. > We need to add support for this metric to .Net -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12766) Node startup can be broken in case of using Local cache with persistence enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17062089#comment-17062089
]
Ivan Pavlukhin commented on IGNITE-12766:
-
[~slava.koptilin], generally everything looks fine. Some comments:
# I suppose we can make nested {{GridCacheProcessor.LocalAffinityFunction}}
class _private_ and throw an exception from a constructor as it should not be
instantiated by calling the constructor.
# I noticed that nested affinity function class is listed in a file
classnames.properties (I forgot why is it needed), should not we add the new
class to this file as well?
# While it does not seem critical, but quite interesting, can we define
{{readResolve}} method and replace an instance of the old nested class with an
instance of the actual one?
> Node startup can be broken in case of using Local cache with persistence
> enabled.
> -
>
> Key: IGNITE-12766
> URL: https://issues.apache.org/jira/browse/IGNITE-12766
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to upgrade from the previous version of Apache Ignite (AI 2.7.6 for
> example) may result in the following exception when Local cache is used and
> persistence enabled.
> {code}
> [2020-03-05 16:47:39,222][ERROR][main][IgniteKernal] Exception during start
> processors, node will be stopped and close connections[2020-03-05
> 16:47:39,222][ERROR][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: An error occurred during cache
> configuration loading from file [file=...] at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:965)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:907)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:171)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCacheConfigurations(GridLocalConfigManager.java:124)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5198)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:488)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:824)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5378)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1286) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2054)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1704)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659) at
> org.apache.ignite.Ignition.start(Ignition.java:346) at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:38)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to find class
> with given class loader for unmarshalling (make sure same versions of all
> classes are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:129)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:961)
> ... 18 moreCaused by: java.lang.ClassNotFoundException:
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
> java.lang.ClassLoader
[jira] [Commented] (IGNITE-12799) Set right SpEL at Spring Data tests
[
https://issues.apache.org/jira/browse/IGNITE-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061959#comment-17061959
]
Sergey Chernolyas commented on IGNITE-12799:
Hi [~slava.koptilin]!
Class org.springframework.context.expression.StandardBeanExpressionResolver
thinks that SpEL is between "#\{" and "}". It doesn't recognize SpEL in all
other strings. It was my error. Also, you can look at
[https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/expression/StandardBeanExpressionResolver.html]
I have appended test method which checks cache names. Test method
[https://github.com/apache/ignite/blob/2e5df6d42536c53421f18cd68c4befe0939f26ac/modules/spring-data-2.0/src/test/java/org/apache/ignite/springdata/IgniteSpringDataCrudSelfExpressionTest.java#L116]
checks that SpEL have been processed.
> Set right SpEL at Spring Data tests
> ---
>
> Key: IGNITE-12799
> URL: https://issues.apache.org/jira/browse/IGNITE-12799
> Project: Ignite
> Issue Type: Bug
> Components: spring
>Affects Versions: 2.8.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>Priority: Trivial
> Fix For: 2.8.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> PersonExpressionRepository uses SpEL "@cacheNames.personCacheName". It is
> wrong. SpEL "#\{cacheNames.personCacheName}" must be used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak
[
https://issues.apache.org/jira/browse/IGNITE-12769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061937#comment-17061937
]
Nikolay Izhikov commented on IGNITE-12769:
--
[~agura]
Can you, please, take a look at my changes
https://github.com/apache/ignite/pull/7549/files
> MetricRegistryMBean and OpenCensusExporterSpi have memory leak
> --
>
> Key: IGNITE-12769
> URL: https://issues.apache.org/jira/browse/IGNITE-12769
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak.
> To the following maps values add but never remove (i.e. on remove
> corresponding histogram or on change histogram buckets layout):
> * {{MetricRegistryMBean.histogramNames}}
> * {{OpenCensusMetricExporterSpi.histogramNames}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak
[
https://issues.apache.org/jira/browse/IGNITE-12769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061932#comment-17061932
]
Nikolay Izhikov commented on IGNITE-12769:
--
[~agura]
> For MetricRegistryMBean each invocation of getAttribute attribute method
> will still produce garbage which is comparable with concatenation of metric
> name and bounds.
Ok, let's remove histogramNames cache from the MetricRegistryMBean.
> MetricRegistryMBean and OpenCensusExporterSpi have memory leak
> --
>
> Key: IGNITE-12769
> URL: https://issues.apache.org/jira/browse/IGNITE-12769
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
>
> {{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak.
> To the following maps values add but never remove (i.e. on remove
> corresponding histogram or on change histogram buckets layout):
> * {{MetricRegistryMBean.histogramNames}}
> * {{OpenCensusMetricExporterSpi.histogramNames}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12801) Possible extra page release when throttling and checkpoint thread store its concurrently
Anton Kalashnikov created IGNITE-12801:
--
Summary: Possible extra page release when throttling and
checkpoint thread store its concurrently
Key: IGNITE-12801
URL: https://issues.apache.org/jira/browse/IGNITE-12801
Project: Ignite
Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov
* User thread acquire page on write release
* Checkpoint thread sees that page was acquired
* Throttling thread sees that page was acquired
* Checkpoint thread saves page to disk and releases the page
* Throttling thread understand that the page was already saved but nonetheless
release this page again. - this is not ok.
{noformat}
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.copyPageForCheckpoint(PageMemoryImpl.java:1181)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.checkpointWritePage(PageMemoryImpl.java:1160)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4868)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:4792)
... 3 common frames omitted
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak
[
https://issues.apache.org/jira/browse/IGNITE-12769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061788#comment-17061788
]
Andrey N. Gura commented on IGNITE-12769:
-
[~nizhikov] {{MetricRegistry}} still allows to remove any metrics. If somebody
remove histogram metric {{histrogramNames}} caches will still contain key-value
pair for removed histogram.
I don't see any reason for {{histogramNames}} cache at all. For
{{MetricRegistryMBean}} each invocation of {{getAttribute}} attribute method
will still produce garbage which is comparable with concatenation of metric
name and bounds.
If we remove this cache we will also fix IGNITE-12767 automatically. Moreover,
we will fix design problem where {{MetricUtils}} is responsible for histogram
metric name representation instead of corresponding exporter.
> MetricRegistryMBean and OpenCensusExporterSpi have memory leak
> --
>
> Key: IGNITE-12769
> URL: https://issues.apache.org/jira/browse/IGNITE-12769
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
>
> {{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak.
> To the following maps values add but never remove (i.e. on remove
> corresponding histogram or on change histogram buckets layout):
> * {{MetricRegistryMBean.histogramNames}}
> * {{OpenCensusMetricExporterSpi.histogramNames}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.
[
https://issues.apache.org/jira/browse/IGNITE-12800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-12800:
--
Priority: Critical (was: Major)
> SQL: local queries cursors must be closed or full read to unlock the
> GridH2Table.
> -
>
> Key: IGNITE-12800
> URL: https://issues.apache.org/jira/browse/IGNITE-12800
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> *Root cause:* local queries cursors must be closed or full read to unlock the
> GridH2Table.
> *Proposal fix:*
> - modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N
> records into internal buffer and unlock the tables (similar to
> {{MapQueryResult}}; later we have to refactor these classes. They must use
> one code base to fetch data and lok/unlock tables)
> - modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the
> real query cancellation isn't called when result set is gathered. It is not
> valid for lazy mode.
> - add wrapper for iterator at the {{RegisteredQueryCursor}} because the state
> of query isn't tracked when results are read via Iterator at the client code.
> - fix tests that doesn't close query cursor for local queries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.
[
https://issues.apache.org/jira/browse/IGNITE-12800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-12800:
--
Fix Version/s: (was: 2.9)
2.8.1
> SQL: local queries cursors must be closed or full read to unlock the
> GridH2Table.
> -
>
> Key: IGNITE-12800
> URL: https://issues.apache.org/jira/browse/IGNITE-12800
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8.1
>
>
> *Root cause:* local queries cursors must be closed or full read to unlock the
> GridH2Table.
> *Proposal fix:*
> - modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N
> records into internal buffer and unlock the tables (similar to
> {{MapQueryResult}}; later we have to refactor these classes. They must use
> one code base to fetch data and lok/unlock tables)
> - modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the
> real query cancellation isn't called when result set is gathered. It is not
> valid for lazy mode.
> - add wrapper for iterator at the {{RegisteredQueryCursor}} because the state
> of query isn't tracked when results are read via Iterator at the client code.
> - fix tests that doesn't close query cursor for local queries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak
[
https://issues.apache.org/jira/browse/IGNITE-12769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061771#comment-17061771
]
Nikolay Izhikov edited comment on IGNITE-12769 at 3/18/20, 2:36 PM:
[~agura]
It seems to me that this issue is invalid.
{{OpenCensusMetricExporterSpi}} and {{MetricRegistryMBean}} keep up to date
{{histogramNames}} cache.
I want to close this ticket as "Not a Problem". What do you think?
1. On the {{MetricRegistry}} removal, all cache for OpenCensus exporter will be
cleared in
{code:java}
/** {@inheritDoc} */
@Override public void spiStart(@Nullable String igniteInstanceName) throws
IgniteSpiException {
//
mreg.addMetricRegistryRemoveListener(mreg -> mreg.forEach(metric ->
histogramNames.remove(metric.name(;
}
{code}
2. On the {{MetricRegistry}} removal bean for JMX will be unregistered
therefore it will be collected by GC:
{code:java}
/** {@inheritDoc} */
@Override public void spiStart(@Nullable String igniteInstanceName) throws
IgniteSpiException {
//
mreg.addMetricRegistryRemoveListener(this::unregister);
}
{code}
3. On the configuration change cache for the specific histogram will be
refreshed in(this applies to the both - JMX and OpenCencus exporters).
{code:java}
public static String[] histogramBucketNames(HistogramMetric metric,
Map> cache) {
//
T2 tuple = cache.get(name);
if (tuple != null && tuple.get1() == bounds) //bounds will be changed
on configuration change.
return tuple.get2();
//
cache.put(name, new T2<>(bounds, names)); //Cache refresh.
return names;
}
{code}
was (Author: nizhikov):
[~agura]
It seems to me that this issue is invalid.
{OpenCensusMetricExporterSpi} and {MetricRegistryMBean} keeps up to date
{histogramNames} cache.
I want to close this ticket as "Not a Problem". What do you think?
1. On the {MetricRegistry} removal all cache for OpenCensus exporter will be
cleared in
{code:java}
/** {@inheritDoc} */
@Override public void spiStart(@Nullable String igniteInstanceName) throws
IgniteSpiException {
//
mreg.addMetricRegistryRemoveListener(mreg -> mreg.forEach(metric ->
histogramNames.remove(metric.name(;
}
{code}
2. On the {MetricRegistry} removal bean for JMX will be unregistered therefore
it will be collected by GC:
{code:java}
/** {@inheritDoc} */
@Override public void spiStart(@Nullable String igniteInstanceName) throws
IgniteSpiException {
//
mreg.addMetricRegistryRemoveListener(this::unregister);
}
{code}
3. On the configuration change cache for the specific histogram will be
refreshed in(this applies to the both - JMX and OpenCencus exporters).
{code:java}
public static String[] histogramBucketNames(HistogramMetric metric,
Map> cache) {
//
T2 tuple = cache.get(name);
if (tuple != null && tuple.get1() == bounds) //bounds will be changed
on configu change.
return tuple.get2();
//
cache.put(name, new T2<>(bounds, names)); //Cache refresh.
return names;
}
{code}
> MetricRegistryMBean and OpenCensusExporterSpi have memory leak
> --
>
> Key: IGNITE-12769
> URL: https://issues.apache.org/jira/browse/IGNITE-12769
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
>
> {{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak.
> To the following maps values add but never remove (i.e. on remove
> corresponding histogram or on change histogram buckets layout):
> * {{MetricRegistryMBean.histogramNames}}
> * {{OpenCensusMetricExporterSpi.histogramNames}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak
[
https://issues.apache.org/jira/browse/IGNITE-12769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061771#comment-17061771
]
Nikolay Izhikov commented on IGNITE-12769:
--
[~agura]
It seems to me that this issue is invalid.
{OpenCensusMetricExporterSpi} and {MetricRegistryMBean} keeps up to date
{histogramNames} cache.
I want to close this ticket as "Not a Problem". What do you think?
1. On the {MetricRegistry} removal all cache for OpenCensus exporter will be
cleared in
{code:java}
/** {@inheritDoc} */
@Override public void spiStart(@Nullable String igniteInstanceName) throws
IgniteSpiException {
//
mreg.addMetricRegistryRemoveListener(mreg -> mreg.forEach(metric ->
histogramNames.remove(metric.name(;
}
{code}
2. On the {MetricRegistry} removal bean for JMX will be unregistered therefore
it will be collected by GC:
{code:java}
/** {@inheritDoc} */
@Override public void spiStart(@Nullable String igniteInstanceName) throws
IgniteSpiException {
//
mreg.addMetricRegistryRemoveListener(this::unregister);
}
{code}
3. On the configuration change cache for the specific histogram will be
refreshed in(this applies to the both - JMX and OpenCencus exporters).
{code:java}
public static String[] histogramBucketNames(HistogramMetric metric,
Map> cache) {
//
T2 tuple = cache.get(name);
if (tuple != null && tuple.get1() == bounds) //bounds will be changed
on configu change.
return tuple.get2();
//
cache.put(name, new T2<>(bounds, names)); //Cache refresh.
return names;
}
{code}
> MetricRegistryMBean and OpenCensusExporterSpi have memory leak
> --
>
> Key: IGNITE-12769
> URL: https://issues.apache.org/jira/browse/IGNITE-12769
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
>
> {{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak.
> To the following maps values add but never remove (i.e. on remove
> corresponding histogram or on change histogram buckets layout):
> * {{MetricRegistryMBean.histogramNames}}
> * {{OpenCensusMetricExporterSpi.histogramNames}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12800) SQL: local queries cursors must be closed or full read to unlock the GridH2Table.
Taras Ledkov created IGNITE-12800:
-
Summary: SQL: local queries cursors must be closed or full read to
unlock the GridH2Table.
Key: IGNITE-12800
URL: https://issues.apache.org/jira/browse/IGNITE-12800
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.8
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.9
*Root cause:* local queries cursors must be closed or full read to unlock the
GridH2Table.
*Proposal fix:*
- modify {{H2ResultSetIterator}} to use "paged mode": iterator reads N records
into internal buffer and unlock the tables (similar to {{MapQueryResult}};
later we have to refactor these classes. They must use one code base to fetch
data and lok/unlock tables)
- modify the state logic of the {{QueryCursorImpl}} for lazy mode. Now the real
query cancellation isn't called when result set is gathered. It is not valid
for lazy mode.
- add wrapper for iterator at the {{RegisteredQueryCursor}} because the state
of query isn't tracked when results are read via Iterator at the client code.
- fix tests that doesn't close query cursor for local queries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12799) Set right SpEL at Spring Data tests
[
https://issues.apache.org/jira/browse/IGNITE-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061760#comment-17061760
]
Vyacheslav Koptilin edited comment on IGNITE-12799 at 3/18/20, 2:19 PM:
Hello [~schernolyas],
I am not an expert in spring data at all. However, I have the following
question:
IGNITE-12582 contains new tests and it is verified by TC Boat (has a green
visa). Does it mean there are no tests that cover the bug you are trying to fix
in this pull-request?
Could you please add to the description the reason why
\{#cacheNames.personCacheName} should be used instead of
\{@cacheNames.personCacheName}?
Thanks,
S.
was (Author: slava.koptilin):
Hello [~schernolyas],
I am not an expert in spring data at all. However, I have the following
question:
IGNITE-12582 contains new tests and it is verified by TC Boat (has a green
visa). Does it mean there are no tests that cover the bug you are trying to fix
in this pull-request?
Thanks,
S.
> Set right SpEL at Spring Data tests
> ---
>
> Key: IGNITE-12799
> URL: https://issues.apache.org/jira/browse/IGNITE-12799
> Project: Ignite
> Issue Type: Bug
> Components: spring
>Affects Versions: 2.8.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>Priority: Trivial
> Fix For: 2.8.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> PersonExpressionRepository uses SpEL "@cacheNames.personCacheName". It is
> wrong. SpEL "#\{cacheNames.personCacheName}" must be used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12799) Set right SpEL at Spring Data tests
[
https://issues.apache.org/jira/browse/IGNITE-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061760#comment-17061760
]
Vyacheslav Koptilin commented on IGNITE-12799:
--
Hello [~schernolyas],
I am not an expert in spring data at all. However, I have the following
question:
IGNITE-12582 contains new tests and it is verified by TC Boat (has a green
visa). Does it mean there are no tests that cover the bug you are trying to fix
in this pull-request?
Thanks,
S.
> Set right SpEL at Spring Data tests
> ---
>
> Key: IGNITE-12799
> URL: https://issues.apache.org/jira/browse/IGNITE-12799
> Project: Ignite
> Issue Type: Bug
> Components: spring
>Affects Versions: 2.8.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>Priority: Trivial
> Fix For: 2.8.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> PersonExpressionRepository uses SpEL "@cacheNames.personCacheName". It is
> wrong. SpEL "#\{cacheNames.personCacheName}" must be used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak
[
https://issues.apache.org/jira/browse/IGNITE-12769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-12769:
Assignee: Nikolay Izhikov
> MetricRegistryMBean and OpenCensusExporterSpi have memory leak
> --
>
> Key: IGNITE-12769
> URL: https://issues.apache.org/jira/browse/IGNITE-12769
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
>
> {{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak.
> To the following maps values add but never remove (i.e. on remove
> corresponding histogram or on change histogram buckets layout):
> * {{MetricRegistryMBean.histogramNames}}
> * {{OpenCensusMetricExporterSpi.histogramNames}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12799) Set right SpEL at Spring Data tests
[
https://issues.apache.org/jira/browse/IGNITE-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061709#comment-17061709
]
Ignite TC Bot commented on IGNITE-12799:
{panel:title=Branch: [pull/7545/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5136931&buildTypeId=IgniteTests24Java8_RunAll]
> Set right SpEL at Spring Data tests
> ---
>
> Key: IGNITE-12799
> URL: https://issues.apache.org/jira/browse/IGNITE-12799
> Project: Ignite
> Issue Type: Bug
> Components: spring
>Affects Versions: 2.8.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>Priority: Trivial
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PersonExpressionRepository uses SpEL "@cacheNames.personCacheName". It is
> wrong. SpEL "#\{cacheNames.personCacheName}" must be used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12787) Remove obsolete Selector.open workaround code from GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-12787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061687#comment-17061687
]
Andrey Mashenkov commented on IGNITE-12787:
---
[~Pavlukhin], yes, PR looks good to me.
Apparently, "stable" versions (OpenJDK and vendored) already has the fix as it
was fixed in early JDK 1.8 beta version.
> Remove obsolete Selector.open workaround code from GridNioServer
>
>
> Key: IGNITE-12787
> URL: https://issues.apache.org/jira/browse/IGNITE-12787
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a code in {{GridNioServer}} aimed to workaround an old bug in JDK
> 1.5 which was fixed in 1.7.
> {code}
> static {
> // This is a workaround for JDK bug (NPE in Selector.open()).
> // http://bugs.sun.com/view_bug.do?bug_id=6427854
> try {
> Selector.open().close();
> }
> catch (IOException ignored) {
> // No-op.
> }
> }
> {code}
> Currently Java 8 is a minimal supported version. So, the workaround code can
> be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061685#comment-17061685
]
Amelchev Nikita commented on IGNITE-12779:
--
[~vladsz83], LGTM.
[~nizhikov], could you take a look, please?
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
> 3) Add IgniteMXBean.state(String, boolean)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12779:
--
Description:
To make cluster deactivation through JMX without sudden erasure in-memory data
we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
was:
To make cluster deactivation through JMX without sudden erasure in-memory data
we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
> 3) Add IgniteMXBean.state(String, boolean)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061681#comment-17061681
]
Ignite TC Bot commented on IGNITE-12779:
{panel:title=Branch: [pull/7531/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5124971&buildTypeId=IgniteTests24Java8_RunAll]
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12787) Remove obsolete Selector.open workaround code from GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-12787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061654#comment-17061654
]
Ivan Pavlukhin edited comment on IGNITE-12787 at 3/18/20, 11:44 AM:
[~amashenkov], is a resolved *openjdk* ticket a sufficient proof?
https://bugs.openjdk.java.net/browse/JDK-6427854
Here is a jdk8_b01 code
https://github.com/openjdk/jdk/blob/d2ac7a107e4af38df029fc19e37df25a4831514e/jdk/src/share/classes/sun/nio/ch/Util.java#L451
_volatile_ property seems to be the fix we are looking for.
was (Author: pavlukhin):
[~amashenkov], is a resolved **openjdk** ticket a sufficient proof?
https://bugs.openjdk.java.net/browse/JDK-6427854
Here is a jdk8_b01 code
https://github.com/openjdk/jdk/blob/d2ac7a107e4af38df029fc19e37df25a4831514e/jdk/src/share/classes/sun/nio/ch/Util.java#L451
_volatile_ property seems to be the fix we are looking for.
> Remove obsolete Selector.open workaround code from GridNioServer
>
>
> Key: IGNITE-12787
> URL: https://issues.apache.org/jira/browse/IGNITE-12787
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a code in {{GridNioServer}} aimed to workaround an old bug in JDK
> 1.5 which was fixed in 1.7.
> {code}
> static {
> // This is a workaround for JDK bug (NPE in Selector.open()).
> // http://bugs.sun.com/view_bug.do?bug_id=6427854
> try {
> Selector.open().close();
> }
> catch (IOException ignored) {
> // No-op.
> }
> }
> {code}
> Currently Java 8 is a minimal supported version. So, the workaround code can
> be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12787) Remove obsolete Selector.open workaround code from GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-12787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061654#comment-17061654
]
Ivan Pavlukhin commented on IGNITE-12787:
-
[~amashenkov], is a resolved **openjdk** ticket a sufficient proof?
https://bugs.openjdk.java.net/browse/JDK-6427854
Here is a jdk8_b01 code
https://github.com/openjdk/jdk/blob/d2ac7a107e4af38df029fc19e37df25a4831514e/jdk/src/share/classes/sun/nio/ch/Util.java#L451
_volatile_ property seems to be the fix we are looking for.
> Remove obsolete Selector.open workaround code from GridNioServer
>
>
> Key: IGNITE-12787
> URL: https://issues.apache.org/jira/browse/IGNITE-12787
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a code in {{GridNioServer}} aimed to workaround an old bug in JDK
> 1.5 which was fixed in 1.7.
> {code}
> static {
> // This is a workaround for JDK bug (NPE in Selector.open()).
> // http://bugs.sun.com/view_bug.do?bug_id=6427854
> try {
> Selector.open().close();
> }
> catch (IOException ignored) {
> // No-op.
> }
> }
> {code}
> Currently Java 8 is a minimal supported version. So, the workaround code can
> be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12766) Node startup can be broken in case of using Local cache with persistence enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061649#comment-17061649
]
Vyacheslav Koptilin commented on IGNITE-12766:
--
Hello [~langj], [~Pavlukhin],
Could you please take a look at the pull-request?
Thanks,
S.
> Node startup can be broken in case of using Local cache with persistence
> enabled.
> -
>
> Key: IGNITE-12766
> URL: https://issues.apache.org/jira/browse/IGNITE-12766
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to upgrade from the previous version of Apache Ignite (AI 2.7.6 for
> example) may result in the following exception when Local cache is used and
> persistence enabled.
> {code}
> [2020-03-05 16:47:39,222][ERROR][main][IgniteKernal] Exception during start
> processors, node will be stopped and close connections[2020-03-05
> 16:47:39,222][ERROR][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: An error occurred during cache
> configuration loading from file [file=...] at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:965)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:907)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:171)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCacheConfigurations(GridLocalConfigManager.java:124)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5198)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:488)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:824)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5378)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1286) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2054)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1704)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659) at
> org.apache.ignite.Ignition.start(Ignition.java:346) at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:38)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to find class
> with given class loader for unmarshalling (make sure same versions of all
> classes are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:129)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:961)
> ... 18 moreCaused by: java.lang.ClassNotFoundException:
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
> java.lang.Class.forName0(Native Method) at
> java.lang.Class.forName(Class.java:348) at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8870) at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInput
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12779:
--
Description:
To make cluster deactivation through JMX without sudden erasure in-memory data
we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
was:
To make cluster deactivation through JMX without sudden erasure in-memory data
we should:
1) Make IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12779:
--
Description:
To make cluster deactivation through JMX without sudden erasure in-memory data
we should:
1) Make IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
was:
To make cluster deactivation through JMX without sudden erasure in-memory data
we should:
1) Add _IgniteMXBean#state(String state, boolean forceDeactivation)_.
2) Let _IgniteMXBean#state(String state)_ and _IgniteMXBean#active(boolean
active)_ fail when deactivating cluster with in-memory data.
3) Separate implementations _Ignite_ and _IgniteMXBean_ from
_IgniteKernal_. They have same method _void active(boolean active)_ which is
required with different behavior. In case of _Ignite#active(boolean active)_ it
should not fail when deactivating cluster with in-memory data.
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure in-memory
> data we should:
> 1) Make IgniteMXBean.active(false) and IgniteMXBean.state("inactive")
> throwing an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12789) Tracking page repairing has no WAL record associated with it
[ https://issues.apache.org/jira/browse/IGNITE-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-12789: --- Description: org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) In order for tracking pages to work properly they should be persisted on disk, it means that failed checkpoint scenario should be supported. Tracking pages restoration has no associated WAL record so in that case binary recovery could leave them broken after a valid repair. was: org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) In order for tracking pages to work properly they should be persisted on disk, it means that failed checkpoint scenario should be supported. Tracking pages restoration haЫ no associated WAL record so in that case binary recovery could leave them broken after a valid repair. > Tracking page repairing has no WAL record associated with it > > > Key: IGNITE-12789 > URL: https://issues.apache.org/jira/browse/IGNITE-12789 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) > > In order for tracking pages to work properly they should be persisted on > disk, it means that failed checkpoint scenario should be supported. Tracking > pages restoration has no associated WAL record so in that case binary > recovery could leave them broken after a valid repair. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061635#comment-17061635
]
Denis Mekhanikov commented on IGNITE-12794:
---
A patch is ready: [https://github.com/apache/ignite/pull/7541]
[~gvvinblade] could you help with a review?
Thanks!
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8.1
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-12794:
--
Reviewer: Igor Seliverstov
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8.1
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061634#comment-17061634
]
Ignite TC Bot commented on IGNITE-12794:
{panel:title=Branch: [pull/7541/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5134222&buildTypeId=IgniteTests24Java8_RunAll]
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8.1
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061633#comment-17061633
]
Sunghan Suh commented on IGNITE-12543:
--
[~Pavlukhin], the above comment is extactly same as what we have wanted to
resolve. I leave a message for your confirmation request.
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12797) Add command line option to CommandHandler to be able to see full stack trace and cause exception in log in case of error.
[ https://issues.apache.org/jira/browse/IGNITE-12797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061628#comment-17061628 ] Ilya Kasnacheev commented on IGNITE-12797: -- Can we have a positive test, one where the presence of this option does not prevent successful operation from succeeding? > Add command line option to CommandHandler to be able to see full stack trace > and cause exception in log in case of error. > - > > Key: IGNITE-12797 > URL: https://issues.apache.org/jira/browse/IGNITE-12797 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > In case of error control.sh can print common error message without any > information about root cause of error. Printing full stack trace and cause > can ease the analysis. User should be able to turn it on when launching > control.sh with specific option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[ https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12779: -- Description: To make cluster deactivation through JMX without sudden erasure in-memory data we should: 1) Add _IgniteMXBean#state(String state, boolean forceDeactivation)_. 2) Let _IgniteMXBean#state(String state)_ and _IgniteMXBean#active(boolean active)_ fail when deactivating cluster with in-memory data. 3) Separate implementations _Ignite_ and _IgniteMXBean_ from _IgniteKernal_. They have same method _void active(boolean active)_ which is required with different behavior. In case of _Ignite#active(boolean active)_ it should not fail when deactivating cluster with in-memory data. was: To make cluster deactivation through JMX without sudden erasure in-memory data we should: 1) Add _IgniteMXBean#state(String state, boolean force)_. 2) Let _IgniteMXBean#state(String state)_ and _IgniteMXBean#active(boolean active)_ fail when deactivating cluster with in-memory data. 3) Separate implementations _Ignite_ and _IgniteMXBean_ from _IgniteKernal_. They have same method _void active(boolean active)_ which is required with different behavior. In case of _Ignite#active(boolean active)_ it should not fail when deactivating cluster with in-memory data. > Split implementations of Ignite and IgniteMXBean, make behavior of their > active(boolean) different > --- > > Key: IGNITE-12779 > URL: https://issues.apache.org/jira/browse/IGNITE-12779 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.8 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Fix For: 2.9 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > To make cluster deactivation through JMX without sudden erasure in-memory > data we should: > 1)Add _IgniteMXBean#state(String state, boolean forceDeactivation)_. > 2)Let _IgniteMXBean#state(String state)_ and _IgniteMXBean#active(boolean > active)_ fail when deactivating cluster with in-memory data. > 3)Separate implementations _Ignite_ and _IgniteMXBean_ from > _IgniteKernal_. They have same method _void active(boolean active)_ which is > required with different behavior. In case of _Ignite#active(boolean active)_ > it should not fail when deactivating cluster with in-memory data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12768) MetricRegistryMBean doesn't show histogram values in case when histogram name contains underscore character
[
https://issues.apache.org/jira/browse/IGNITE-12768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061620#comment-17061620
]
Nikolay Izhikov commented on IGNITE-12768:
--
Merged to master.
Cherry-picked to 2.8.1
> MetricRegistryMBean doesn't show histogram values in case when histogram name
> contains underscore character
> ---
>
> Key: IGNITE-12768
> URL: https://issues.apache.org/jira/browse/IGNITE-12768
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{MetricRegistryMBean}} doesn't show histogram values in case when histogram
> name contains underscore character.
> The problem in {{MetricRegistryMBean.searchHistogram()}} method which relies
> on first underscore character in the fully qualified metric name. This method
> also use relatively old and not effective API for string parsing (this API
> implementation is synchronized). It should be replaced by simple
> {{String.lastIndexOf()}} for example.
> Reproducer:
> {code:java}
> package org.apache.ignite.spi.metric.jmx;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.processors.metric.MetricRegistry;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.junit.Test;
> import javax.management.*;
> import java.lang.management.ManagementFactory;
> public class MetricRegistryMBeanTest extends GridCommonAbstractTest {
> private static final String REGISTRY_NAME = "test_registry";
> private static final String VALID_HISTOGRAM_NAME = "testhist";
> private static final String INVALID_HISTOGRAM_NAME = "test_hist";
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi exporterSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(exporterSpi);
> return cfg;
> }
> @Test public void testBean() throws Exception {
> Ignite ignite = startGrid();
> MetricRegistry reg =
> ((IgniteEx)ignite).context().metric().registry(REGISTRY_NAME);
> reg.histogram(VALID_HISTOGRAM_NAME, new long[] {10, 100}, null);
> reg.histogram(INVALID_HISTOGRAM_NAME, new long[] {10, 100}, null);
> assertNotNull(mbean(ignite).getAttribute(VALID_HISTOGRAM_NAME + '_' +
> 10 + '_' + 100));
> assertEquals(0L, mbean(ignite).getAttribute(VALID_HISTOGRAM_NAME +
> '_' + 10 + '_' + 100));
> assertNotNull(mbean(ignite).getAttribute(INVALID_HISTOGRAM_NAME + '_'
> + 10 + '_' + 100));
> assertEquals(0L, mbean(ignite).getAttribute(INVALID_HISTOGRAM_NAME +
> '_' + 10 + '_' + 100));
> }
> private static DynamicMBean mbean(Ignite ignite) {
> try {
> ObjectName mbeanName = U.makeMBeanName(ignite.name(), null,
> REGISTRY_NAME);
> MBeanServer mbeanSrv = ManagementFactory.getPlatformMBeanServer();
> if (!mbeanSrv.isRegistered(mbeanName))
> fail("MBean is not registered: " +
> mbeanName.getCanonicalName());
> return MBeanServerInvocationHandler.newProxyInstance(mbeanSrv,
> mbeanName, DynamicMBean.class, false);
> } catch (MalformedObjectNameException e) {
> throw new IgniteException(e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Fix Version/s: 2.9
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Fix For: 2.9
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 8.Add @Override to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 9. Remove, combine with #8:
> IGridClusterStateProcessor#changeGlobalState0(
> ClusterState state,
> BaselineTopology blt,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[ https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12779: -- Affects Version/s: 2.8 > Split implementations of Ignite and IgniteMXBean, make behavior of their > active(boolean) different > --- > > Key: IGNITE-12779 > URL: https://issues.apache.org/jira/browse/IGNITE-12779 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.8 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Fix For: 2.9 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > To make cluster deactivation through JMX without sudden erasure in-memory > data we should: > 1)Add _IgniteMXBean#state(String state, boolean force)_. > 2)Let _IgniteMXBean#state(String state)_ and _IgniteMXBean#active(boolean > active)_ fail when deactivating cluster with in-memory data. > 3)Separate implementations _Ignite_ and _IgniteMXBean_ from > _IgniteKernal_. They have same method _void active(boolean active)_ which is > required with different behavior. In case of _Ignite#active(boolean active)_ > it should not fail when deactivating cluster with in-memory data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Affects Version/s: 2.8
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Fix For: 2.9
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 8.Add @Override to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 9. Remove, combine with #8:
> IGridClusterStateProcessor#changeGlobalState0(
> ClusterState state,
> BaselineTopology blt,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[ https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12779: -- Fix Version/s: 2.9 > Split implementations of Ignite and IgniteMXBean, make behavior of their > active(boolean) different > --- > > Key: IGNITE-12779 > URL: https://issues.apache.org/jira/browse/IGNITE-12779 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Fix For: 2.9 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > To make cluster deactivation through JMX without sudden erasure in-memory > data we should: > 1)Add _IgniteMXBean#state(String state, boolean force)_. > 2)Let _IgniteMXBean#state(String state)_ and _IgniteMXBean#active(boolean > active)_ fail when deactivating cluster with in-memory data. > 3)Separate implementations _Ignite_ and _IgniteMXBean_ from > _IgniteKernal_. They have same method _void active(boolean active)_ which is > required with different behavior. In case of _Ignite#active(boolean active)_ > it should not fail when deactivating cluster with in-memory data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12464) Service metrics
[ https://issues.apache.org/jira/browse/IGNITE-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12464: -- Affects Version/s: (was: 2.7.6) 2.8 > Service metrics > --- > > Key: IGNITE-12464 > URL: https://issues.apache.org/jira/browse/IGNITE-12464 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Labels: IEP-35 > Time Spent: 5h 50m > Remaining Estimate: 0h > > We should provide the following metrics for each deployed service: > * -Count of executions- - this number seems useless, because, we can compute > it just by summing all histograms values. > * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12787) Remove obsolete Selector.open workaround code from GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-12787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061610#comment-17061610
]
Andrey Mashenkov commented on IGNITE-12787:
---
[~Pavlukhin],
There was a link to Oracle JDK ticket which looks outdated and broken.
Is there any proof that the fix is a part of all 1.8_x JDK versions?
I mean here not only OracleJDK, but OpenJDK and other vendors.
> Remove obsolete Selector.open workaround code from GridNioServer
>
>
> Key: IGNITE-12787
> URL: https://issues.apache.org/jira/browse/IGNITE-12787
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a code in {{GridNioServer}} aimed to workaround an old bug in JDK
> 1.5 which was fixed in 1.7.
> {code}
> static {
> // This is a workaround for JDK bug (NPE in Selector.open()).
> // http://bugs.sun.com/view_bug.do?bug_id=6427854
> try {
> Selector.open().close();
> }
> catch (IOException ignored) {
> // No-op.
> }
> }
> {code}
> Currently Java 8 is a minimal supported version. So, the workaround code can
> be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061604#comment-17061604
]
Ivan Pavlukhin commented on IGNITE-12543:
-
(y)
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12789) Tracking page repairing has no WAL record associated with it
[ https://issues.apache.org/jira/browse/IGNITE-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-12789: --- Description: org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) In order for tracking pages to work properly they should be persisted on disk, it means that failed checkpoint scenario should be supported. Tracking pages restoration haЫ no associated WAL record so in that case binary recovery could leave them broken after a valid repair. was: org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) In order for tracking pages to work properly they should be persisted on disk, it means that failed checkpoint scenario should be supported. Tracking pages restoration have no associated WAL record so in that case binary recovery leave leave them broken after a valid repair. > Tracking page repairing has no WAL record associated with it > > > Key: IGNITE-12789 > URL: https://issues.apache.org/jira/browse/IGNITE-12789 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) > > In order for tracking pages to work properly they should be persisted on > disk, it means that failed checkpoint scenario should be supported. Tracking > pages restoration haЫ no associated WAL record so in that case binary > recovery could leave them broken after a valid repair. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12789) Tracking page repairing has no WAL record associated with it
[ https://issues.apache.org/jira/browse/IGNITE-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-12789: --- Description: org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) In order for tracking pages to work properly they should be persisted on disk, it means that failed checkpoint scenario should be supported. Tracking pages restoration have no associated WAL record so in that case binary recovery leave leave them broken after a valid repair. was:org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) > Tracking page repairing has no WAL record associated with it > > > Key: IGNITE-12789 > URL: https://issues.apache.org/jira/browse/IGNITE-12789 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long) > > In order for tracking pages to work properly they should be persisted on > disk, it means that failed checkpoint scenario should be supported. Tracking > pages restoration have no associated WAL record so in that case binary > recovery leave leave them broken after a valid repair. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12768) MetricRegistryMBean doesn't show histogram values in case when histogram name contains underscore character
[
https://issues.apache.org/jira/browse/IGNITE-12768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061599#comment-17061599
]
Ignite TC Bot commented on IGNITE-12768:
{panel:title=Branch: [pull/7542/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5135360&buildTypeId=IgniteTests24Java8_RunAll]
> MetricRegistryMBean doesn't show histogram values in case when histogram name
> contains underscore character
> ---
>
> Key: IGNITE-12768
> URL: https://issues.apache.org/jira/browse/IGNITE-12768
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{MetricRegistryMBean}} doesn't show histogram values in case when histogram
> name contains underscore character.
> The problem in {{MetricRegistryMBean.searchHistogram()}} method which relies
> on first underscore character in the fully qualified metric name. This method
> also use relatively old and not effective API for string parsing (this API
> implementation is synchronized). It should be replaced by simple
> {{String.lastIndexOf()}} for example.
> Reproducer:
> {code:java}
> package org.apache.ignite.spi.metric.jmx;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.processors.metric.MetricRegistry;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.junit.Test;
> import javax.management.*;
> import java.lang.management.ManagementFactory;
> public class MetricRegistryMBeanTest extends GridCommonAbstractTest {
> private static final String REGISTRY_NAME = "test_registry";
> private static final String VALID_HISTOGRAM_NAME = "testhist";
> private static final String INVALID_HISTOGRAM_NAME = "test_hist";
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi exporterSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(exporterSpi);
> return cfg;
> }
> @Test public void testBean() throws Exception {
> Ignite ignite = startGrid();
> MetricRegistry reg =
> ((IgniteEx)ignite).context().metric().registry(REGISTRY_NAME);
> reg.histogram(VALID_HISTOGRAM_NAME, new long[] {10, 100}, null);
> reg.histogram(INVALID_HISTOGRAM_NAME, new long[] {10, 100}, null);
> assertNotNull(mbean(ignite).getAttribute(VALID_HISTOGRAM_NAME + '_' +
> 10 + '_' + 100));
> assertEquals(0L, mbean(ignite).getAttribute(VALID_HISTOGRAM_NAME +
> '_' + 10 + '_' + 100));
> assertNotNull(mbean(ignite).getAttribute(INVALID_HISTOGRAM_NAME + '_'
> + 10 + '_' + 100));
> assertEquals(0L, mbean(ignite).getAttribute(INVALID_HISTOGRAM_NAME +
> '_' + 10 + '_' + 100));
> }
> private static DynamicMBean mbean(Ignite ignite) {
> try {
> ObjectName mbeanName = U.makeMBeanName(ignite.name(), null,
> REGISTRY_NAME);
> MBeanServer mbeanSrv = ManagementFactory.getPlatformMBeanServer();
> if (!mbeanSrv.isRegistered(mbeanName))
> fail("MBean is not registered: " +
> mbeanName.getCanonicalName());
> return MBeanServerInvocationHandler.newProxyInstance(mbeanSrv,
> mbeanName, DynamicMBean.class, false);
> } catch (MalformedObjectNameException e) {
> throw new IgniteException(e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12734) Scan query shutting down the node in some cases
[
https://issues.apache.org/jira/browse/IGNITE-12734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061591#comment-17061591
]
Aleksey Plekhanov commented on IGNITE-12734:
[~mmuzaf] thank you for the review!
Merged to master.
> Scan query shutting down the node in some cases
> ---
>
> Key: IGNITE-12734
> URL: https://issues.apache.org/jira/browse/IGNITE-12734
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Fix For: 2.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> public class CachePartitionEvictionQueryTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String name)
> throws Exception {
> return super.getConfiguration(name).setDataStorageConfiguration(new
> DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> }
> @Override protected FailureHandler getFailureHandler(String
> igniteInstanceName) {
> return new StopNodeFailureHandler();
> }
> @Test
> public void testQuery() throws Exception {
>
> startGrid(getConfiguration(getTestIgniteInstanceName(0)).setConsistentId("1"));
> grid(0).cluster().active(true);
> grid(0).cluster().baselineAutoAdjustEnabled(true);
> grid(0).cluster().baselineAutoAdjustTimeout(0);
> IgniteCache cache = grid(0).getOrCreateCache(
> new CacheConfiguration Integer>(DEFAULT_CACHE_NAME).setBackups(0)
> .setAffinity(new
> RendezvousAffinityFunction().setPartitions(2)));
> cache.put(0, 0);
> cache.put(1, 1);
> Iterator iter = cache.query(new
> ScanQuery<>().setPageSize(1)).iterator();
> iter.next();
>
> startGrid(getConfiguration(getTestIgniteInstanceName(1)).setConsistentId("0"));
> awaitPartitionMapExchange();
> forceCheckpoint(grid(0));
> iter.next();
> }
> }
> {code}
> Node fails with the reason:
> {noformat}
> [2020-03-02
> 15:17:46,663][ERROR][test-runner-#1%cache.CachePartitionEvictionQueryTest%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[], msg=Runtime failure on bounds:
> [lower=null, upper=null
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[], msg=Runtime failure on
> bounds: [lower=null, upper=null]]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5927)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1054)
> at
> org.apache.ignite.internal.processors.cache.tree.CacheDataTree.find(CacheDataTree.java:164)
> at
> org.apache.ignite.internal.processors.cache.tree.CacheDataTree.find(CacheDataTree.java:63)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1021)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2884)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2878)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2866)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.cursor(GridCacheOffheapManager.java:2560)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.onHasNext(IgniteCacheOffheapManagerImpl.java:937)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3031)
> at
> org.apache.ignite
[jira] [Commented] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061585#comment-17061585
]
Aleksey Plekhanov commented on IGNITE-12543:
[~Pavlukhin] when we marshal {{List}} on thin client side there is no
size overhead. Overhead appears on the server-side when we unmarshal (with keep
binary) byte array to {{List}} and marshal it again. Each binary
object after unmarshalling refers to the same full byte array (with offset and
length), then this byte array is copied for each object by
{{doWriteBinaryObject}} method during second marshaling. If we will avoid
double marshaling, the object will be stored in the form thin client marshal it
(without size grow) and then transferred back to the thin client in the same
form. So, yes, number of bytes transferred over the wire will be adequate after
fixing IGNITE-12625
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12622) Forbid mixed cache groups with both atomic and transactional caches
[ https://issues.apache.org/jira/browse/IGNITE-12622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov reassigned IGNITE-12622: --- Assignee: Ivan Rakov > Forbid mixed cache groups with both atomic and transactional caches > --- > > Key: IGNITE-12622 > URL: https://issues.apache.org/jira/browse/IGNITE-12622 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.9 > > > Apparently it's possible in Ignite to configure a cache group with both > ATOMIC and TRANSACTIONAL caches. > IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* tests. > As per discussed on dev list > (http://apache-ignite-developers.2346864.n4.nabble.com/Forbid-mixed-cache-groups-with-both-atomic-and-transactional-caches-td45586.html), > the community has concluded that such configurations should be prohibited. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12768) MetricRegistryMBean doesn't show histogram values in case when histogram name contains underscore character
[
https://issues.apache.org/jira/browse/IGNITE-12768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061526#comment-17061526
]
Amelchev Nikita commented on IGNITE-12768:
--
[~nizhikov], Hi,
LGTM.
> MetricRegistryMBean doesn't show histogram values in case when histogram name
> contains underscore character
> ---
>
> Key: IGNITE-12768
> URL: https://issues.apache.org/jira/browse/IGNITE-12768
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{MetricRegistryMBean}} doesn't show histogram values in case when histogram
> name contains underscore character.
> The problem in {{MetricRegistryMBean.searchHistogram()}} method which relies
> on first underscore character in the fully qualified metric name. This method
> also use relatively old and not effective API for string parsing (this API
> implementation is synchronized). It should be replaced by simple
> {{String.lastIndexOf()}} for example.
> Reproducer:
> {code:java}
> package org.apache.ignite.spi.metric.jmx;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.processors.metric.MetricRegistry;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.junit.Test;
> import javax.management.*;
> import java.lang.management.ManagementFactory;
> public class MetricRegistryMBeanTest extends GridCommonAbstractTest {
> private static final String REGISTRY_NAME = "test_registry";
> private static final String VALID_HISTOGRAM_NAME = "testhist";
> private static final String INVALID_HISTOGRAM_NAME = "test_hist";
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi exporterSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(exporterSpi);
> return cfg;
> }
> @Test public void testBean() throws Exception {
> Ignite ignite = startGrid();
> MetricRegistry reg =
> ((IgniteEx)ignite).context().metric().registry(REGISTRY_NAME);
> reg.histogram(VALID_HISTOGRAM_NAME, new long[] {10, 100}, null);
> reg.histogram(INVALID_HISTOGRAM_NAME, new long[] {10, 100}, null);
> assertNotNull(mbean(ignite).getAttribute(VALID_HISTOGRAM_NAME + '_' +
> 10 + '_' + 100));
> assertEquals(0L, mbean(ignite).getAttribute(VALID_HISTOGRAM_NAME +
> '_' + 10 + '_' + 100));
> assertNotNull(mbean(ignite).getAttribute(INVALID_HISTOGRAM_NAME + '_'
> + 10 + '_' + 100));
> assertEquals(0L, mbean(ignite).getAttribute(INVALID_HISTOGRAM_NAME +
> '_' + 10 + '_' + 100));
> }
> private static DynamicMBean mbean(Ignite ignite) {
> try {
> ObjectName mbeanName = U.makeMBeanName(ignite.name(), null,
> REGISTRY_NAME);
> MBeanServer mbeanSrv = ManagementFactory.getPlatformMBeanServer();
> if (!mbeanSrv.isRegistered(mbeanName))
> fail("MBean is not registered: " +
> mbeanName.getCanonicalName());
> return MBeanServerInvocationHandler.newProxyInstance(mbeanSrv,
> mbeanName, DynamicMBean.class, false);
> } catch (MalformedObjectNameException e) {
> throw new IgniteException(e);
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061513#comment-17061513 ] Ivan Pavlukhin commented on IGNITE-12798: - [~rangerzhou], I guess that your problem is related to remote class loading. I suppose that when you start servers using ignite.sh server java processes do not have filter/listener classes on classpath. Classes need to be somehow delivered to servers, enabling _peer class loading_ might help (https://apacheignite.readme.io/docs/zero-deployment#peer-class-loading). Next potential problem might be using java lambdas for _filters_ and _listeners_, it worth trying anonymous classes if it does not work with lambdas. > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > But if I start server node by java code in IDEA ( Ignition.start() ), the > continuous query is ok. > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12760) Prevent AssertionError on message unmarshalling, when classLoaderId contains id of node that already left
[
https://issues.apache.org/jira/browse/IGNITE-12760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061511#comment-17061511
]
Denis Chudov commented on IGNITE-12760:
---
[~akalashnikov] could you please review my fix?
> Prevent AssertionError on message unmarshalling, when classLoaderId contains
> id of node that already left
> -
>
> Key: IGNITE-12760
> URL: https://issues.apache.org/jira/browse/IGNITE-12760
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Following assertion error triggers failure handler and crashes the node. Can
> possibly crash the whole cluster.
> {code:java}
> 2020-02-18
> 14:34:09.775\[ERROR]\[query-#146129%DPL_GRID%DplGridNodeName%]\[o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message \[senderId=727757ed-4ad4-4779-bda9-081525725cce,
> msg=GridCacheQueryRequest \[id=178,
> cacheName=com.sbt.tokenization.data.entity.KEKEntity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=727757ed-4ad4-4779-bda9-081525725cce, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion \[topVer=97, minorTopVer=0], sendTimestamp=-1,
> receiveTimestamp=-1, super=GridCacheIdMessage \[cacheId=-1129073400,
> super=GridCacheMessage \[msgId=179, depInfo=GridDeploymentInfoBean
> \[clsLdrId=c32670e3071-d30ee64b-0833-45d4-abbe-fb6282669caa, depMode=SHARED,
> userVer=0, locDepOwner=false, participants=null],
> lastAffChangedTopVer=AffinityTopologyVersion \[topVer=8, minorTopVer=6],
> err=null, skipPrepare=false
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1576)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1565)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:130)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1092)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
> There is no fair reproducer for now, but it seems that we should prevent such
> situation in general like following:
> 1) check the correctness of the message before it will be sent - inside of
> GridCacheDeploymentManager#prepare. If we have the corresponding class loader
> on local node, we can try to fix message and replace wrong class loader with
> local one.
> 2) log suspicious deployments which we receive from
> GridDeploymentManager#deploy - maybe we have obsolete deployments in caches.
> 3) possibly we can remove this assertion, we should have this class on sender
> node and use it as class loader id, and if we don't, we will receive
> exception on finishUnmarshall (Failed to peer load class) and try to process
> this situation with GridCacheIoManager#processFailedMessage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061496#comment-17061496
]
Ivan Pavlukhin commented on IGNITE-12543:
-
[~alex_pl], thank you for details. But will be a number of bytes transferred
over the wire adequate after fixing IGNITE-12625 or there still will be a size
explosion? Beforehand we observed an explosion when SQL columns of type
{{List}} had been transferred over the wire. The root cause is a
code fragment mentioned before:
{code: java}
// org.apacheignite.internal.binary.BinaryWriterExImpl.java
public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
if (po == null)
out.writeByte(GridBinaryMarshaller.NULL);
else {
byte[] poArr = po.array();
out.unsafeEnsure(1 + 4 + poArr.length +4);
out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
out.unsafeWriteInt(poArr.length);
out.writeByteArray(poArr);
out.unsafeWriteInt(po.start());
}
}
{code}
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12543) When put List>, the data was increased much larger.
[
https://issues.apache.org/jira/browse/IGNITE-12543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061496#comment-17061496
]
Ivan Pavlukhin edited comment on IGNITE-12543 at 3/18/20, 8:31 AM:
---
[~alex_pl], thank you for details. But will be a number of bytes transferred
over the wire adequate after fixing IGNITE-12625 or there still will be a size
explosion? Beforehand we observed an explosion when SQL columns of type
{{List}} had been transferred over the wire. The root cause is a
code fragment mentioned before:
{code:java}
// org.apacheignite.internal.binary.BinaryWriterExImpl.java
public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
if (po == null)
out.writeByte(GridBinaryMarshaller.NULL);
else {
byte[] poArr = po.array();
out.unsafeEnsure(1 + 4 + poArr.length +4);
out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
out.unsafeWriteInt(poArr.length);
out.writeByteArray(poArr);
out.unsafeWriteInt(po.start());
}
}
{code}
was (Author: pavlukhin):
[~alex_pl], thank you for details. But will be a number of bytes transferred
over the wire adequate after fixing IGNITE-12625 or there still will be a size
explosion? Beforehand we observed an explosion when SQL columns of type
{{List}} had been transferred over the wire. The root cause is a
code fragment mentioned before:
{code: java}
// org.apacheignite.internal.binary.BinaryWriterExImpl.java
public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
if (po == null)
out.writeByte(GridBinaryMarshaller.NULL);
else {
byte[] poArr = po.array();
out.unsafeEnsure(1 + 4 + poArr.length +4);
out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
out.unsafeWriteInt(poArr.length);
out.writeByteArray(poArr);
out.unsafeWriteInt(po.start());
}
}
{code}
> When put List>, the data was increased much larger.
>
>
> Key: IGNITE-12543
> URL: https://issues.apache.org/jira/browse/IGNITE-12543
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use Ignite 2.6 version of Java Thin Client.
>
> When I put data in the form List>,
> The size of the original 200KB data was increased to 50MB when inquired by
> Ignite servers.
> On the Heap Dump, the list element was repeatedly accumulated, increasing the
> data size.
>
> When I checked org.apacheignite.internal.binary.BinaryWriterExImpl.java
> doWriteBinaryObject() method,
> {code:java}
> // org.apacheignite.internal.binary.BinaryWriterExImpl.java
> public void doWriteBinaryObject(@Nullable BinaryObjectImpl po) {
> if (po == null)
> out.writeByte(GridBinaryMarshaller.NULL);
> else {
> byte[] poArr = po.array();
> out.unsafeEnsure(1 + 4 + poArr.length +4);
> out.unsafeWriteByte(GridBinaryMarshaller.BINARY_OBJ);
> out.unsafeWriteInt(poArr.length);
> out.writeByteArray(poArr);
> out.unsafeWriteInt(po.start());
> }
> }
> {code}
>
> The current Ignite implementation for storing data in the form
> List> is:
> In the Marshalling stage, for example, data the size of List(5
> members) is:
> As many as 10*5 of the list's elements are duplicated.
> If the above data contains five objects of 200KB size, ten by one,
> 50 iterations are stored and 200K*10**5 = 100MB of data is used for cache and
> transfer.
> As a result of this increase in data size, it is confirmed that the failure
> of OOM, GC, etc. is caused by occupying Heap memory.
> Unnecessarily redundant data is used for cache storage and network transport.
> When looking up cache data, only some of the data at the top is read based on
> file location information from the entire data, so that normal data is
> retrieved.
> The way we're implemented today is safe from basic behavior, but we're
> wasting memory and network unnecessarily using inefficient algorithms
> This can have very serious consequences. Please check.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12746) Regression in GridCacheColocatedDebugTest: putAll of sorted keys causes deadlock
[ https://issues.apache.org/jira/browse/IGNITE-12746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-12746: Release Note: Fixed bug in transaction thread chaining mechanism that possibly could cause deadlock on concurrent putAll scenarios > Regression in GridCacheColocatedDebugTest: putAll of sorted keys causes > deadlock > > > Key: IGNITE-12746 > URL: https://issues.apache.org/jira/browse/IGNITE-12746 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ilya Kasnacheev >Assignee: Ivan Rakov >Priority: Blocker > Fix For: 2.8.1 > > Time Spent: 20m > Remaining Estimate: 0h > > After this commit: > 7d4bb49264b IGNITE-12329 Invalid handling of remote entries causes partition > desync and transaction hanging in COMMITTING state. > the following tests: > org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedColocated > org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheColocatedDebugTest#testPutsMultithreadedMixed > started to be flaky because their ordered putAll operations started > deadlocking. > This is a regression compared to 2.7 and should be fixed, since it may affect > production clusters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12789) Tracking page repairing has no WAL record associated with it
[
https://issues.apache.org/jira/browse/IGNITE-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061485#comment-17061485
]
Ignite TC Bot commented on IGNITE-12789:
{panel:title=Branch: [pull/7537/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5131029&buildTypeId=IgniteTests24Java8_RunAll]
> Tracking page repairing has no WAL record associated with it
>
>
> Key: IGNITE-12789
> URL: https://issues.apache.org/jira/browse/IGNITE-12789
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO#resetCorruptFlag(long)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12799) Set right SpEL at Spring Data tests
[
https://issues.apache.org/jira/browse/IGNITE-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chernolyas updated IGNITE-12799:
---
Description: PersonExpressionRepository uses SpEL
"@cacheNames.personCacheName". It is wrong. SpEL
"#\{cacheNames.personCacheName}" must be used.
> Set right SpEL at Spring Data tests
> ---
>
> Key: IGNITE-12799
> URL: https://issues.apache.org/jira/browse/IGNITE-12799
> Project: Ignite
> Issue Type: Bug
> Components: spring
>Affects Versions: 2.8.1
>Reporter: Sergey Chernolyas
>Assignee: Sergey Chernolyas
>Priority: Trivial
> Fix For: 2.8.1
>
>
> PersonExpressionRepository uses SpEL "@cacheNames.personCacheName". It is
> wrong. SpEL "#\{cacheNames.personCacheName}" must be used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12799) Set right SpEL at Spring Data tests
[ https://issues.apache.org/jira/browse/IGNITE-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chernolyas updated IGNITE-12799: --- Summary: Set right SpEL at Spring Data tests (was: Set right SpEL at test) > Set right SpEL at Spring Data tests > --- > > Key: IGNITE-12799 > URL: https://issues.apache.org/jira/browse/IGNITE-12799 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.8.1 >Reporter: Sergey Chernolyas >Assignee: Sergey Chernolyas >Priority: Trivial > Fix For: 2.8.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12799) Set right SpEL at test
Sergey Chernolyas created IGNITE-12799: -- Summary: Set right SpEL at test Key: IGNITE-12799 URL: https://issues.apache.org/jira/browse/IGNITE-12799 Project: Ignite Issue Type: Bug Components: spring Affects Versions: 2.8.1 Reporter: Sergey Chernolyas Assignee: Sergey Chernolyas Fix For: 2.8.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12766) Node startup can be broken in case of using Local cache with persistence enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061465#comment-17061465
]
Ignite TC Bot commented on IGNITE-12766:
{panel:title=Branch: [pull/7534/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5131508&buildTypeId=IgniteTests24Java8_RunAll]
> Node startup can be broken in case of using Local cache with persistence
> enabled.
> -
>
> Key: IGNITE-12766
> URL: https://issues.apache.org/jira/browse/IGNITE-12766
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to upgrade from the previous version of Apache Ignite (AI 2.7.6 for
> example) may result in the following exception when Local cache is used and
> persistence enabled.
> {code}
> [2020-03-05 16:47:39,222][ERROR][main][IgniteKernal] Exception during start
> processors, node will be stopped and close connections[2020-03-05
> 16:47:39,222][ERROR][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: An error occurred during cache
> configuration loading from file [file=...] at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:965)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:907)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:171)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCacheConfigurations(GridLocalConfigManager.java:124)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5198)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:488)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:824)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5378)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1286) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2054)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1704)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659) at
> org.apache.ignite.Ignition.start(Ignition.java:346) at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:38)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to find class
> with given class loader for unmarshalling (make sure same versions of all
> classes are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:129)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:961)
> ... 18 moreCaused by: java.lang.ClassNotFoundException:
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
> java.lang.Class.forName0(Native Method) at
> java.lang.Class.forName(Class.java:348) at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8870) at
> org.apach
[jira] [Commented] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061464#comment-17061464 ] RangerZhou commented on IGNITE-12798: - Reprodece steps: # bin/ignite.sh # Ignition.start() in IDEA and execute continuous query: cache.query(qry) > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > But if I start server node by java code in IDEA ( Ignition.start() ), the > continuous query is ok. > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RangerZhou updated IGNITE-12798: Description: I start ignite server by ./ignite.sh, start a ignite client by java code, and execute a continuous query with java in IDEA, but exception like this: Exception in thread "main" javax.cache.CacheException: Failed to start continuous query. Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener But if I start server node by java code in IDEA ( Ignition.start() ), the continuous query is ok. My client code as below: !TOFListener.png! The exception screenshots: !Exception01.png! !Exception02.png! !Exception03.png! The exception uploaded the attachment was: I start ignite server by ./ignite.sh, start a ignite client by java code, and execute a continuous query with java in IDEA, but exception like this: Exception in thread "main" javax.cache.CacheException: Failed to start continuous query. Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener My client code as below: !TOFListener.png! The exception screenshots: !Exception01.png! !Exception02.png! !Exception03.png! The exception uploaded the attachment > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > But if I start server node by java code in IDEA ( Ignition.start() ), the > continuous query is ok. > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RangerZhou updated IGNITE-12798: Attachment: Exception02.png > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > My client code as below: > > !TOFListener.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RangerZhou updated IGNITE-12798: Attachment: Exception01.png > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > My client code as below: > > !TOFListener.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RangerZhou updated IGNITE-12798: Attachment: Exception03.png > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > My client code as below: > > !TOFListener.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RangerZhou updated IGNITE-12798: Description: I start ignite server by ./ignite.sh, start a ignite client by java code, and execute a continuous query with java in IDEA, but exception like this: Exception in thread "main" javax.cache.CacheException: Failed to start continuous query. Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener My client code as below: !TOFListener.png! The exception screenshots: !Exception01.png! !Exception02.png! !Exception03.png! The exception uploaded the attachment was: I start ignite server by ./ignite.sh, start a ignite client by java code, and execute a continuous query with java in IDEA, but exception like this: Exception in thread "main" javax.cache.CacheException: Failed to start continuous query. Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener My client code as below: !TOFListener.png! The exception uploaded the attachment > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[
https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
RangerZhou updated IGNITE-12798:
Description:
I start ignite server by ./ignite.sh, start a ignite client by java code, and
execute a continuous query with java in IDEA, but exception like this:
Exception in thread "main" javax.cache.CacheException: Failed to start
continuous query.
Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener
My client code as below:
!TOFListener.png!
The exception uploaded the attachment
was:
I start ignite server by ./ignite.sh, start a ignite client by java code, and
execute a continuous query with java in IDEA, but exception like this:
Exception in thread "main" javax.cache.CacheException: Failed to start
continuous query.
Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener
My client code as below:
public class TOFListener {
public static void main(String[] args) {
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setClientMode(true);
Ignite ignite = Ignition.start(cfg);
IgniteCache cache = ignite.getOrCreateCache("TOFCache");
// Creating a continuous query.
ContinuousQuery qry = new ContinuousQuery<>();
qry.setInitialQuery(new ScanQuery<>((k, v) -> "name".equals(k) ||
"shoulderWidthStdDev".equals(k)));
qry.setLocalListener((evts) -> evts.forEach(e ->
System.out.println("UpdatedValue, [key=" + e.getKey() + ", val=" +
e.getValue() + "]")));
qry.setRemoteFilterFactory(() -> evts -> evts.getKey().equals("name") ||
evts.getKey().equals("shoulderWidthStdDev"));
QueryCursor> cursor = cache.query(qry);
}
}
The exception uploaded the attachment
> Failed to start continuous query when use client node in IDEA
> -
>
> Key: IGNITE-12798
> URL: https://issues.apache.org/jira/browse/IGNITE-12798
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: RangerZhou
>Priority: Major
> Attachments: Exception.log, TOFListener.png
>
>
> I start ignite server by ./ignite.sh, start a ignite client by java code, and
> execute a continuous query with java in IDEA, but exception like this:
> Exception in thread "main" javax.cache.CacheException: Failed to start
> continuous query.
> Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener
> My client code as below:
>
> !TOFListener.png!
> The exception uploaded the attachment
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[
https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
RangerZhou updated IGNITE-12798:
Attachment: TOFListener.png
> Failed to start continuous query when use client node in IDEA
> -
>
> Key: IGNITE-12798
> URL: https://issues.apache.org/jira/browse/IGNITE-12798
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: RangerZhou
>Priority: Major
> Attachments: Exception.log, TOFListener.png
>
>
> I start ignite server by ./ignite.sh, start a ignite client by java code, and
> execute a continuous query with java in IDEA, but exception like this:
> Exception in thread "main" javax.cache.CacheException: Failed to start
> continuous query.
> Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener
> My client code as below:
> public class TOFListener {
> public static void main(String[] args) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setClientMode(true);
> Ignite ignite = Ignition.start(cfg);
> IgniteCache cache = ignite.getOrCreateCache("TOFCache");
> // Creating a continuous query.
> ContinuousQuery qry = new ContinuousQuery<>();
> qry.setInitialQuery(new ScanQuery<>((k, v) -> "name".equals(k) ||
> "shoulderWidthStdDev".equals(k)));
> qry.setLocalListener((evts) -> evts.forEach(e ->
> System.out.println("UpdatedValue, [key=" + e.getKey() + ", val=" +
> e.getValue() + "]")));
> qry.setRemoteFilterFactory(() -> evts -> evts.getKey().equals("name") ||
> evts.getKey().equals("shoulderWidthStdDev"));
> QueryCursor> cursor = cache.query(qry);
> }
> }
>
> The exception uploaded the attachment
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
RangerZhou created IGNITE-12798:
---
Summary: Failed to start continuous query when use client node in
IDEA
Key: IGNITE-12798
URL: https://issues.apache.org/jira/browse/IGNITE-12798
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.7.6
Reporter: RangerZhou
Attachments: Exception.log
I start ignite server by ./ignite.sh, start a ignite client by java code, and
execute a continuous query with java in IDEA, but exception like this:
Exception in thread "main" javax.cache.CacheException: Failed to start
continuous query.
Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener
My client code as below:
public class TOFListener {
public static void main(String[] args) {
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setClientMode(true);
Ignite ignite = Ignition.start(cfg);
IgniteCache cache = ignite.getOrCreateCache("TOFCache");
// Creating a continuous query.
ContinuousQuery qry = new ContinuousQuery<>();
qry.setInitialQuery(new ScanQuery<>((k, v) -> "name".equals(k) ||
"shoulderWidthStdDev".equals(k)));
qry.setLocalListener((evts) -> evts.forEach(e ->
System.out.println("UpdatedValue, [key=" + e.getKey() + ", val=" +
e.getValue() + "]")));
qry.setRemoteFilterFactory(() -> evts -> evts.getKey().equals("name") ||
evts.getKey().equals("shoulderWidthStdDev"));
QueryCursor> cursor = cache.query(qry);
}
}
The exception uploaded the attachment
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
