[jira] [Commented] (IGNITE-21599) Detect AI2 running and add an error to the log
[ https://issues.apache.org/jira/browse/IGNITE-21599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820064#comment-17820064 ] Stephen Darlington commented on IGNITE-21599: - I'm not sure we need to explicitly check for AI2, but we do need better errors. Like, is the underlying cause that we can't bind to port 10800 (thin-client for both AI2 and 3) or something similar? > Detect AI2 running and add an error to the log > -- > > Key: IGNITE-21599 > URL: https://issues.apache.org/jira/browse/IGNITE-21599 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Priority: Major > Labels: ignite-3 > > Currently, it is impossible to run AI2 and AI3 in the same VM. If you try to > start AI3 node, it will stop without any specific error message for debugging > purpose. > We should check for AI2 so that users know why the node failed to start. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21599) Detect AI2 running and add an error to the log
[ https://issues.apache.org/jira/browse/IGNITE-21599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820063#comment-17820063 ] Stephen Darlington edited comment on IGNITE-21599 at 2/23/24 1:40 PM: -- Repro: # Start Ignite 2 node (with ignite.sh) # Start AI3 node (ignite3db start) # Initialise AI3 cluster # AI3 node dies There are a bunch of warnings, but the only error I see is: 2024-02-23 13:31:04:208 + [ERROR][%defaultNode%start-0][MetaStorageLeaderElectionListener] Unable to start Idle Safe Time scheduler was (Author: sdarlington): Repro: # Start Ignite 2 / GG 8 node (with ignite.sh) # Start GG9 node (ignite3db start) # Initialise GG9 cluster # GG9 node dies There are a bunch of warnings, but the only error I see is: 2024-02-23 13:31:04:208 + [ERROR][%defaultNode%start-0][MetaStorageLeaderElectionListener] Unable to start Idle Safe Time scheduler > Detect AI2 running and add an error to the log > -- > > Key: IGNITE-21599 > URL: https://issues.apache.org/jira/browse/IGNITE-21599 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Priority: Major > Labels: ignite-3 > > Currently, it is impossible to run AI2 and AI3 in the same VM. If you try to > start AI3 node, it will stop without any specific error message for debugging > purpose. > We should check for AI2 so that users know why the node failed to start. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-14891) Support Next Java LTS (Java 17)
[ https://issues.apache.org/jira/browse/IGNITE-14891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington resolved IGNITE-14891. - Fix Version/s: 2.13 Resolution: Fixed > Support Next Java LTS (Java 17) > --- > > Key: IGNITE-14891 > URL: https://issues.apache.org/jira/browse/IGNITE-14891 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kadaner >Priority: Major > Fix For: 2.13 > > > Next Java LTS is right around the corner and many projects already started > working on supporting it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20059) SpringBoot/Data extensions all use super-old, unsupported versions
Stephen Darlington created IGNITE-20059: --- Summary: SpringBoot/Data extensions all use super-old, unsupported versions Key: IGNITE-20059 URL: https://issues.apache.org/jira/browse/IGNITE-20059 Project: Ignite Issue Type: Improvement Components: extensions, spring, springdata Reporter: Stephen Darlington Assignee: Stephen Darlington All our Spring dependencies are very out of date. It's currently pointing to version 2.2.13, which hasn't been supported since late 2020. This is an obstacle to Ignite being added to the [Spring Initializr|https://github.com/spring-io/start.spring.io/issues/960]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19899) SpringBoot doesn't register autoconfigures
[ https://issues.apache.org/jira/browse/IGNITE-19899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-19899: Description: Newer versions of SpringBoot change how autoconfigurations can be found (basically from a file called spring.factory to one called AutoConfiguration.imports). Here SpringBoot documentation for more details: [Spring-Boot-3.0-Migration-Guide|https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#auto-configuration-files] (was: Newer versions of SpringBoot change how autoconfigurations can be found (basically from a file called spring.factory to one called AutoConfiguration.imports).) > SpringBoot doesn't register autoconfigures > -- > > Key: IGNITE-19899 > URL: https://issues.apache.org/jira/browse/IGNITE-19899 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 1.0 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > > Newer versions of SpringBoot change how autoconfigurations can be found > (basically from a file called spring.factory to one called > AutoConfiguration.imports). Here SpringBoot documentation for more details: > [Spring-Boot-3.0-Migration-Guide|https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#auto-configuration-files] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19899) SpringBoot doesn't register autoconfigures
Stephen Darlington created IGNITE-19899: --- Summary: SpringBoot doesn't register autoconfigures Key: IGNITE-19899 URL: https://issues.apache.org/jira/browse/IGNITE-19899 Project: Ignite Issue Type: Improvement Components: spring Affects Versions: 1.0 Reporter: Stephen Darlington Assignee: Stephen Darlington Newer versions of SpringBoot change how autoconfigurations can be found (basically from a file called spring.factory to one called AutoConfiguration.imports). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17603) onGet not triggered in Cache Interceptor
[
https://issues.apache.org/jira/browse/IGNITE-17603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598514#comment-17598514
]
Stephen Darlington commented on IGNITE-17603:
-
Also possibly related to IGNITE-1903 .
> onGet not triggered in Cache Interceptor
>
>
> Key: IGNITE-17603
> URL: https://issues.apache.org/jira/browse/IGNITE-17603
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.9.1
> Environment: Mac, Java 11
>Reporter: Stephen Darlington
>Priority: Major
>
> The onGet method in cache interceptors appears not to be called since version
> 2.9.0. Or at least, the API changed. I have the following code:
> CacheConfiguration cacheConfiguration = new
> CacheConfiguration<>();
> cacheConfiguration.setName("PERSON_CACHE");
> cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
> cacheConfiguration.setIndexedTypes(Long.class, Person.class);
> cacheConfiguration.setInterceptor(new CacheInterceptor Object>() \{
> @Override
> public Object onGet(Long aLong, Object p) {
> Person person = (Person)p;
> return new Person(new
> StringBuilder(person.getName()).reverse().toString(), person.getHeight());
> }
> @Override
> public Object onBeforePut(Cache.Entry entry, Object
> p) \{
> if (p.getClass().equals(Person.class)) {
> Person person = (Person)p;
> return new Person(new
> StringBuilder(person.getName()).reverse().toString(), person.getHeight());
> }
> else if (p.getClass().equals(BinaryObjectImpl.class)) \{
> BinaryObjectBuilder person = ((BinaryObject)
> p).toBuilder();
> String name = person.getField("name");
> person.setField("name", new
> StringBuilder(name).reverse().toString());
> return person.build();
> }
> else \{
> return null;
> }
> }
> @Override
> public void onAfterPut(Cache.Entry entry) \{
> // do nothing
> }
> @Override
> public IgniteBiTuple
> onBeforeRemove(Cache.Entry entry) \{
> return new IgniteBiTuple<>(true, entry.getValue());
> }
> @Override
> public void onAfterRemove(Cache.Entry entry) \{
> // do nothing
> }
> });
> It reverses the name before storing it and reverses it again on a get. In
> 2.9.0 this works as expected. In every version since it fails. It reverses
> the string on a put but the onGet method never gets called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17603) onGet not triggered in Cache Interceptor
[
https://issues.apache.org/jira/browse/IGNITE-17603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598513#comment-17598513
]
Stephen Darlington commented on IGNITE-17603:
-
Caused by / related to IGNITE-13417?
> onGet not triggered in Cache Interceptor
>
>
> Key: IGNITE-17603
> URL: https://issues.apache.org/jira/browse/IGNITE-17603
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.9.1
> Environment: Mac, Java 11
>Reporter: Stephen Darlington
>Priority: Major
>
> The onGet method in cache interceptors appears not to be called since version
> 2.9.0. Or at least, the API changed. I have the following code:
> CacheConfiguration cacheConfiguration = new
> CacheConfiguration<>();
> cacheConfiguration.setName("PERSON_CACHE");
> cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
> cacheConfiguration.setIndexedTypes(Long.class, Person.class);
> cacheConfiguration.setInterceptor(new CacheInterceptor Object>() \{
> @Override
> public Object onGet(Long aLong, Object p) {
> Person person = (Person)p;
> return new Person(new
> StringBuilder(person.getName()).reverse().toString(), person.getHeight());
> }
> @Override
> public Object onBeforePut(Cache.Entry entry, Object
> p) \{
> if (p.getClass().equals(Person.class)) {
> Person person = (Person)p;
> return new Person(new
> StringBuilder(person.getName()).reverse().toString(), person.getHeight());
> }
> else if (p.getClass().equals(BinaryObjectImpl.class)) \{
> BinaryObjectBuilder person = ((BinaryObject)
> p).toBuilder();
> String name = person.getField("name");
> person.setField("name", new
> StringBuilder(name).reverse().toString());
> return person.build();
> }
> else \{
> return null;
> }
> }
> @Override
> public void onAfterPut(Cache.Entry entry) \{
> // do nothing
> }
> @Override
> public IgniteBiTuple
> onBeforeRemove(Cache.Entry entry) \{
> return new IgniteBiTuple<>(true, entry.getValue());
> }
> @Override
> public void onAfterRemove(Cache.Entry entry) \{
> // do nothing
> }
> });
> It reverses the name before storing it and reverses it again on a get. In
> 2.9.0 this works as expected. In every version since it fails. It reverses
> the string on a put but the onGet method never gets called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17603) onGet not triggered in Cache Interceptor
Stephen Darlington created IGNITE-17603:
---
Summary: onGet not triggered in Cache Interceptor
Key: IGNITE-17603
URL: https://issues.apache.org/jira/browse/IGNITE-17603
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.9.1
Environment: Mac, Java 11
Reporter: Stephen Darlington
The onGet method in cache interceptors appears not to be called since version
2.9.0. Or at least, the API changed. I have the following code:
CacheConfiguration cacheConfiguration = new
CacheConfiguration<>();
cacheConfiguration.setName("PERSON_CACHE");
cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cacheConfiguration.setIndexedTypes(Long.class, Person.class);
cacheConfiguration.setInterceptor(new CacheInterceptor()
\{
@Override
public Object onGet(Long aLong, Object p) {
Person person = (Person)p;
return new Person(new
StringBuilder(person.getName()).reverse().toString(), person.getHeight());
}
@Override
public Object onBeforePut(Cache.Entry entry, Object
p) \{
if (p.getClass().equals(Person.class)) {
Person person = (Person)p;
return new Person(new
StringBuilder(person.getName()).reverse().toString(), person.getHeight());
}
else if (p.getClass().equals(BinaryObjectImpl.class)) \{
BinaryObjectBuilder person = ((BinaryObject) p).toBuilder();
String name = person.getField("name");
person.setField("name", new
StringBuilder(name).reverse().toString());
return person.build();
}
else \{
return null;
}
}
@Override
public void onAfterPut(Cache.Entry entry) \{
// do nothing
}
@Override
public IgniteBiTuple
onBeforeRemove(Cache.Entry entry) \{
return new IgniteBiTuple<>(true, entry.getValue());
}
@Override
public void onAfterRemove(Cache.Entry entry) \{
// do nothing
}
});
It reverses the name before storing it and reverses it again on a get. In 2.9.0
this works as expected. In every version since it fails. It reverses the string
on a put but the onGet method never gets called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-10647) Spark example code potentially confusing
[ https://issues.apache.org/jira/browse/IGNITE-10647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington reassigned IGNITE-10647: --- Assignee: (was: Stephen Darlington) > Spark example code potentially confusing > > > Key: IGNITE-10647 > URL: https://issues.apache.org/jira/browse/IGNITE-10647 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Stephen Darlington >Priority: Minor > > This started with a [question on Stack > Overflow|https://stackoverflow.com/questions/53704478/apache-ignite-spark-dataframes-client-vs-server-doubts/53704993#53704993]. > In short, the user copy-and-pasted the whole sample code over, without > realising that in addition to firing up a Spark client it also runs an Ignite > server. > The advantage of this is obviously that the code is entirely self-contained. > However, there's little to suggest what's going on in the code, which bits > are just setting stuff up and which bits are actually demonstrating the Spark > integration. > Maybe there's a way to restructure it to make it clearer? Or a few extra > comments? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-14326) Resetting Ignite cache entry TTL
[
https://issues.apache.org/jira/browse/IGNITE-14326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington reassigned IGNITE-14326:
---
Assignee: (was: Stephen Darlington)
> Resetting Ignite cache entry TTL
>
>
> Key: IGNITE-14326
> URL: https://issues.apache.org/jira/browse/IGNITE-14326
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Stephen Darlington
>Priority: Major
> Labels: cggg
> Original Estimate: 64h
> Remaining Estimate: 64h
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to refresh the TTL without first retrieving the record, which
> is slow and resource consuming if an entry is large.
> Provide a method to reset Ignite cache entry TTL.
> Suggested API (to be discussed with community):
> {{IgniteCache#touch(key)}}: resets the TTL using the latest TTL value or does
> nothing if no TTL was specified for the key.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17245) AbstractContinuousQuery.setIncludeExpired does not return this
Title: Message Title Stephen Darlington assigned an issue to Stephen Darlington Ignite / IGNITE-17245 AbstractContinuousQuery.setIncludeExpired does not return this Change By: Stephen Darlington Assignee: Stephen Darlington Add Comment This message was sent by Atlassian Jira (v8.20.10#820010-sha1:ace47f9)
[jira] [Resolved] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington resolved IGNITE-8618. Resolution: Won't Fix Support for Java 17 was added in 2.13. Java 10 is old and not an LTS version. > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IGNITE-10097) Document how to disable self-registration on Web Console
[ https://issues.apache.org/jira/browse/IGNITE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington resolved IGNITE-10097. - Resolution: Won't Fix The community is no longer supporting the Web Console. > Document how to disable self-registration on Web Console > > > Key: IGNITE-10097 > URL: https://issues.apache.org/jira/browse/IGNITE-10097 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Kuznetsov >Assignee: Artem Budnikov >Priority: Major > > See IGNITE-9941 for details > Sample commands: > For Web Console Docker standalone image: > docker run -e "server_disable_signup=true" -p 9090:80 _docker_image_id_ > For Web Console Direct install for Linux: > ./web-console-linux --server:disable:signup true --server:port 30005 > > If self registration disabled, Admin can create accounts in "Admin panel" > screen with "Actions -> Add user". > E-mail with link to reset password to new account will be e-mailed to User. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-13065) Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read property 'length' of null
[ https://issues.apache.org/jira/browse/IGNITE-13065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington resolved IGNITE-13065. - Resolution: Won't Fix The community is no longer supporting the Web Console. > Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read > property 'length' of null > - > > Key: IGNITE-13065 > URL: https://issues.apache.org/jira/browse/IGNITE-13065 > Project: Ignite > Issue Type: Bug >Reporter: david >Priority: Critical > > Hi, > I am using docker to host the web console and have pulled the latest image > from docker. I have upgraded my ignite server to 2.8.0 but co no longer > perform scans of my cache > > Has a new docker image for the web console been pushed to docker to support > ignite 2.8.0? > > thank you > David -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-12007) Latest "apacheignite/web-console-backend" docker image is broken
[
https://issues.apache.org/jira/browse/IGNITE-12007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington resolved IGNITE-12007.
-
Resolution: Won't Fix
The community is no longer supporting Web Console.
> Latest "apacheignite/web-console-backend" docker image is broken
>
>
> Key: IGNITE-12007
> URL: https://issues.apache.org/jira/browse/IGNITE-12007
> Project: Ignite
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.7
>Reporter: Igor Belyakov
>Priority: Critical
>
> It's not possible to run docker container by using the latest version of
> "apacheignite/web-console-backend" image.
> Next error happens on the start:
> {code:java}
> npm ERR! A complete log of this run can be found in:
> npm ERR! /root/.npm/_logs/2019-07-23T14_24_40_353Z-debug.log
> npm ERR! path /opt/web-console/package.json
> npm ERR! code ENOENT
> npm ERR! errno -2
> npm ERR! syscall open
> npm ERR! enoent ENOENT: no such file or directory, open
> '/opt/web-console/package.json'
> npm ERR! enoent This is related to npm not being able to find a file.
> npm ERR! enoent{code}
> How to reproduce:
> Run container by using docker-compose as described here:
> [https://hub.docker.com/r/apacheignite/web-console-backend]
>
> Seems like it was broken by the next commit:
> [https://github.com/apache/ignite/commit/4c295f8f468ddfce458948c17c13b1748b13e918#diff-ec0d595d738c4207e08ce210624e902aR22]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16449) Crash when using cache with SQL On-Heap Cache
[
https://issues.apache.org/jira/browse/IGNITE-16449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486337#comment-17486337
]
Stephen Darlington commented on IGNITE-16449:
-
Updated with a simpler reproducer. It's not an issue with the cache store, it's
purely with the SQL On Heap Cache.
> Crash when using cache with SQL On-Heap Cache
> -
>
> Key: IGNITE-16449
> URL: https://issues.apache.org/jira/browse/IGNITE-16449
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.11, 2.12, 2.11.1
> Environment: Java 11
>Reporter: Stephen Darlington
>Priority: Major
> Attachments: cachestore-btree-1.zip
>
>
> If you enable the on-heap SQL cache and use the cache-store, you get a B+
> Tree corruption error.
> {{SEVERE: JVM will be halted immediately due to the failure:
> [failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=-1938387115,
> val2=844420635166791]], cacheId=-1938387115, cacheName=PERSON,
> indexName=PERSON_HEIGHT_IDX, msg=Runtime failure on row: Row@33647615[ key:
> -9203523458338071405, val: CacheStoreServer$Person [idHash=1063096745,
> hash=-1708653899, name=Name 32047, height=177, this$0=null] ][ }}
> Find attached a reproducer.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16449) Crash when using cache with SQL On-Heap Cache
[
https://issues.apache.org/jira/browse/IGNITE-16449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-16449:
Attachment: cachestore-btree-1.zip
Description:
If you enable the on-heap SQL cache and use the cache-store, you get a B+ Tree
corruption error.
{{SEVERE: JVM will be halted immediately due to the failure:
[failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=-1938387115,
val2=844420635166791]], cacheId=-1938387115, cacheName=PERSON,
indexName=PERSON_HEIGHT_IDX, msg=Runtime failure on row: Row@33647615[ key:
-9203523458338071405, val: CacheStoreServer$Person [idHash=1063096745,
hash=-1708653899, name=Name 32047, height=177, this$0=null] ][ }}
Find attached a reproducer.
was:
If you enable the on-heap SQL cache and use the cache-store, you get a B+ Tree
corruption error.
{{SEVERE: JVM will be halted immediately due to the failure:
[failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=-1938387115,
val2=844420635166791]], cacheId=-1938387115, cacheName=PERSON,
indexName=PERSON_HEIGHT_IDX, msg=Runtime failure on row: Row@33647615[ key:
-9203523458338071405, val: CacheStoreServer$Person [idHash=1063096745,
hash=-1708653899, name=Name 32047, height=177, this$0=null] ][ }}
Find attached a reproducer. It appears to be a race condition, so you may need
to run it several times. Alternatively, you can add more data.
Summary: Crash when using cache with SQL On-Heap Cache (was: Crash
when using CacheStore with SQL On-Heap Cache)
> Crash when using cache with SQL On-Heap Cache
> -
>
> Key: IGNITE-16449
> URL: https://issues.apache.org/jira/browse/IGNITE-16449
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.11, 2.12, 2.11.1
> Environment: Java 11
>Reporter: Stephen Darlington
>Priority: Major
> Attachments: cachestore-btree-1.zip
>
>
> If you enable the on-heap SQL cache and use the cache-store, you get a B+
> Tree corruption error.
> {{SEVERE: JVM will be halted immediately due to the failure:
> [failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=-1938387115,
> val2=844420635166791]], cacheId=-1938387115, cacheName=PERSON,
> indexName=PERSON_HEIGHT_IDX, msg=Runtime failure on row: Row@33647615[ key:
> -9203523458338071405, val: CacheStoreServer$Person [idHash=1063096745,
> hash=-1708653899, name=Name 32047, height=177, this$0=null] ][ }}
> Find attached a reproducer.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16449) Crash when using cache with SQL On-Heap Cache
[
https://issues.apache.org/jira/browse/IGNITE-16449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-16449:
Attachment: (was: cachestore-btree.zip)
> Crash when using cache with SQL On-Heap Cache
> -
>
> Key: IGNITE-16449
> URL: https://issues.apache.org/jira/browse/IGNITE-16449
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.11, 2.12, 2.11.1
> Environment: Java 11
>Reporter: Stephen Darlington
>Priority: Major
> Attachments: cachestore-btree-1.zip
>
>
> If you enable the on-heap SQL cache and use the cache-store, you get a B+
> Tree corruption error.
> {{SEVERE: JVM will be halted immediately due to the failure:
> [failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=-1938387115,
> val2=844420635166791]], cacheId=-1938387115, cacheName=PERSON,
> indexName=PERSON_HEIGHT_IDX, msg=Runtime failure on row: Row@33647615[ key:
> -9203523458338071405, val: CacheStoreServer$Person [idHash=1063096745,
> hash=-1708653899, name=Name 32047, height=177, this$0=null] ][ }}
> Find attached a reproducer.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16449) Crash when using CacheStore with SQL On-Heap Cache
Stephen Darlington created IGNITE-16449:
---
Summary: Crash when using CacheStore with SQL On-Heap Cache
Key: IGNITE-16449
URL: https://issues.apache.org/jira/browse/IGNITE-16449
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.11.1, 2.11, 2.12
Environment: Java 11
Reporter: Stephen Darlington
Attachments: cachestore-btree.zip
If you enable the on-heap SQL cache and use the cache-store, you get a B+ Tree
corruption error.
{{SEVERE: JVM will be halted immediately due to the failure:
[failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=-1938387115,
val2=844420635166791]], cacheId=-1938387115, cacheName=PERSON,
indexName=PERSON_HEIGHT_IDX, msg=Runtime failure on row: Row@33647615[ key:
-9203523458338071405, val: CacheStoreServer$Person [idHash=1063096745,
hash=-1708653899, name=Name 32047, height=177, this$0=null] ][ }}
Find attached a reproducer. It appears to be a race condition, so you may need
to run it several times. Alternatively, you can add more data.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16293) Support multi-platform Docker images
[ https://issues.apache.org/jira/browse/IGNITE-16293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481692#comment-17481692 ] Stephen Darlington commented on IGNITE-16293: - We already support two architectures: x86-64 and s390x. Having said that, this ticket was prompted by someone looking for an ARM64 image for an Apple Silicon Mac. > Support multi-platform Docker images > > > Key: IGNITE-16293 > URL: https://issues.apache.org/jira/browse/IGNITE-16293 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Stephen Darlington >Priority: Major > > The current Docker image is only built for the x86-64 architecture. It would > be good to have multi-architecture support. [This > blog|https://www.docker.com/blog/multi-platform-docker-builds/] explains how > (basically a second build and a "manifest"). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16293) Support multi-platform Docker images
Stephen Darlington created IGNITE-16293: --- Summary: Support multi-platform Docker images Key: IGNITE-16293 URL: https://issues.apache.org/jira/browse/IGNITE-16293 Project: Ignite Issue Type: Improvement Components: build Reporter: Stephen Darlington The current Docker image is only built for the x86-64 architecture. It would be good to have multi-architecture support. [This blog|https://www.docker.com/blog/multi-platform-docker-builds/] explains how (basically a second build and a "manifest"). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-12923) web-* docker images on Docker Hub are out of date
[ https://issues.apache.org/jira/browse/IGNITE-12923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington resolved IGNITE-12923. - Resolution: Won't Fix > web-* docker images on Docker Hub are out of date > - > > Key: IGNITE-12923 > URL: https://issues.apache.org/jira/browse/IGNITE-12923 > Project: Ignite > Issue Type: Bug >Reporter: Zaar Hai >Priority: Major > Attachments: Selection_574.png > > > Good day, > Looking at DockerHub, web-agent and web-console-* docker image were updated > more than a year ago and there are no new images for Ignite 2.8.0. > It will be great if they can updated automatically with each new release of > Ignite. As it is now, one cann't have out-of-the-box web console for Ignite > 2.8.0 without either rebuilding docker images manually or residing to > GridGain centralized UI. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-12923) web-* docker images on Docker Hub are out of date
[ https://issues.apache.org/jira/browse/IGNITE-12923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474749#comment-17474749 ] Stephen Darlington commented on IGNITE-12923: - Web Console is no longer supported. > web-* docker images on Docker Hub are out of date > - > > Key: IGNITE-12923 > URL: https://issues.apache.org/jira/browse/IGNITE-12923 > Project: Ignite > Issue Type: Bug >Reporter: Zaar Hai >Priority: Major > Attachments: Selection_574.png > > > Good day, > Looking at DockerHub, web-agent and web-console-* docker image were updated > more than a year ago and there are no new images for Ignite 2.8.0. > It will be great if they can updated automatically with each new release of > Ignite. As it is now, one cann't have out-of-the-box web console for Ignite > 2.8.0 without either rebuilding docker images manually or residing to > GridGain centralized UI. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15960) Ignite#getOrCreateNearCache appears to be broken?
Stephen Darlington created IGNITE-15960:
---
Summary: Ignite#getOrCreateNearCache appears to be broken?
Key: IGNITE-15960
URL: https://issues.apache.org/jira/browse/IGNITE-15960
Project: Ignite
Issue Type: Bug
Affects Versions: 2.10
Reporter: Stephen Darlington
I have my Ignite server running a connect a thick-client running some code.
If I don't create any caches in advance and run this code:
{{client.getOrCreateNearCache(CACHE_NAME, new NearCacheConfiguration()}}
{{.setNearEvictionPolicyFactory(new LruEvictionPolicyFactory<>()));}}
The error I get is:
{{Failed to start client cache (a cache with the given name is not started)}}
Okay, so I create my cache in advance:
{{client.getOrCreateCache(CACHE_NAME);}}
{{client.getOrCreateNearCache(CACHE_NAME, new NearCacheConfiguration()}}
{{.setNearEvictionPolicyFactory(new LruEvictionPolicyFactory<>()));}}
This time I get the following error:
{{Failed to start near cache (a cache with the same name without near cache is
already started)}}
Okay, so I'll create a cache with a near cache:
{{client.getOrCreateCache(new CacheConfiguration<>()}}
{{.setName(CACHE_NAME)}}
{{.setNearConfiguration(new NearCacheConfiguration()}}
{{.setNearEvictionPolicyFactory(new LruEvictionPolicyFactory<>(;}}
{{client.getOrCreateNearCache(CACHE_NAME, new NearCacheConfiguration()}}
{{.setNearEvictionPolicyFactory(new LruEvictionPolicyFactory<>()));}}
Still the same error:
{{Failed to start near cache (a cache with the same name without near cache is
already started)}}
So however the cache is created or configured, it appears not to work.
One possibility is that it's only supposed to work on a server where the near
cache already exists. If so, this is not mentioned anywhere in the
documentation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-14750) NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
[
https://issues.apache.org/jira/browse/IGNITE-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17349343#comment-17349343
]
Stephen Darlington commented on IGNITE-14750:
-
[~zstan], no, I don't know how it happened is the short version. They deleted
the files before I was able to see the directory structure. A Null Pointer
Exception here could be caused by it being a file rather than a directory.
Maxim suggests it could be a concurrency issue, which is also plausible. As far
as I can tell, File#listFiles() throws a SecurityException if it doesn't have
permission. "I don't know" isn't terribly satisfying, but that's why I improved
the error handling.
> NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
> --
>
> Key: IGNITE-14750
> URL: https://issues.apache.org/jira/browse/IGNITE-14750
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Minor
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Upgrading from Ignite 2.9 to 2.10, using persistence we got the following
> error on one node. The other nodes started correctly. Ended up deleting the
> persistence store and creating a new node.
> {{[2021-05-18 15:21:51,949][WARN ][main][MaintenanceProcessor] Caught
> exception when starting MaintenanceProcessor, maintenance mode won't be
> entered}}{{_java.lang.NullPointerException_}}{{_at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.visitFolder(PdsConsistentIdProcessor.java:246)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.folderSize(PdsConsistentIdProcessor.java:234)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.getPathDisplayableInfo(PdsConsistentIdProcessor.java:265)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:195)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1061)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:947)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:846)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:716)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:685)_}}{{
> _at org.apache.ignite.Ignition.start(Ignition.java:353)_}}{{_at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)_}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14750) NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
[
https://issues.apache.org/jira/browse/IGNITE-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348625#comment-17348625
]
Stephen Darlington commented on IGNITE-14750:
-
[~mmuzaf], there was only one node running on this machine so I don't think
that's likely. Also it repeatedly only failed on this one node. I think the
pattern you suggest would be a bit more random.
Having said that, what you suggest does sound possible. There's always going to
be a race condition between finding the folder and getting the list of
files/folders in it. Maybe it would make sense just to catch the null pointer
exception.
> NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
> --
>
> Key: IGNITE-14750
> URL: https://issues.apache.org/jira/browse/IGNITE-14750
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Minor
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Upgrading from Ignite 2.9 to 2.10, using persistence we got the following
> error on one node. The other nodes started correctly. Ended up deleting the
> persistence store and creating a new node.
> {{[2021-05-18 15:21:51,949][WARN ][main][MaintenanceProcessor] Caught
> exception when starting MaintenanceProcessor, maintenance mode won't be
> entered}}{{_java.lang.NullPointerException_}}{{_at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.visitFolder(PdsConsistentIdProcessor.java:246)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.folderSize(PdsConsistentIdProcessor.java:234)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.getPathDisplayableInfo(PdsConsistentIdProcessor.java:265)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:195)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1061)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:947)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:846)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:716)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:685)_}}{{
> _at org.apache.ignite.Ignition.start(Ignition.java:353)_}}{{_at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)_}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14750) NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
[
https://issues.apache.org/jira/browse/IGNITE-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348560#comment-17348560
]
Stephen Darlington commented on IGNITE-14750:
-
Basically, [this
code|https://github.com/apache/ignite/blob/22af51e366acb4721122fec4249fac215234dd42/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/filename/PdsConsistentIdProcessor.java#L246]
assumes that a path is a directory based on the result of a predicate... but
it turns out to be a file. I'm not clear how this could happen – and the files
have now been deleted – but the cause is clear
> NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
> --
>
> Key: IGNITE-14750
> URL: https://issues.apache.org/jira/browse/IGNITE-14750
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Minor
>
> Upgrading from Ignite 2.9 to 2.10, using persistence we got the following
> error on one node. The other nodes started correctly. Ended up deleting the
> persistence store and creating a new node.
> {{[2021-05-18 15:21:51,949][WARN ][main][MaintenanceProcessor] Caught
> exception when starting MaintenanceProcessor, maintenance mode won't be
> entered}}{{_java.lang.NullPointerException_}}{{_at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.visitFolder(PdsConsistentIdProcessor.java:246)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.folderSize(PdsConsistentIdProcessor.java:234)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.getPathDisplayableInfo(PdsConsistentIdProcessor.java:265)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:195)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1061)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:947)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:846)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:716)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:685)_}}{{
> _at org.apache.ignite.Ignition.start(Ignition.java:353)_}}{{_at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)_}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14750) NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
Stephen Darlington created IGNITE-14750:
---
Summary: NullPointerException when starting MaintenanceProcessor
after upgrade from 2.9
Key: IGNITE-14750
URL: https://issues.apache.org/jira/browse/IGNITE-14750
Project: Ignite
Issue Type: Bug
Affects Versions: 2.10
Reporter: Stephen Darlington
Assignee: Stephen Darlington
Upgrading from Ignite 2.9 to 2.10, using persistence we got the following error
on one node. The other nodes started correctly. Ended up deleting the
persistence store and creating a new node.
{{[2021-05-18 15:21:51,949][WARN ][main][MaintenanceProcessor] Caught exception
when starting MaintenanceProcessor, maintenance mode won't be
entered}}{{_java.lang.NullPointerException_}}{{_at
org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.visitFolder(PdsConsistentIdProcessor.java:246)_}}{{
_at
org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.folderSize(PdsConsistentIdProcessor.java:234)_}}{{
_at
org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.getPathDisplayableInfo(PdsConsistentIdProcessor.java:265)_}}{{
_at
org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:195)_}}{{
_at
org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)_}}{{
_at
org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)_}}{{
_at
org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)_}}{{
_at
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)_}}{{
_at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)_}}{{
_at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)_}}{{
_at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)_}}{{
_at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)_}}{{
_at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1061)_}}{{
_at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:947)_}}{{
_at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:846)_}}{{
_at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:716)_}}{{
_at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:685)_}}{{
_at org.apache.ignite.Ignition.start(Ignition.java:353)_}}{{_at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)_}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7641) Add CacheEntry#ttl method
[
https://issues.apache.org/jira/browse/IGNITE-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322324#comment-17322324
]
Stephen Darlington commented on IGNITE-7641:
Hi [~slava.koptilin], I understand that you're a good person to look at this PR?
> Add CacheEntry#ttl method
> -
>
> Key: IGNITE-7641
> URL: https://issues.apache.org/jira/browse/IGNITE-7641
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Stephen Darlington
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to know the current TTL for a particular key.
> We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
> will provide this information. Looks like it's already available via
> {{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
> API.
> Here is the user forum discussion about this:
> http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14326) Add CacheEntry#setTtl method
[
https://issues.apache.org/jira/browse/IGNITE-14326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-14326:
Description:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
_setting_ the TTL.
The API for this is less well defined than the get TTL method. Suggest a number
of options:
* Update using the default TTL policy
* Update using a specified long
* Update using a specified Expiry policy
was:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
_setting_ the TTL.
We can add {{CacheEntry#setTtl()}} and/or {{IgniteCache#setTtl(K key)}} method
that will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
[http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
> Add CacheEntry#setTtl method
>
>
> Key: IGNITE-14326
> URL: https://issues.apache.org/jira/browse/IGNITE-14326
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to know the current TTL for a particular key or refresh the
> TTL without first retrieving the record.
> Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
> _setting_ the TTL.
> The API for this is less well defined than the get TTL method. Suggest a
> number of options:
> * Update using the default TTL policy
> * Update using a specified long
> * Update using a specified Expiry policy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14326) Add CacheEntry#setTtl method
[
https://issues.apache.org/jira/browse/IGNITE-14326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-14326:
Description:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
_setting_ the TTL.
We can add {{CacheEntry#setTtl()}} and/or {{IgniteCache#setTtl(K key)}} method
that will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
[http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
was:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket
We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
[http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
> Add CacheEntry#setTtl method
>
>
> Key: IGNITE-14326
> URL: https://issues.apache.org/jira/browse/IGNITE-14326
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to know the current TTL for a particular key or refresh the
> TTL without first retrieving the record.
> Ticket IGNITE-7641 details the IgniteCache#ttl() method. This ticket is about
> _setting_ the TTL.
> We can add {{CacheEntry#setTtl()}} and/or {{IgniteCache#setTtl(K key)}}
> method that will provide this information. Looks like it's already available
> via {{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to
> public API.
> Here is the user forum discussion about this:
> [http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14326) Add CacheEntry#setTtl method
[
https://issues.apache.org/jira/browse/IGNITE-14326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-14326:
Description:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key or refresh the TTL
without first retrieving the record.
Ticket
We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
[http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
was:
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key.
We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html
> Add CacheEntry#setTtl method
>
>
> Key: IGNITE-14326
> URL: https://issues.apache.org/jira/browse/IGNITE-14326
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to know the current TTL for a particular key or refresh the
> TTL without first retrieving the record.
> Ticket
> We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
> will provide this information. Looks like it's already available via
> {{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
> API.
> Here is the user forum discussion about this:
> [http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14326) Add CacheEntry#setTtl method
Stephen Darlington created IGNITE-14326:
---
Summary: Add CacheEntry#setTtl method
Key: IGNITE-14326
URL: https://issues.apache.org/jira/browse/IGNITE-14326
Project: Ignite
Issue Type: Improvement
Components: cache
Affects Versions: 2.3
Reporter: Stephen Darlington
Assignee: Stephen Darlington
Ignite provides a way to specify an expiry policy on per entry level, but there
is no way to know the current TTL for a particular key.
We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
will provide this information. Looks like it's already available via
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
API.
Here is the user forum discussion about this:
http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17295120#comment-17295120 ] Stephen Darlington commented on IGNITE-12192: - Not sure what the status of this ticket should be, but it _is_ in [2.10|https://github.com/apache/ignite/blob/ignite-2.10/modules/visor-console/src/main/scala/org/apache/ignite/visor/commands/VisorConsole.scala#L258], [~mmuzaf], so I switched the tag back. > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-12192: Fix Version/s: (was: 2.11) 2.10 > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-11553) Ignite metrics to Prometheus.io
[ https://issues.apache.org/jira/browse/IGNITE-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington resolved IGNITE-11553. - Resolution: Won't Fix With the OpenCensus module now included, explicit Prometheus support isn't necessary. > Ignite metrics to Prometheus.io > --- > > Key: IGNITE-11553 > URL: https://issues.apache.org/jira/browse/IGNITE-11553 > Project: Ignite > Issue Type: New Feature >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > It would be nice if Ignite could send its metrics (or at least some of them) > to [Prometheus|https://prometheus.io] metrics and alerting system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-12192: Fix Version/s: 2.10 > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14220) Shuffle server addresses for thin clients
Stephen Darlington created IGNITE-14220: --- Summary: Shuffle server addresses for thin clients Key: IGNITE-14220 URL: https://issues.apache.org/jira/browse/IGNITE-14220 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 2.9.1 Reporter: Stephen Darlington To connect to a grid from a thin-client, we provide a list of servers and ports. If partition awareness is disabled, Ignite connects to the first node. In the case where there are lots of thin clients, they all end up connecting to the same server node. This is improved somewhat when partition awareness is enabled. JCache requests go directly to the data node in question. But SQL queries will all be sent to the same node (since the algorithm is deterministic). If the list were "shuffled" before use, the load would end up balanced across the cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-7641) Add CacheEntry#ttl method
[
https://issues.apache.org/jira/browse/IGNITE-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington reassigned IGNITE-7641:
--
Assignee: Stephen Darlington
> Add CacheEntry#ttl method
> -
>
> Key: IGNITE-7641
> URL: https://issues.apache.org/jira/browse/IGNITE-7641
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Stephen Darlington
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to know the current TTL for a particular key.
> We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that
> will provide this information. Looks like it's already available via
> {{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public
> API.
> Here is the user forum discussion about this:
> http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14067) CREATE TABLE with template doesn't use isEncryptionEnabled flag
Stephen Darlington created IGNITE-14067:
---
Summary: CREATE TABLE with template doesn't use
isEncryptionEnabled flag
Key: IGNITE-14067
URL: https://issues.apache.org/jira/browse/IGNITE-14067
Project: Ignite
Issue Type: Bug
Components: cache, sql
Affects Versions: 2.9.1, 2.8.1, 2.9
Reporter: Stephen Darlington
Assignee: Stephen Darlington
If I create a cache template:
{{CacheConfiguration encryptedCacheTemplate = new CacheConfiguration();}}
{{encryptedCacheTemplate.setName("EncryptedCacheTemplate")}}
{{ .setEncryptionEnabled(true)}}
{{ .setBackups(1)}}
{{ .setCacheMode(CacheMode.PARTITIONED);}}
{{ignite.addCacheConfiguration(encryptedCacheTemplate);}}
And then try to use it:
{{create table ignite_enc (id long primary key, name varchar) with
"template=EncryptedCacheTemplate";}}
The encryption setting is not used.
Workaround: specify the encryption flag "manually":
{{create table ignite_enc2 (id long primary key, name varchar) with
"template=EncryptedCacheTemplate,encrypted=true"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14067) CREATE TABLE with template doesn't use isEncryptionEnabled flag
[
https://issues.apache.org/jira/browse/IGNITE-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-14067:
Description:
If I create a cache template:
{{CacheConfiguration encryptedCacheTemplate = new CacheConfiguration();}}
{{encryptedCacheTemplate.setName("EncryptedCacheTemplate")}}
{{.setEncryptionEnabled(true)}}
{{.setBackups(1)}}
{{.setCacheMode(CacheMode.PARTITIONED);}}
{{ignite.addCacheConfiguration(encryptedCacheTemplate);}}
And then try to use it:
{{create table ignite_enc (id long primary key, name varchar) with
"template=EncryptedCacheTemplate";}}
The encryption setting is not used.
Workaround: specify the encryption flag "manually":
{{create table ignite_enc2 (id long primary key, name varchar) with
"template=EncryptedCacheTemplate,encrypted=true"}}
was:
If I create a cache template:
{{CacheConfiguration encryptedCacheTemplate = new CacheConfiguration();}}
{{encryptedCacheTemplate.setName("EncryptedCacheTemplate")}}
{{ .setEncryptionEnabled(true)}}
{{ .setBackups(1)}}
{{ .setCacheMode(CacheMode.PARTITIONED);}}
{{ignite.addCacheConfiguration(encryptedCacheTemplate);}}
And then try to use it:
{{create table ignite_enc (id long primary key, name varchar) with
"template=EncryptedCacheTemplate";}}
The encryption setting is not used.
Workaround: specify the encryption flag "manually":
{{create table ignite_enc2 (id long primary key, name varchar) with
"template=EncryptedCacheTemplate,encrypted=true"}}
> CREATE TABLE with template doesn't use isEncryptionEnabled flag
> ---
>
> Key: IGNITE-14067
> URL: https://issues.apache.org/jira/browse/IGNITE-14067
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 2.9, 2.8.1, 2.9.1
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
>
> If I create a cache template:
> {{CacheConfiguration encryptedCacheTemplate = new CacheConfiguration();}}
> {{encryptedCacheTemplate.setName("EncryptedCacheTemplate")}}
> {{.setEncryptionEnabled(true)}}
> {{.setBackups(1)}}
> {{.setCacheMode(CacheMode.PARTITIONED);}}
> {{ignite.addCacheConfiguration(encryptedCacheTemplate);}}
> And then try to use it:
> {{create table ignite_enc (id long primary key, name varchar) with
> "template=EncryptedCacheTemplate";}}
> The encryption setting is not used.
> Workaround: specify the encryption flag "manually":
> {{create table ignite_enc2 (id long primary key, name varchar) with
> "template=EncryptedCacheTemplate,encrypted=true"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13996) JMX beans in a format not understood by Prometheus
[
https://issues.apache.org/jira/browse/IGNITE-13996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-13996:
Description:
When I connect Ignite to Prometheus' JMX exporter, I get the following
exception:
{{Jan 13, 2021 5:31:49 PM
io.prometheus.jmx.shaded.io.prometheus.jmx.JmxCollector collect}}
{{ SEVERE: JMX scrape failed: java.lang.IllegalArgumentException: Not an
Attribute:
javax.management.openmbean.TabularDataSupport(tabularType=javax.management.openmbean.TabularType(name=org.apache.ignite.spi.systemview.view.ScanQueryView,rowType=javax.management.openmbean.CompositeType(name=org.apache.ignite.spi.systemview.view.ScanQueryView,items=((itemName=cacheGroupId,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=cacheGroupName,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=cacheId,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=cacheName,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=canceled,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),(itemName=duration,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=filter,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=keepBinary,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),(itemName=local,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),(itemName=originNodeId,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=pageSize,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=partition,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=queryId,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=startTime,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=subjectId,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=systemViewRowId,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=taskName,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=topology,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=transformer,itemType=javax.management.openmbean.SimpleType(name=java.lang.String,indexNames=(systemViewRowId)),contents={})}}
{{ at javax.management.AttributeList.adding(AttributeList.java:328)}}
{{ at javax.management.AttributeList.adding(AttributeList.java:335)}}
{{ at javax.management.AttributeList.asList(AttributeList.java:165)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.jmx.JmxScraper.scrapeBean(JmxScraper.java:156)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.jmx.JmxScraper.doScrape(JmxScraper.java:117)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.jmx.JmxCollector.collect(JmxCollector.java:460)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.CollectorRegistry$MetricFamilySamplesEnumeration.findNextElement(CollectorRegistry.java:183)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.CollectorRegistry$MetricFamilySamplesEnumeration.nextElement(CollectorRegistry.java:216)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.CollectorRegistry$MetricFamilySamplesEnumeration.nextElement(CollectorRegistry.java:137)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.exporter.common.TextFormat.write004(TextFormat.java:22)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.exporter.HTTPServer$HTTPMetricHandler.handle(HTTPServer.java:59)}}
{{ at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)}}
{{ at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)}}
{{ at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:82)}}
{{ at
sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:675)}}
{{ at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)}}
{{ at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:647)}}
{{ 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)}}
And only the basic JVM metrics appear in Prometheus. A workaround would be to
use OpenCensus, but a lot of people seem to prefer JMX.
It's not clear to me Ignite's JMX output is incorrect ([Prometheus' developers
don't seem keen to resolve on their
side|https://github.com/prometheus/jmx_exporter/issues/483]) but ideally,
Ignite would work correctly with a common monitoring tool.
was:
When I connect Ignite to Prometheus' JMX exporter, I get the following
exception:
{{ }}
{{ Jan 13, 2021 5:31:49 PM
io.prometheus.jmx.shaded.io.prometheus.jmx.JmxCollector collect}}
{{ SEVERE: JMX scrape failed:
[jira] [Created] (IGNITE-13996) JMX beans in a format not understood by Prometheus
Stephen Darlington created IGNITE-13996:
---
Summary: JMX beans in a format not understood by Prometheus
Key: IGNITE-13996
URL: https://issues.apache.org/jira/browse/IGNITE-13996
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1, 2.8.1, 2.9
Reporter: Stephen Darlington
When I connect Ignite to Prometheus' JMX exporter, I get the following
exception:
{{ }}
{{ Jan 13, 2021 5:31:49 PM
io.prometheus.jmx.shaded.io.prometheus.jmx.JmxCollector collect}}
{{ SEVERE: JMX scrape failed: java.lang.IllegalArgumentException: Not an
Attribute:
javax.management.openmbean.TabularDataSupport(tabularType=javax.management.openmbean.TabularType(name=org.apache.ignite.spi.systemview.view.ScanQueryView,rowType=javax.management.openmbean.CompositeType(name=org.apache.ignite.spi.systemview.view.ScanQueryView,items=((itemName=cacheGroupId,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=cacheGroupName,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=cacheId,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=cacheName,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=canceled,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),(itemName=duration,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=filter,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=keepBinary,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),(itemName=local,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),(itemName=originNodeId,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=pageSize,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=partition,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=queryId,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=startTime,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=subjectId,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=systemViewRowId,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)),(itemName=taskName,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=topology,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=transformer,itemType=javax.management.openmbean.SimpleType(name=java.lang.String,indexNames=(systemViewRowId)),contents={})}}
{{ at javax.management.AttributeList.adding(AttributeList.java:328)}}
{{ at javax.management.AttributeList.adding(AttributeList.java:335)}}
{{ at javax.management.AttributeList.asList(AttributeList.java:165)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.jmx.JmxScraper.scrapeBean(JmxScraper.java:156)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.jmx.JmxScraper.doScrape(JmxScraper.java:117)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.jmx.JmxCollector.collect(JmxCollector.java:460)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.CollectorRegistry$MetricFamilySamplesEnumeration.findNextElement(CollectorRegistry.java:183)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.CollectorRegistry$MetricFamilySamplesEnumeration.nextElement(CollectorRegistry.java:216)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.CollectorRegistry$MetricFamilySamplesEnumeration.nextElement(CollectorRegistry.java:137)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.exporter.common.TextFormat.write004(TextFormat.java:22)}}
{{ at
io.prometheus.jmx.shaded.io.prometheus.client.exporter.HTTPServer$HTTPMetricHandler.handle(HTTPServer.java:59)}}
{{ at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)}}
{{ at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)}}
{{ at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:82)}}
{{ at
sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:675)}}
{{ at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)}}
{{ at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:647)}}
{{ 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)}}
{{ }}
And only the basic JVM metrics appear in Prometheus. A workaround would be to
use OpenCensus, but a lot of people seem to prefer JMX.
It's not clear to me Ignite's JMX output is incorrect ([Prometheus' developers
don't seem keen to resolve on their
side|https://github.com/prometheus/jmx_exporter/issues/483]) but ideally,
Ignite would work correctly with a common monitoring tool.
--
This message was sent by Atlassian Jira
[jira] [Updated] (IGNITE-13503) On-heap cache eviction policy based on available memory rather than number of records
[ https://issues.apache.org/jira/browse/IGNITE-13503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-13503: Description: Currently, you can set the maximum size of an on-heap cache strictly by the number of records it holds. In cases where records vary substantially in size this could result in the cache being far bigger or far smaller than anticipated. It would be nice to have the ability to use available memory, for example using Java's soft references. was: Currently, you can set the maximum size of an on-heap cache strictly by the number of records it holds. In cases where records vary substantially in size this could result in the cache being far bigger or far smaller than anticipated. It would be nice to have the option to specify a maximum size in bytes. > On-heap cache eviction policy based on available memory rather than number of > records > - > > Key: IGNITE-13503 > URL: https://issues.apache.org/jira/browse/IGNITE-13503 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stephen Darlington >Priority: Minor > > Currently, you can set the maximum size of an on-heap cache strictly by the > number of records it holds. In cases where records vary substantially in size > this could result in the cache being far bigger or far smaller than > anticipated. > It would be nice to have the ability to use available memory, for example > using Java's soft references. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13503) On-heap cache eviction policy based on available memory rather than number of records
[ https://issues.apache.org/jira/browse/IGNITE-13503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-13503: Summary: On-heap cache eviction policy based on available memory rather than number of records (was: On-heap cache eviction policy based on size rather than number of records) > On-heap cache eviction policy based on available memory rather than number of > records > - > > Key: IGNITE-13503 > URL: https://issues.apache.org/jira/browse/IGNITE-13503 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stephen Darlington >Priority: Minor > > Currently, you can set the maximum size of an on-heap cache strictly by the > number of records it holds. In cases where records vary substantially in size > this could result in the cache being far bigger or far smaller than > anticipated. > It would be nice to have the option to specify a maximum size in bytes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13503) On-heap cache eviction policy based on size rather than number of records
Stephen Darlington created IGNITE-13503: --- Summary: On-heap cache eviction policy based on size rather than number of records Key: IGNITE-13503 URL: https://issues.apache.org/jira/browse/IGNITE-13503 Project: Ignite Issue Type: Improvement Components: cache Reporter: Stephen Darlington Currently, you can set the maximum size of an on-heap cache strictly by the number of records it holds. In cases where records vary substantially in size this could result in the cache being far bigger or far smaller than anticipated. It would be nice to have the option to specify a maximum size in bytes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13502) Events when off-heap eviction is triggered
Stephen Darlington created IGNITE-13502: --- Summary: Events when off-heap eviction is triggered Key: IGNITE-13502 URL: https://issues.apache.org/jira/browse/IGNITE-13502 Project: Ignite Issue Type: Improvement Components: cache, persistence Reporter: Stephen Darlington If I configure my data region with an eviction policy, it's not currently possible to see when it is triggered or which records were affected. There is EVT_CACHE_ENTRY_EVICTED, but I understand that this is for _on_-heap eviction (certainly it's not triggered in my tests). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13398) NPE in IgniteServiceProcessor when destroying a cache
[
https://issues.apache.org/jira/browse/IGNITE-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-13398:
Affects Version/s: 2.8
2.8.1
> NPE in IgniteServiceProcessor when destroying a cache
> --
>
> Key: IGNITE-13398
> URL: https://issues.apache.org/jira/browse/IGNITE-13398
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Denis Mekhanikov
>Priority: Major
> Attachments: Main.java
>
>
> Try running the attached reproducer: [^Main.java]. The following exception is
> printed to the logs:
> {noformat}
> Sep 03, 2020 12:13:58 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to notify direct custom event listener:
> DynamicCacheChangeBatch [id=c1d6e335471-6bafb375-9d3e-487a-974d-35927ae02c04,
> reqs=ArrayList [DynamicCacheChangeRequest [cacheName=foo, hasCfg=false,
> nodeId=5e41fda8-e749-432c-9832-7b1c6ee3d0c8, clientStartOnly=false,
> stop=true, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=null, stopCaches=[foo],
> startGrps=[], stopGrps=[foo, destroy=true], resetParts=null,
> stateChangeRequest=null], startCaches=false]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.lambda$processDynamicCacheChangeRequest$6(IgniteServiceProcessor.java:1694)
> at java.util.Collection.removeIf(Collection.java:414)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.processDynamicCacheChangeRequest(IgniteServiceProcessor.java:1691)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.access$200(IgniteServiceProcessor.java:108)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:232)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:229)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:665)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:528)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2608)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2646)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17199498#comment-17199498
]
Stephen Darlington commented on IGNITE-13453:
-
I would prefer to keep the defaults the same, regardless of how you start it.
Given free rein, I'd make it secure-by-default and have JMX disabled by default
but I think that change would warrant a further discussion.
> Docker: Change run.sh to call java directly
> ---
>
> Key: IGNITE-13453
> URL: https://issues.apache.org/jira/browse/IGNITE-13453
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Alexandr Shapkin
>Assignee: Ilya Murchenko
>Priority: Critical
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ignite.sh is cumbersome in Docker as it creates the hassle with signals not
> being propagated but adds little value as most of what ignite.sh discovers
> about the system is known beforehand for our Docker images.
> Let's replace ignite.sh call with direct java invocation.
> {code:bash}
> #!/bin/bash
> #
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements. See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to You under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
> #
> source "${IGNITE_HOME}"/bin/include/functions.sh
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Set IGNITE_LIBS.
> #
> source "${IGNITE_HOME}"/bin/include/setenv.sh
> CP="${IGNITE_LIBS}"
> DEFAULT_CONFIG=config/default-config.xml
> #
> # Add optional libs to classpath
> #
> if [ -n "${OPTION_LIBS}" ]; then
> IFS=, LIBS_LIST=("$(tr -d '[:space:]' <<< ${OPTION_LIBS})")
> for lib in ${LIBS_LIST[@]}; do
> LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
> "${JARS[*]}")
> if [ -z "${USER_LIBS}" ]; then
> export USER_LIBS="${LIBS}"
> else
> export USER_LIBS="${USER_LIBS}:${LIBS}"
> fi
> done
> fi
> #
> # Add external libs to classpath
> #
> if [ -n "${EXTERNAL_LIBS}" ]; then
> IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
> for lib in "${LIBS_LIST[@]}"; do
> echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
> done
> wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
> "${IGNITE_HOME}"/libs/external
> rm "${IGNITE_HOME}"/work/external_libs
> fi
> #
> # Define classpath
> #
> if [ "${USER_LIBS:-}" != "" ]; then
> IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
> fi
> CP="${IGNITE_LIBS}"
> unset IFS
> #
> # Define default Java options
> #
> if [ -z "${JVM_OPTS}" ] ; then
> JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
> fi
> #
> # Add Java extra option
> #
> if [ "${version}" -eq 8 ] ; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> ${JVM_OPTS}"
> elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --illegal-access=permit \
> --add-modules=java.xml.bind \
> ${JVM_OPTS}"
> elif [ "${version}" -ge 11 ] ; then
> JVM_OPTS="\
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED \
> --illegal-access=permit \
> ${JVM_OPTS}"
> fi
> DIGNITE_QUIET=$(printenv JVM_OPTS | grep -o 'IGNITE_QUIET=[^ ,]\+' | cut -d
> "=" -f 2)
> if [ "${IGNITE_QUIET}" == "false" -o "${DIGNITE_QUIET}" == "false" ]; then
> JVM_OPTS="${JVM_OPTS} -DIGNITE_QUIET=false"
> fi
> #
> #
[jira] [Updated] (IGNITE-13468) Destroying a caches doesn't clean up cache directory
[
https://issues.apache.org/jira/browse/IGNITE-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-13468:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Destroying a caches doesn't clean up cache directory
>
>
> Key: IGNITE-13468
> URL: https://issues.apache.org/jira/browse/IGNITE-13468
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8.1
>Reporter: Stephen Darlington
>Priority: Minor
>
> If I create a cache – either with SQL or with Ignite#getOrCreateCache() – in
> a data region with persistence enabled, destroying the cache removes all the
> data files but not the directory in which they're stored.
> For example. Before:
> $ ls cache*
> {{cache-DESTROY_DEMO:}}
> {{cache_data.dat index.bin part-2.bin part-3.bin part-4.bin}}
> cache-ignite-sys-cache:
> {{cache_data.dat index.bin}}
> {{$}}
> After:
> $ ls cache*
> {{cache-DESTROY_DEMO:}}{{ }}
> cache-ignite-sys-cache:
> {{cache_data.dat index.bin}}
> {{$}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13468) Destroying a caches doesn't clean up cache directory
[
https://issues.apache.org/jira/browse/IGNITE-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-13468:
Description:
If I create a cache – either with SQL or with Ignite#getOrCreateCache() – in a
data region with persistence enabled, destroying the cache removes all the data
files but not the directory in which they're stored.
For example. Before:
$ ls cache*
{{cache-DESTROY_DEMO:}}
{{cache_data.dat index.bin part-2.bin part-3.bin part-4.bin}}
cache-ignite-sys-cache:
{{cache_data.dat index.bin}}
{{$}}
After:
$ ls cache*
{{cache-DESTROY_DEMO:}}{{ }}
cache-ignite-sys-cache:
{{cache_data.dat index.bin}}
{{$}}
was:
If I create a cache – either with SQL or with Ignite#getOrCreateCache() – in a
data region with persistence enabled, destroying the cache removes all the data
files but not the directory in which they're stored.
For example. Before:
{{$ ls cache*}}
{{ cache-DESTROY_DEMO:}}
{{ cache_data.dat index.bin part-2.bin part-3.bin part-4.bin}}
{{cache-ignite-sys-cache:}}
{{ cache_data.dat index.bin}}
{{ $}}
After:
{{$ ls cache*}}
{{ cache-DESTROY_DEMO:}}
{{cache-ignite-sys-cache:}}
{{ cache_data.dat index.bin}}
{{ $}}
> Destroying a caches doesn't clean up cache directory
>
>
> Key: IGNITE-13468
> URL: https://issues.apache.org/jira/browse/IGNITE-13468
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8.1
>Reporter: Stephen Darlington
>Priority: Minor
>
> If I create a cache – either with SQL or with Ignite#getOrCreateCache() – in
> a data region with persistence enabled, destroying the cache removes all the
> data files but not the directory in which they're stored.
> For example. Before:
> $ ls cache*
> {{cache-DESTROY_DEMO:}}
> {{cache_data.dat index.bin part-2.bin part-3.bin part-4.bin}}
> cache-ignite-sys-cache:
> {{cache_data.dat index.bin}}
> {{$}}
> After:
> $ ls cache*
> {{cache-DESTROY_DEMO:}}{{ }}
> cache-ignite-sys-cache:
> {{cache_data.dat index.bin}}
> {{$}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13468) Destroying a caches doesn't clean up cache directory
Stephen Darlington created IGNITE-13468:
---
Summary: Destroying a caches doesn't clean up cache directory
Key: IGNITE-13468
URL: https://issues.apache.org/jira/browse/IGNITE-13468
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.8.1
Reporter: Stephen Darlington
If I create a cache – either with SQL or with Ignite#getOrCreateCache() – in a
data region with persistence enabled, destroying the cache removes all the data
files but not the directory in which they're stored.
For example. Before:
{{$ ls cache*}}
{{ cache-DESTROY_DEMO:}}
{{ cache_data.dat index.bin part-2.bin part-3.bin part-4.bin}}
{{cache-ignite-sys-cache:}}
{{ cache_data.dat index.bin}}
{{ $}}
After:
{{$ ls cache*}}
{{ cache-DESTROY_DEMO:}}
{{cache-ignite-sys-cache:}}
{{ cache_data.dat index.bin}}
{{ $}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13464) Ignite-rest-http includes vulnerable dependencies
Stephen Darlington created IGNITE-13464: --- Summary: Ignite-rest-http includes vulnerable dependencies Key: IGNITE-13464 URL: https://issues.apache.org/jira/browse/IGNITE-13464 Project: Ignite Issue Type: Bug Components: rest Affects Versions: 2.8.1, 2.9 Reporter: Stephen Darlington The ignite-rest-http module includes a [vulnerable version|https://nvd.nist.gov/vuln/detail/CVE-2019-17571] of the log4j library. It also appears to include slf4j. Why does the REST API include its own logging libraries? This was spotted in 2.8.1 but still appears to be an issue in master and 2.9. More here: http://apache-ignite-users.70518.x6.nabble.com/critical-security-vulnerability-for-opt-ignite-apache-ignite-libs-optional-ignite-rest-http-log4j-1-r-td34031.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13404) ignite.sh fails to set default JVM parameters
[ https://issues.apache.org/jira/browse/IGNITE-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-13404: Description: ignite.sh [tries to set parameters for the JVM|https://github.com/apache/ignite/blob/master/bin/ignite.sh#L102] if they've not been set by the user (defaulting to 1Gb heap), unfortunately, it's always set by an earlier part of the startup scripts. Conversely, ignitevisorcmd.sh always sets the same parameters, even if they have already been set by the user. was:ignite.sh [tries to set parameters for the JVM|https://github.com/apache/ignite/blob/master/bin/ignite.sh#L102] if they've not been set by the user (defaulting to 1Gb heap), unfortunately it's always set by an earlier part of the startup scripts. > ignite.sh fails to set default JVM parameters > - > > Key: IGNITE-13404 > URL: https://issues.apache.org/jira/browse/IGNITE-13404 > Project: Ignite > Issue Type: Bug > Environment: Anything but Windows. >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Minor > > ignite.sh [tries to set parameters for the > JVM|https://github.com/apache/ignite/blob/master/bin/ignite.sh#L102] if > they've not been set by the user (defaulting to 1Gb heap), unfortunately, > it's always set by an earlier part of the startup scripts. > Conversely, ignitevisorcmd.sh always sets the same parameters, even if they > have already been set by the user. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13404) ignite.sh fails to set default JVM parameters
Stephen Darlington created IGNITE-13404: --- Summary: ignite.sh fails to set default JVM parameters Key: IGNITE-13404 URL: https://issues.apache.org/jira/browse/IGNITE-13404 Project: Ignite Issue Type: Bug Environment: Anything but Windows. Reporter: Stephen Darlington Assignee: Stephen Darlington ignite.sh [tries to set parameters for the JVM|https://github.com/apache/ignite/blob/master/bin/ignite.sh#L102] if they've not been set by the user (defaulting to 1Gb heap), unfortunately it's always set by an earlier part of the startup scripts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11715) Add support for nojmx flag when running Ignite in docker
[ https://issues.apache.org/jira/browse/IGNITE-11715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-11715: Docs Text: To be added to the table showing the various environment variables on https://apacheignite.readme.io/docs/docker-deployment: Name: IGNITE_OPTIONS Description: Additional options to pass to the ignite.sh on startup. Default: N/A Example: -nojmx > Add support for nojmx flag when running Ignite in docker > > > Key: IGNITE-11715 > URL: https://issues.apache.org/jira/browse/IGNITE-11715 > Project: Ignite > Issue Type: Wish >Reporter: Kresimir Horvat >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add option to run ignite with -nojmx when running Ignite in docker container. > Currently run.sh script doesn't support passing -nojmx option. > > Desired result is to run ignite with -nojmx flag and possibility of passing > JMX_MON as env variable over docker run. > More details about problem are described in thread > [http://apache-ignite-users.70518.x6.nabble.com/Running-control-sh-in-docker-container-when-JXM-is-started-td27812.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13234) SqlFieldsQuery as ContinuousQuery.InitialQuery
[ https://issues.apache.org/jira/browse/IGNITE-13234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154412#comment-17154412 ] Stephen Darlington commented on IGNITE-13234: - This has already been fixed in the .net version > SqlFieldsQuery as ContinuousQuery.InitialQuery > -- > > Key: IGNITE-13234 > URL: https://issues.apache.org/jira/browse/IGNITE-13234 > Project: Ignite > Issue Type: New Feature > Components: platforms >Affects Versions: 2.8, 2.8.1 >Reporter: Stephen Darlington >Priority: Major > > SqlQuery has been deprecated in favour of SqlFieldsQuery, but ContinuousQuery > in Ignite does not allow SqlFieldsQuery as InitialQuery. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13234) SqlFieldsQuery as ContinuousQuery.InitialQuery
Stephen Darlington created IGNITE-13234: --- Summary: SqlFieldsQuery as ContinuousQuery.InitialQuery Key: IGNITE-13234 URL: https://issues.apache.org/jira/browse/IGNITE-13234 Project: Ignite Issue Type: New Feature Components: platforms Affects Versions: 2.8.1, 2.8 Reporter: Stephen Darlington SqlQuery has been deprecated in favour of SqlFieldsQuery, but ContinuousQuery in Ignite does not allow SqlFieldsQuery as InitialQuery. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12867) Python thin client: support for DB-API
[ https://issues.apache.org/jira/browse/IGNITE-12867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077962#comment-17077962 ] Stephen Darlington commented on IGNITE-12867: - Link updated (Jira was having problems when I created the ticket -- it _did_ point to the right place!). I guess ODBC might work but it does make things a lot harder if you're not on Windows. We don't ship an ODBC binary for Linux as far as I know. > Python thin client: support for DB-API > -- > > Key: IGNITE-12867 > URL: https://issues.apache.org/jira/browse/IGNITE-12867 > Project: Ignite > Issue Type: Improvement > Components: python >Affects Versions: 2.8 >Reporter: Stephen Darlington >Priority: Major > > Python has a database connection standard called > [DB-API|https://www.python.org/dev/peps/pep-0249/]. It would make the Ignite > Python thin client a lot more useful if it could use this in addition to its > current Ignite-specific APIs. Implementing this would enable other Apache > tools such as SuperSet and Airflow to connect to and use Ignite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12867) Python thin client: support for DB-API
[ https://issues.apache.org/jira/browse/IGNITE-12867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-12867: Description: Python has a database connection standard called [DB-API|https://www.python.org/dev/peps/pep-0249/]. It would make the Ignite Python thin client a lot more useful if it could use this in addition to its current Ignite-specific APIs. Implementing this would enable other Apache tools such as SuperSet and Airflow to connect to and use Ignite. (was: Python has a database connection standard called [DB-API|http://example.com/]. It would make the Ignite Python thin client a lot more useful if it could use this in addition to its current Ignite-specific APIs. Implementing this would enable other Apache tools such as SuperSet and Airflow to connect to and use Ignite.) > Python thin client: support for DB-API > -- > > Key: IGNITE-12867 > URL: https://issues.apache.org/jira/browse/IGNITE-12867 > Project: Ignite > Issue Type: Improvement > Components: python >Affects Versions: 2.8 >Reporter: Stephen Darlington >Priority: Major > > Python has a database connection standard called > [DB-API|https://www.python.org/dev/peps/pep-0249/]. It would make the Ignite > Python thin client a lot more useful if it could use this in addition to its > current Ignite-specific APIs. Implementing this would enable other Apache > tools such as SuperSet and Airflow to connect to and use Ignite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12867) Python thin client: support for DB-API
[ https://issues.apache.org/jira/browse/IGNITE-12867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076241#comment-17076241 ] Stephen Darlington commented on IGNITE-12867: - More investigation is needed -- hence adding as a comment rather than another ticket -- but we should also make sure we can interoperate with [SQLAlchemy|https://github.com/sqlalchemy/sqlalchemy]. This may Just Work once the DB-API change is implemented or may require some tweaks. > Python thin client: support for DB-API > -- > > Key: IGNITE-12867 > URL: https://issues.apache.org/jira/browse/IGNITE-12867 > Project: Ignite > Issue Type: Improvement > Components: python >Affects Versions: 2.8 >Reporter: Stephen Darlington >Priority: Major > > Python has a database connection standard called > [DB-API|http://example.com/]. It would make the Ignite Python thin client a > lot more useful if it could use this in addition to its current > Ignite-specific APIs. Implementing this would enable other Apache tools such > as SuperSet and Airflow to connect to and use Ignite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12867) Python thin client: support for DB-API
Stephen Darlington created IGNITE-12867: --- Summary: Python thin client: support for DB-API Key: IGNITE-12867 URL: https://issues.apache.org/jira/browse/IGNITE-12867 Project: Ignite Issue Type: Improvement Components: python Affects Versions: 2.8 Reporter: Stephen Darlington Python has a database connection standard called [DB-API|http://example.com/]. It would make the Ignite Python thin client a lot more useful if it could use this in addition to its current Ignite-specific APIs. Implementing this would enable other Apache tools such as SuperSet and Airflow to connect to and use Ignite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980290#comment-16980290 ] Stephen Darlington commented on IGNITE-12192: - Is there anything else I need to do to help get this merged? > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940786#comment-16940786 ] Stephen Darlington commented on IGNITE-12192: - The attached patch ([GitHub Pull Request #6877|https://github.com/apache/ignite/pull/6877]) offers a third way: when it falls out of the main loop, disconnect from the cluster if it's connected. > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939551#comment-16939551 ] Stephen Darlington commented on IGNITE-12192: - [~kuaw26], it already _does_ support ^D. It only fails if you're connected to a cluster when you press it. Why should ^D only work sometimes? Also, visor is as much a Unix utility as, say, the Scala REPL or Python, both of which support ^D. My guess is they also support ^Z when run in Windows, which is the convention on that platform. > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12182) ExecutorService is inconsistent with Compute and Services, runs on clients
[ https://issues.apache.org/jira/browse/IGNITE-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939349#comment-16939349 ] Stephen Darlington commented on IGNITE-12182: - Would you mind taking a look, [~yzhdanov]? > ExecutorService is inconsistent with Compute and Services, runs on clients > -- > > Key: IGNITE-12182 > URL: https://issues.apache.org/jira/browse/IGNITE-12182 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > In IGNITE-860 the default behaviour was changed so that compute and service > tasks would be executed only on server nodes. This is a sensible default and > it's confusing that it's not also true for jobs run using the ExecutorService. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939347#comment-16939347 ] Stephen Darlington commented on IGNITE-12192: - Would you mind taking a look, [~kuaw26] ? > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9836) Invalid check of ea java versions
[
https://issues.apache.org/jira/browse/IGNITE-9836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939339#comment-16939339
]
Stephen Darlington commented on IGNITE-9836:
Implemented review comments here: [https://github.com/apache/ignite/pull/6920]
> Invalid check of ea java versions
> -
>
> Key: IGNITE-9836
> URL: https://issues.apache.org/jira/browse/IGNITE-9836
> Project: Ignite
> Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> On check of '1.8.0_192-ea' java version in ignite.sh the next messages in
> console are printed:
> {code:java}
> ./include/functions.sh: line 81: [: -lt: unary operator expected
> ./ignite.sh: line 61:
> /home/vsisko/Downloads/distr/bin/include/build-classpath.sh: No such file or
> directory
> ./ignite.sh: line 152: [: -eq: unary operator expected
> ./ignite.sh: line 157: [: -gt: unary operator expected
> ./ignite.sh: line 170: [: -eq: unary operator expected{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12182) ExecutorService is inconsistent with Compute and Services, runs on clients
[ https://issues.apache.org/jira/browse/IGNITE-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-12182: Fix Version/s: 2.8 > ExecutorService is inconsistent with Compute and Services, runs on clients > -- > > Key: IGNITE-12182 > URL: https://issues.apache.org/jira/browse/IGNITE-12182 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > In IGNITE-860 the default behaviour was changed so that compute and service > tasks would be executed only on server nodes. This is a sensible default and > it's confusing that it's not also true for jobs run using the ExecutorService. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-12192: Description: You can exit most Unix utilities by pressing ^D. However, if you do that in ignitevisorcmd when you're connected to a cluster, the process hangs. You have to press ^C to quit. (It does work as expected if you close the connection first.) (was: You can exit most Unix utilities by pressing ^D. However, if you do that in ignitevisorcmd, the process hangs. You have to press ^C to quit.) > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-12192: Component/s: visor Fix Version/s: 2.8 > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd, the process hangs. You have to press ^C to quit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington updated IGNITE-12192: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd, the process hangs. You have to press ^C to quit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12192) visorcmd hangs if you ^D to quit
Stephen Darlington created IGNITE-12192: --- Summary: visorcmd hangs if you ^D to quit Key: IGNITE-12192 URL: https://issues.apache.org/jira/browse/IGNITE-12192 Project: Ignite Issue Type: Bug Affects Versions: 2.7.5 Reporter: Stephen Darlington Assignee: Stephen Darlington You can exit most Unix utilities by pressing ^D. However, if you do that in ignitevisorcmd, the process hangs. You have to press ^C to quit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12182) ExecutorService is inconsistent with Compute and Services, runs on clients
Stephen Darlington created IGNITE-12182: --- Summary: ExecutorService is inconsistent with Compute and Services, runs on clients Key: IGNITE-12182 URL: https://issues.apache.org/jira/browse/IGNITE-12182 Project: Ignite Issue Type: Bug Components: compute Affects Versions: 2.7.5 Reporter: Stephen Darlington Assignee: Stephen Darlington In IGNITE-860 the default behaviour was changed so that compute and service tasks would be executed only on server nodes. This is a sensible default and it's confusing that it's not also true for jobs run using the ExecutorService. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11586) Update platforms/cpp/DEVNOTES.txt: OpenSSL
[
https://issues.apache.org/jira/browse/IGNITE-11586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849706#comment-16849706
]
Stephen Darlington commented on IGNITE-11586:
-
Done. Also rebased (again) and added references to {{--with-openssl}} option
(which is probably better than using environment variable).
> Update platforms/cpp/DEVNOTES.txt: OpenSSL
> ---
>
> Key: IGNITE-11586
> URL: https://issues.apache.org/jira/browse/IGNITE-11586
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10 Pro, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Stephen Darlington
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ODBC compilation required OpenSSL headers and the project compilation fails
> due to unable to open {{include/openssl/ssl.h}}. I suggest to add the
> requirement to install OpenSSL and set the corresponding environment variable:
> {noformat}
> Building on Windows with Visual Studio (tm)
> --
> Common Requirements:
> ...
> * OPENSSL_HOME environment variable must be set pointing to OpenSSL
> installation directory.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11715) Add support for nojmx flag when running Ignite in docker
[ https://issues.apache.org/jira/browse/IGNITE-11715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington reassigned IGNITE-11715: --- Assignee: Stephen Darlington > Add support for nojmx flag when running Ignite in docker > > > Key: IGNITE-11715 > URL: https://issues.apache.org/jira/browse/IGNITE-11715 > Project: Ignite > Issue Type: Wish >Reporter: Kresimir Horvat >Assignee: Stephen Darlington >Priority: Major > > Add option to run ignite with -nojmx when running Ignite in docker container. > Currently run.sh script doesn't support passing -nojmx option. > > Desired result is to run ignite with -nojmx flag and possibility of passing > JMX_MON as env variable over docker run. > More details about problem are described in thread > [http://apache-ignite-users.70518.x6.nabble.com/Running-control-sh-in-docker-container-when-JXM-is-started-td27812.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11856) Running ignite.sh with nojmx flag stops with error
Stephen Darlington created IGNITE-11856:
---
Summary: Running ignite.sh with nojmx flag stops with error
Key: IGNITE-11856
URL: https://issues.apache.org/jira/browse/IGNITE-11856
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.7
Reporter: Stephen Darlington
Assignee: Stephen Darlington
Running ignite.sh with the {{-nojmx}} flag results in an error:
{code:java}
./ignite.sh: line 228: JMX_MON: unbound variable{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11586) Update platforms/cpp/DEVNOTES.txt: OpenSSL
[
https://issues.apache.org/jira/browse/IGNITE-11586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington reassigned IGNITE-11586:
---
Assignee: Stephen Darlington
> Update platforms/cpp/DEVNOTES.txt: OpenSSL
> ---
>
> Key: IGNITE-11586
> URL: https://issues.apache.org/jira/browse/IGNITE-11586
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10 Pro, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Stephen Darlington
>Priority: Major
> Fix For: 2.8
>
>
> ODBC compilation required OpenSSL headers and the project compilation fails
> due to unable to open {{include/openssl/ssl.h}}. I suggest to add the
> requirement to install OpenSSL and set the corresponding environment variable:
> {noformat}
> Building on Windows with Visual Studio (tm)
> --
> Common Requirements:
> ...
> * OPENSSL_HOME environment variable must be set pointing to OpenSSL
> installation directory.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11586) Update platforms/cpp/DEVNOTES.txt: OpenSSL
[
https://issues.apache.org/jira/browse/IGNITE-11586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805108#comment-16805108
]
Stephen Darlington commented on IGNITE-11586:
-
I added the check for OpenSSL as part of the Mac port:
https://issues.apache.org/jira/browse/IGNITE-1436
> Update platforms/cpp/DEVNOTES.txt: OpenSSL
> ---
>
> Key: IGNITE-11586
> URL: https://issues.apache.org/jira/browse/IGNITE-11586
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10 Pro, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Priority: Major
> Fix For: 2.8
>
>
> ODBC compilation required OpenSSL headers and the project compilation fails
> due to unable to open {{include/openssl/ssl.h}}. I suggest to add the
> requirement to install OpenSSL and set the corresponding environment variable:
> {noformat}
> Building on Windows with Visual Studio (tm)
> --
> Common Requirements:
> ...
> * OPENSSL_HOME environment variable must be set pointing to OpenSSL
> installation directory.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1436) C++: Port to MAC OS.
[ https://issues.apache.org/jira/browse/IGNITE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799213#comment-16799213 ] Stephen Darlington commented on IGNITE-1436: [~isapego], updated version force-pushed to my branch. I updated the documentation so _hopefully_ enough for you to get started. > C++: Port to MAC OS. > > > Key: IGNITE-1436 > URL: https://issues.apache.org/jira/browse/IGNITE-1436 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Stephen Darlington >Priority: Major > Labels: cpp > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > It will require minimal porting of "common" and "utils" stuff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11553) Ignite metrics to Prometheus.io
Stephen Darlington created IGNITE-11553: --- Summary: Ignite metrics to Prometheus.io Key: IGNITE-11553 URL: https://issues.apache.org/jira/browse/IGNITE-11553 Project: Ignite Issue Type: New Feature Reporter: Stephen Darlington Assignee: Stephen Darlington It would be nice if Ignite could send its metrics (or at least some of them) to [Prometheus|https://prometheus.io] metrics and alerting system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5475) SQL: add "WITH AS" support
[
https://issues.apache.org/jira/browse/IGNITE-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16756212#comment-16756212
]
Stephen Darlington commented on IGNITE-5475:
Any update on this? It's not documented but this syntax does appear to work:
{code:sql}
0: jdbc:ignite:thin://127.0.0.1> create table ignite (id long, name varchar,
primary key(id));
No rows affected (0.219 seconds)
0: jdbc:ignite:thin://127.0.0.1> insert into ignite values (1, 'Stephen'), (2,
‘Leon');
2 rows affected (0.075 seconds)
0: jdbc:ignite:thin://127.0.0.1> select * from ignite;
+++
| ID | NAME |
+++
| 1 | Stephen |
| 2 | Leon. |
+++
2 rows selected (0.056 seconds)
0: jdbc:ignite:thin://127.0.0.1> with num_one as (select * from ignite where id
=1)
. . . . . . . . . . . . . . . .> select name from num_one;
++
| NAME |
++
| Stephen |
++
1 row selected (0.024 seconds)
{code}
The 'recursive' option fails with an exception:
{code:java}
Error: javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Unknown query type: null
(state=5,code=1){code}
I assume we got it "for free" when the version of H2 was updated?
> SQL: add "WITH AS" support
> --
>
> Key: IGNITE-5475
> URL: https://issues.apache.org/jira/browse/IGNITE-5475
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Andrew Mashenkov
>Priority: Minor
> Labels: sql-engine
>
> Seems for now, H2 doesn't support "WITH AS" clause.
> We should throw exception until we found a workaround or "WITH" support be
> added to H2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-5475) SQL: add "WITH AS" support
[
https://issues.apache.org/jira/browse/IGNITE-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16756212#comment-16756212
]
Stephen Darlington edited comment on IGNITE-5475 at 1/30/19 3:16 PM:
-
Any update on this? It's not documented but this syntax does appear to work in
2.7:
{code:sql}
0: jdbc:ignite:thin://127.0.0.1> create table ignite (id long, name varchar,
primary key(id));
No rows affected (0.219 seconds)
0: jdbc:ignite:thin://127.0.0.1> insert into ignite values (1, 'Stephen'), (2,
‘Leon');
2 rows affected (0.075 seconds)
0: jdbc:ignite:thin://127.0.0.1> select * from ignite;
+++
| ID | NAME |
+++
| 1 | Stephen |
| 2 | Leon. |
+++
2 rows selected (0.056 seconds)
0: jdbc:ignite:thin://127.0.0.1> with num_one as (select * from ignite where id
=1)
. . . . . . . . . . . . . . . .> select name from num_one;
++
| NAME |
++
| Stephen |
++
1 row selected (0.024 seconds)
{code}
The 'recursive' option fails with an exception:
{code:java}
Error: javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Unknown query type: null
(state=5,code=1){code}
I assume we got it "for free" when the version of H2 was updated?
was (Author: sdarlington):
Any update on this? It's not documented but this syntax does appear to work:
{code:sql}
0: jdbc:ignite:thin://127.0.0.1> create table ignite (id long, name varchar,
primary key(id));
No rows affected (0.219 seconds)
0: jdbc:ignite:thin://127.0.0.1> insert into ignite values (1, 'Stephen'), (2,
‘Leon');
2 rows affected (0.075 seconds)
0: jdbc:ignite:thin://127.0.0.1> select * from ignite;
+++
| ID | NAME |
+++
| 1 | Stephen |
| 2 | Leon. |
+++
2 rows selected (0.056 seconds)
0: jdbc:ignite:thin://127.0.0.1> with num_one as (select * from ignite where id
=1)
. . . . . . . . . . . . . . . .> select name from num_one;
++
| NAME |
++
| Stephen |
++
1 row selected (0.024 seconds)
{code}
The 'recursive' option fails with an exception:
{code:java}
Error: javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Unknown query type: null
(state=5,code=1){code}
I assume we got it "for free" when the version of H2 was updated?
> SQL: add "WITH AS" support
> --
>
> Key: IGNITE-5475
> URL: https://issues.apache.org/jira/browse/IGNITE-5475
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Andrew Mashenkov
>Priority: Minor
> Labels: sql-engine
>
> Seems for now, H2 doesn't support "WITH AS" clause.
> We should throw exception until we found a workaround or "WITH" support be
> added to H2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1436) C++: Port to MAC OS.
[ https://issues.apache.org/jira/browse/IGNITE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740338#comment-16740338 ] Stephen Darlington commented on IGNITE-1436: Okay, I'll wait until TC is set up with a way to test the Mac version. > C++: Port to MAC OS. > > > Key: IGNITE-1436 > URL: https://issues.apache.org/jira/browse/IGNITE-1436 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Stephen Darlington >Priority: Major > Labels: cpp > Fix For: 2.8 > > > It will require minimal porting of "common" and "utils" stuff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1436) C++: Port to MAC OS.
[ https://issues.apache.org/jira/browse/IGNITE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739272#comment-16739272 ] Stephen Darlington commented on IGNITE-1436: Let me know if I should rebase it against master. Is the TC build a requirement? Without more testing I would hesitate to say that the Mac is fully supported but, as long as we don't break platforms that _are_ supported, I'd still argue that it's a net positive. > C++: Port to MAC OS. > > > Key: IGNITE-1436 > URL: https://issues.apache.org/jira/browse/IGNITE-1436 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Stephen Darlington >Priority: Major > Labels: cpp > Fix For: 2.8 > > > It will require minimal porting of "common" and "utils" stuff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10647) Spark example code potentially confusing
Stephen Darlington created IGNITE-10647: --- Summary: Spark example code potentially confusing Key: IGNITE-10647 URL: https://issues.apache.org/jira/browse/IGNITE-10647 Project: Ignite Issue Type: Improvement Affects Versions: 2.7 Reporter: Stephen Darlington Assignee: Stephen Darlington This started with a [question on Stack Overflow|https://stackoverflow.com/questions/53704478/apache-ignite-spark-dataframes-client-vs-server-doubts/53704993#53704993]. In short, the user copy-and-pasted the whole sample code over, without realising that in addition to firing up a Spark client it also runs an Ignite server. The advantage of this is obviously that the code is entirely self-contained. However, there's little to suggest what's going on in the code, which bits are just setting stuff up and which bits are actually demonstrating the Spark integration. Maybe there's a way to restructure it to make it clearer? Or a few extra comments? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10646) Typo in partition map exchange diagnostics
Stephen Darlington created IGNITE-10646:
---
Summary: Typo in partition map exchange diagnostics
Key: IGNITE-10646
URL: https://issues.apache.org/jira/browse/IGNITE-10646
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.7
Reporter: Stephen Darlington
Assignee: Stephen Darlington
If the partition map failed to exchange in time, you get the following error
message and suggestion:
{code:java}
"Failed to wait for partition map exchange [...] Consider changing
TransactionConfiguration.txTimeoutOnPartitionMapSynchronization"{code}
Unfortunately there is no {{txTimeoutOnPartitionMapSynchronization}} property.
Maybe there used to be? In any case, the code looks at
{{txTimeoutOnPartitionMapExchange}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10577) ignite-kubernetes is missing jackson-annotations dependency
[
https://issues.apache.org/jira/browse/IGNITE-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711702#comment-16711702
]
Stephen Darlington edited comment on IGNITE-10577 at 12/6/18 5:04 PM:
--
Patch is against master. Possibly also needs to be back-ported to 2.7, though
there is a workaround.
[https://github.com/apache/ignite/pull/5594]
was (Author: sdarlington):
Patch is against master. Possible also needs to be back-ported to 2.7, though
there is a workaround.
https://github.com/apache/ignite/pull/5594
> ignite-kubernetes is missing jackson-annotations dependency
> ---
>
> Key: IGNITE-10577
> URL: https://issues.apache.org/jira/browse/IGNITE-10577
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.7
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
>
> When starting 2.7 with the ignite-kubernetes option I get the following
> exception on startup:
>
> {code}
> [13:44:34,605][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> java.lang.NoClassDefFoundError: com/fasterxml/jackson/annotation/JsonView
> at
> com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector.(JacksonAnnotationIntrospector.java:37)
> at
> com.fasterxml.jackson.databind.ObjectMapper.(ObjectMapper.java:291)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:151)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1900)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1848)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1049)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:910)
> {code}
>
> It's clearly missing a dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10577) ignite-kubernetes is missing jackson-annotations dependency
Stephen Darlington created IGNITE-10577:
---
Summary: ignite-kubernetes is missing jackson-annotations
dependency
Key: IGNITE-10577
URL: https://issues.apache.org/jira/browse/IGNITE-10577
Project: Ignite
Issue Type: Bug
Components: build
Affects Versions: 2.7
Reporter: Stephen Darlington
Assignee: Stephen Darlington
When starting 2.7 with the ignite-kubernetes option I get the following
exception on startup:
{{[13:44:34,605][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).}}{{java.lang.NoClassDefFoundError:
com/fasterxml/jackson/annotation/JsonView}}{{ at
com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector.(JacksonAnnotationIntrospector.java:37)}}{{
at
com.fasterxml.jackson.databind.ObjectMapper.(ObjectMapper.java:291)}}{{
at
org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:151)}}{{
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1900)}}{{
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1848)}}{{
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1049)}}{{
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:910)}}
It's clearly missing a dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10577) ignite-kubernetes is missing jackson-annotations dependency
[
https://issues.apache.org/jira/browse/IGNITE-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Darlington updated IGNITE-10577:
Description:
When starting 2.7 with the ignite-kubernetes option I get the following
exception on startup:
{code}
[13:44:34,605][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).
java.lang.NoClassDefFoundError: com/fasterxml/jackson/annotation/JsonView
at
com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector.(JacksonAnnotationIntrospector.java:37)
at
com.fasterxml.jackson.databind.ObjectMapper.(ObjectMapper.java:291)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:151)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1900)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1848)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1049)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:910)
{code}
It's clearly missing a dependency.
was:
When starting 2.7 with the ignite-kubernetes option I get the following
exception on startup:
{{[13:44:34,605][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).}}{{java.lang.NoClassDefFoundError:
com/fasterxml/jackson/annotation/JsonView}}{{ at
com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector.(JacksonAnnotationIntrospector.java:37)}}{{
at
com.fasterxml.jackson.databind.ObjectMapper.(ObjectMapper.java:291)}}{{
at
org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:151)}}{{
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1900)}}{{
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1848)}}{{
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1049)}}{{
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:910)}}
It's clearly missing a dependency.
> ignite-kubernetes is missing jackson-annotations dependency
> ---
>
> Key: IGNITE-10577
> URL: https://issues.apache.org/jira/browse/IGNITE-10577
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.7
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Major
>
> When starting 2.7 with the ignite-kubernetes option I get the following
> exception on startup:
>
> {code}
> [13:44:34,605][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> java.lang.NoClassDefFoundError: com/fasterxml/jackson/annotation/JsonView
> at
> com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector.(JacksonAnnotationIntrospector.java:37)
> at
> com.fasterxml.jackson.databind.ObjectMapper.(ObjectMapper.java:291)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:151)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1900)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1848)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1049)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:910)
> {code}
>
> It's clearly missing a dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10155) Yardstick should allow modifier when starting servers
[ https://issues.apache.org/jira/browse/IGNITE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington resolved IGNITE-10155. - Resolution: Invalid Raised in wrong project. Closing. > Yardstick should allow modifier when starting servers > - > > Key: IGNITE-10155 > URL: https://issues.apache.org/jira/browse/IGNITE-10155 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > > Currently, Yardstick will start as many copies of Ignite as specified in the > configuration file. However there is currently no way to customise the > behaviour of each of those nodes. The example I'm currently working with is > forcing CPU affinity. > Related: it's also error prone to specify multiple nodes (when the number is > large). It would be nice to have some kind of shorthand to say you want, say, > four nodes on this particular host. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10155) Yardstick should allow modifier when starting servers
[ https://issues.apache.org/jira/browse/IGNITE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679566#comment-16679566 ] Stephen Darlington commented on IGNITE-10155: - Still a work in progress, but PR here: https://github.com/gridgain/yardstick/pull/29 > Yardstick should allow modifier when starting servers > - > > Key: IGNITE-10155 > URL: https://issues.apache.org/jira/browse/IGNITE-10155 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > > Currently, Yardstick will start as many copies of Ignite as specified in the > configuration file. However there is currently no way to customise the > behaviour of each of those nodes. The example I'm currently working with is > forcing CPU affinity. > Related: it's also error prone to specify multiple nodes (when the number is > large). It would be nice to have some kind of shorthand to say you want, say, > four nodes on this particular host. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10155) Yardstick should allow modifier when starting servers
[ https://issues.apache.org/jira/browse/IGNITE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington reassigned IGNITE-10155: --- Assignee: Stephen Darlington > Yardstick should allow modifier when starting servers > - > > Key: IGNITE-10155 > URL: https://issues.apache.org/jira/browse/IGNITE-10155 > Project: Ignite > Issue Type: Improvement > Components: yardstick >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > > Currently, Yardstick will start as many copies of Ignite as specified in the > configuration file. However there is currently no way to customise the > behaviour of each of those nodes. The example I'm currently working with is > forcing CPU affinity. > Related: it's also error prone to specify multiple nodes (when the number is > large). It would be nice to have some kind of shorthand to say you want, say, > four nodes on this particular host. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-1436) C++: Port to MAC OS.
[ https://issues.apache.org/jira/browse/IGNITE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Darlington reassigned IGNITE-1436: -- Assignee: Stephen Darlington > C++: Port to MAC OS. > > > Key: IGNITE-1436 > URL: https://issues.apache.org/jira/browse/IGNITE-1436 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Stephen Darlington >Priority: Major > Labels: cpp > > It will require minimal porting of "common" and "utils" stuff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10155) Yardstick should allow modifier when starting servers
Stephen Darlington created IGNITE-10155: --- Summary: Yardstick should allow modifier when starting servers Key: IGNITE-10155 URL: https://issues.apache.org/jira/browse/IGNITE-10155 Project: Ignite Issue Type: Improvement Components: yardstick Reporter: Stephen Darlington Currently, Yardstick will start as many copies of Ignite as specified in the configuration file. However there is currently no way to customise the behaviour of each of those nodes. The example I'm currently working with is forcing CPU affinity. Related: it's also error prone to specify multiple nodes (when the number is large). It would be nice to have some kind of shorthand to say you want, say, four nodes on this particular host. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9357) Spark Structured Streaming with Ignite as data source and sink
[ https://issues.apache.org/jira/browse/IGNITE-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620452#comment-16620452 ] Stephen Darlington commented on IGNITE-9357: I created a patch to this patch here: [https://github.com/sdarlington/ignite/commit/15df75bf60ab3cbd6f6936131d26be560a026d22] This is needed so that using an OffsetPolicy of 'timestamp' works correctly. > Spark Structured Streaming with Ignite as data source and sink > -- > > Key: IGNITE-9357 > URL: https://issues.apache.org/jira/browse/IGNITE-9357 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.7 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > We are working on a PoC where we want to use Ignite as a data storage and > Spark as a computation engine. We found that Ignite is supported neither as a > source nor as a Sink when using Spark Structured Streaming, which is a must > for us. > We are enhancing Ignite to support Spark streaming with Ignite. We will send > docs and code for review for the Ignite Community to consider if the > community wants to accept this feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
