Ignite Visor cache command freezes, when client node connects.
Hi, using 2.7.3
I start my client as...
TcpDiscoverySpi spi = new TcpDiscoverySpi();
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
ipFinder.setAddresses(addresses.getList());
spi.setIpFinder(ipFinder);
igniteConfig.setDiscoverySpi(spi);
igniteConfig.setClientMode(true);
I then also create a cache dynamically as...
CacheConfiguration cacheCfg = new CacheConfiguration("DJTAZZ");
cacheCfg.setCacheMode(CacheMode.REPLICATED);
this.cache =
igniteClient.getIgniteInstance().getOrCreateCache(cacheCfg);
In ignitegridvisor.sh when I run the "cache" command it seems to freeze
until I disconnect my application.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Extra console output from logs.
Nobody has experienced this? I'm not trying to disable logs. I'm just getting double the output... -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Extra console output from logs.
More precisely this is what we see...
This line is good:
{"appTimestamp":"2019-01-09T18:29:34.298+00:00","threadName":"vert.x-worker-thread-0","level":"INFO","loggerName":"org.apache.ignite.internal.IgniteKernal%xx-dev","message":"\n\n>>>
__ \n>>> / _/ ___/ |/ / _/_ __/ __/ \n>>>
_/ // (7 7// / / / / _/\n>>> /___/\\___/_/|_/___/ /_/ /___/ \n>>>
\n>>> ver. 2.7.0#20181130-sha1:256ae401\n>>> 2018 Copyright(C) Apache
Software Foundation\n>>> \n>>> Ignite documentation:
http://ignite.apache.org\n"}
The below shouldn't print:
[13:29:34]__
[13:29:34] / _/ ___/ |/ / _/_ __/ __/
[13:29:34] _/ // (7 7// / / / / _/
[13:29:34] /___/\___/_/|_/___/ /_/ /___/
[13:29:34]
[13:29:34] ver. 2.7.0#20181130-sha1:256ae401
[13:29:34] 2018 Copyright(C) Apache Software Foundation
[13:29:34]
[13:29:34] Ignite documentation: http://ignite.apache.org
[13:29:34]
[13:29:34] Quiet mode.
[13:29:34] ^-- Logging by 'Slf4jLogger
[impl=Logger[o.a.i.i.IgniteKernal%xx-dev], quiet=true]'
[13:29:34] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false
or "-v" to ignite.{sh|bat}
[13:29:34]
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Extra console output from logs.
Hi using 2.3.7 and Slf4J and a Json encoder so all our logs can print as Json. We setup the logger as follows... IgniteLogger log = new Slf4jLogger(); igniteConfig.setGridLogger(log); But we have noticed that there is duplicate output from Ignite to the console in the desired Json and plain console output. I remember reading somewhere there a bug related to this? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Single or multiple instances of Ignite and IgniteCache
I understand that Ignite and IgniteCache are thread safe... When I create my instance of Ignite is it better to instantiate multiple instances of both Ignite and IgniteCache or is it better to build them through a singleton? So far it doesn't seem to matter and it's easier to Ingnition.getOrStart() then to try to synchronize the creation of the grid instance. Also as an additional note Ignite is started as client only node... -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Ignite in container enviroments?
Ok I think I have possible solution... Based on: https://docs.mesosphere.com/1.11/networking/DNS/ The container IP is available at: .marathon.containerip.dcos.thisdcos.directory also according to the docs this will return the proper I.P if in container or bridge mode. Currently I only have working with container dc/os overlay. So if we enable Static TCP/IP discovery and set the env var: IGNITE_TCP_DISCOVERY_ADDRESSES to .marathon.containerip.dcos.thisdcos.directory where is the name we chose for application then this works. In fact I can now scale up and down easily. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Ignite in container enviroments?
Maybe allow amore general SPI that scans I.Ps based on wildcard. For example: 9.x.x.*? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Ignite in container enviroments?
Hi, on that note I will try the mesos framework. And a native IPFinder DC/OS would be appreciated (not swarm). >From what I see some Hazelcast folks have done something similar... This uses marathon: https://github.com/phaneesh/hazelcast-marathon-discovery This seems to just use the container I.Ps as is: https://github.com/unterstein/dcos-hazelcast -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Ignite in container enviroments?
Hi, from what I have tried and read it seems that you need host network for docker to run Ignite and overlay networks cause issues... I'm using DC/OS and I can technically maybe try the mesos deployment, but not sure how new or old that framework is. #1 the docs indicate to use: libs\optional\ignite-mesos\ignite-mesos--jar-with-dependencies.jar which doesn't exist in the downloaded zip of 2.7.0 #2 How do i know if it will workd with DC/OS 1.11 The next attempt that I got working is to use the Docker with DC/OS overlay network. This works by using the TCP discovery and setting 9.x.x.x addresses from DC/OS, the thing is with this you don't know which of the 9.x.x.x address the container will get assigned and I don't think we want to go put the full list of 9.x.x.x address just on the chance that the nodes will eventually ping the right addresses. The other option is to try to use a DC/OS load balanced VIP, but the address returned by the VIP is not the one the container see which is in the 9.x.x.x raange... -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: SQL Performance indexing performance on-heap vs off-heap
Just curious. What's the status of this has it been reproduced? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-tp1352p5778.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Getting IllegalStateException: Cache has been closed or destroyed: cache
Humm not sure... it seems consistent to one node. if I can figure it out I'll post more info. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Getting-IllegalStateException-Cache-has-been-closed-or-destroyed-cache-tp1631p1637.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Single key with multiple values or multi map?
Ok thanks -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Single-key-with-multiple-values-or-multi-map-tp1618p1629.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Getting IllegalStateException: Cache has been closed or destroyed: cache
Using 1.4.0, I have 4 nodes all running with -Xmx100g and it deems one node keeps going down with I have 32,000,000 total records in the cache not including the downed node. SEVERE: Unhandled exception java.lang.IllegalStateException: Cache has been closed or destroyed: cache at org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:161) at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:1826) at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.size(IgniteCacheProxy.java:753) at com.xxx.service.MyExtPrimService.lambda$start$6(MyExtPrimService.java:101) at com.xxx.service.MyExtPrimService$$Lambda$41/1511442228.handle(Unknown Source) at io.vertx.core.impl.VertxImpl$InternalTimerHandler.handle(VertxImpl.java:711) at io.vertx.core.impl.VertxImpl$InternalTimerHandler.handle(VertxImpl.java:682) at io.vertx.core.impl.ContextImpl.lambda$wrapTask$15(ContextImpl.java:314) at io.vertx.core.impl.ContextImpl$$Lambda$4/1615056168.run(Unknown Source) at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:357) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111) at java.lang.Thread.run(Thread.java:745) -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Getting-IllegalStateException-Cache-has-been-closed-or-destroyed-cache-tp1631.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Single key with multiple values or multi map?
Hi is there a way yo implement single key with multiple values? Thanks -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Single-key-with-multiple-values-or-multi-map-tp1618.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Btw anyone heard of CQ engine?
What I like about cq is the various index types it supports. Cqengine hash index is O(1) is the H2 hash index the same? And will ignite eventually enable it? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Btw-anyone-heard-of-CQ-engine-tp1421p1441.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Btw anyone heard of CQ engine?
Ok cool. I think if we have the options as users to pick the type of index per field it would be great. I think equality index is great for analytics purposes. In fact I'm trying to push ignite with 9 union queries with equality to search over millions of records if not billions. In my particular case the data doesn't change, but I need real fast lookup in the few milliseconds range. So I insert the object to the cache and then query the cache, but the object doesn't change. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Btw-anyone-heard-of-CQ-engine-tp1421p1445.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Can't seem to connect grid visor
I mean I can't connect visor to the grid lol -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Can-t-seem-to-connect-grid-visor-tp1442p1448.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Is it me or primitives as properties are alot faster?
Ok so here is more details...
Running 1.3.3 on single node single server with 32 cores
I had a MyModel as...
Switched to...
1- My SQL queries # of operations jumped from 18,000/sec to 54,000/sec.
2- Total cache size for 15 Million records went from 20GB on-heap usage to
just about 6.5GB on-heap usage.
Also if you business case allows it. Make sure you convert your models'
Strings properties into 64-bit long hash codes as much as possible
especially for indexes. I.e:
myModel.setMyField1(some64bitHashingFunction("This string value will be
stored as a 64 bit long"));
In my case I can do this because I don't care of the actual value, just
using the indexes to count stuff.
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Is-it-me-or-primitives-as-properties-are-alot-faster-tp1404p1408.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: SQL Performance indexing performance on-heap vs off-heap
I think I know what it is... I was using object types instead of primitive types. I switched all possible properties of my model from Object types to primitives and off-heap seems to be performing as you said about 20% slower then on heap, but there no performance decrease so far... Let me know if you guys find the same -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-tp1352p1409.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: SQL Performance indexing performance on-heap vs off-heap
Actually might be wrong primitives might not help... -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-tp1352p1411.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: SQL Performance indexing performance on-heap vs off-heap
Sergy, point taken, but what i'm trying to point out is the following... In on-heap mode I can easily insert and query 0-15,000,000 without any performance loss. And if anything even more then 15 million entries in the cache. The off-heap cache though instantly within a few thousand entries it's performance starts to degrade. Also for on-heap the query latency time stays consistent. So 1 entry or 15 million entries the query takes about the same time. This is not true for the off-heap it slowly degrades. To be clear we are talking about SQL queries and indexes. I posted my analysis in the threads above + the github code to reproduce it. I'm willing to even do a join.me to show you. I can reproduce it 100% of the time. Thanks -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-tp1352p1419.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: SQL Performance indexing performance on-heap vs off-heap
Sorry Dimitry, switching to primitives definitely helped me save on heap usage, but not performance. The issue I reported with off-heap is still true, it's alot slower then on-heap and gets slower over time as the cache grows... -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-tp1352p1416.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: SQL Performance indexing performance on-heap vs off-heap
Only 1 node and 1 physical machine so there's no network -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-tp1352p1394.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: SQL Performance indexing performance on-heap vs off-heap
Also I would like to mention this is tested on a single node with 32 cores. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-tp1352p1365.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: SQL Performance indexing performance on-heap vs off-heap
Ok I think I have managed to reproduce the issue. Here is the github code: https://github.com/javadevmtl/ignite-for-github The code is simple it launches a FixedThreadPool each worker executes a put and SQL query. The app can be launched in on-heap or off-heap mode The average time is calculated by: total time of execution / number of executions. on-heap 1 Million Entries: Avg 128128 nanos 2 Million Entries: Avg 141960 nanos 3 Million Entries: Avg 149321 nanos 4 Million Entries: Avg 167495 nanos off-heap 1 Million Entries: Avg 333946 nanos 2 Million Entries: Avg 433551 nanos 3 Million Entries: Avg 453551 nanos 4 Million Entries: Avg 546028 nanos As you can see on-heap is allot faster and far more stable in latency time. Off-heap seems to get slower and slower with the cache growing. The app is run as: java -jar -Xmx16g -XX:+UseG1GC -jar ignite-for-github-1.0-fat.jar on-heap 8 400 1000 130 Only the off-heap/on-heap flag and the number of entries are changed between runs... -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-tp1352p1364.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Is invokeAll() considered a batch operation?
Hi Yakov... Each physical server node is 32 cores. When I deploy my vertx.io application I tell it to create 32 instances of consumer.handler Vertx.io is much like node.js reactor pattern. Each request is put into an event loop and each instance of consume.handler will take 1 event from the loop and process it. Vertx underneath handles all the dirty work. So everything that runs inside consume would be as if it was 1 single thread. Though of course ignite will work in it's on thread pool, that doesn't change. As far as the keys goes it's arbitrary data so it's not attached to an identifier. Here are some questions I try to answer Given the person "John Smith" how many unique phone numbers does he have. Given the phone number "555-555-" how many unique persons are associated to it. The other way I was trying to this was using a a data model where each data is serialized, but secondary indexes where proving slow. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Is-invokeAll-considered-a-batch-operation-tp1220p1247.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Is invokeAll() considered a batch operation?
Sorry for the confusion... So... - Just to be clear running 1.3.0 on 2 nodes with total of 64 cores and 256GB of RAM - Cache is configured as off-heap partitioned no backups with 96GB and each node is started as -Xmx4g - Each app is a web server that receives json request that parses the json and inserts the json properties as different keys (27 total). - Requests are load balanced to both nodes. All times quoted below includes full business logic and network time. The json payload sent always contains the 27 properties. Only the app is recompiled to either invokeAll() for 1 key 3 keys, 9 keys etc... Also time remains constant from 0 records inserted all the way up to millions (so at least this is good thing) which also means java is sufficiently warmed up with millions of calls. 01 keys: 2ms 03 keys: 4ms 09 keys: 9ms 18 keys: 16ms 27 keys: 25ms I was maybe hopping slightly better latency... Here is the code maybe you have suggestions on improvements? http://pastebin.com/pR36DwdG -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Is-invokeAll-considered-a-batch-operation-tp1220p1238.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Query performance
Cool I let you know about performance. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Re-Query-performance-tp1009p1192.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Query performance
So 2 different web requests will put new objects in and then run the same queries, but each web request needs to have it's own responses back. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Re-Query-performance-tp1009p1161.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Query performance
Anyways I think I will go down the key/value route it's so much faster. 1- In the query approach I was able to do atomic operations since each request yielded a new entry in the cache and I never had to update. But queries for now seem a bit slow. 2- Using key/value approach speed of put is alot faster but now I have to worry about possibly updating same key multiple times. But entry processor seems to do what I need. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Re-Query-performance-tp1009p1168.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
