Ignite Affinity & Binary Configuration Issues

[addo]

Hello Igniters,

As we've been trying to utilize Ignite, some issues were identified which
did not seem logical at first sight. When we introduced data and compute
collocation (affinity), there were some "hacks" and "tweaks" that were
needed so that it would function properly. I will first delineate the
scenarios which resulted in the odd behavior.

The following scenarios assume you have :
* 2 Ignite server nodes (S1 and S2) 
* A client node (C1)
* A cache:
--- Custom affinity key mapper
--- Cache mode partitioned
--- Write synchronization set to primary sync
* A key (K1) to-be-stored and its value in the cache is 1 { .put(K1, 1) }
--- K1 is a simple POJO (3 fields as String, 1 field as a primitive int)

Scenario #1 - Binary Configuration
- Get or create cache via C1
- Put K1 with a value of 1
- Affinity run on cache with K1 as the affinity key
- Ignite node where K1 is stored could not find key in its cache (the
partitions it owns)

Solution to #1 - Explicitly define a binary configuration to the POJO

Scenario #2 - Affinity Key Mapper
- Add a custom affinity key mapper that points to a String field in K1
- Run scenario #1 again
- Affinity run on cache with K1 could not find the key in the node chosen

Solution to #2 - Add a condition in the key mapper of when the key is a
Binary Object
We've found that, at some point, the cache was calling its affinity key
mapper on a Binary Object (and our first implementation did not take that
into account).

The questions that we're trying to answer:
1. Shouldn't ignite handle POJO affinity keys out-of-the-box?
2. Do I have to modify my binary configuration every time I need to use a
new POJO as an affinity key?
3. Does switching the serialization framework to something like Kryo solves
this automatically?
4. What other options can we have to solve this?

Thank you for your time and effort in reading this long (and hopefully
interesting) post. We'll be looking forward to your replies. Please find
*attached* the code to reproduce the issues.

Kind regards,

Addo

ignite-samples.rar
 
 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-Affinity-Binary-Configuration-Issues-tp11897.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite may start more service instances per node than maxPerNodeCount in case of manual redeploy

[Andrey Mashenkov]

Hi Evgeniy,

I've fixed the issue.
PFA a patch.

On Tue, Apr 4, 2017 at 12:23 AM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:

> Hi Evgeniy,
>
> Looks like a bug. I've created a ticket [1].
> Seems, this reporoduced only when service deployment with dynamic
> approach. When Ignite starts with service configured - all looks fine for
> me.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4907
>
> On Mon, Apr 3, 2017 at 4:26 PM, Evgeniy Ignatiev <
> yevgeniy.ignat...@gmail.com> wrote:
>
>> Hello.
>>
>> Recently we discovered that if a service is configured in
>> IgniteConfiguration with e.g. maxPerNodeCount equal to 1 and totalCount
>> equal to 3, we start-up 2 Ignite nodes - then cancel the service after some
>> time and redeploy it with the same config as ignite.services().deploy(...)
>> - we observe more than instance of service starting per node.
>>
>> Here is a minimal code that demonstrates this issue:
>> https://github.com/YevIgn/ignite-services-bug - After the call to
>> ignite.services().deploy(...) - the output to console is "Started 3
>> services" while "Started 2 services" is expected as there are only two
>> nodes. This is with the Ignite 1.9.0.
>>
>> Could you please look into it?
>>
>>
>>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>



-- 
Best regards,
Andrey V. Mashenkov
Index: modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeSelfTest.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeSelfTest.java	(date 149147903)
+++ modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeSelfTest.java	(date 1491990083000)
@@ -264,4 +264,65 @@
 stopGrid("client");
 }
 }
+
+/**
+ * @throws Exception If failed.
+ */
+public void testDeployLimits() throws Exception {
+String name = "serviceWithLimitsUpdateTopology";
+
+Ignite g = randomGrid();
+
+final int totalInstances = nodeCount() + 1;
+
+CountDownLatch latch = new CountDownLatch(nodeCount());
+
+DummyService.exeLatch(name, latch);
+
+ServiceConfiguration srvcCfg = new ServiceConfiguration();
+
+srvcCfg.setName(name);
+srvcCfg.setMaxPerNodeCount(1);
+srvcCfg.setTotalCount(totalInstances);
+srvcCfg.setService(new DummyService());
+
+IgniteServices svcs = g.services().withAsync();
+
+svcs.deploy(srvcCfg);
+
+IgniteFuture fut = svcs.future();
+
+info("Deployed service: " + name);
+
+fut.get();
+
+info("Finished waiting for service future: " + name);
+
+latch.await();
+
+TestCase.assertEquals(name, nodeCount(), DummyService.started(name));
+TestCase.assertEquals(name, 0, DummyService.cancelled(name));
+
+checkCount(name, g.services().serviceDescriptors(), nodeCount());
+
+int extraNodes = 2;
+
+latch = new CountDownLatch(1);
+
+DummyService.exeLatch(name, latch);
+
+startExtraNodes(2);
+
+try {
+latch.await();
+
+TestCase.assertEquals(name, totalInstances, DummyService.started(name));
+TestCase.assertEquals(name, 0, DummyService.cancelled(name));
+
+checkCount(name, g.services().serviceDescriptors(), totalInstances);
+}
+finally {
+stopExtraNodes(extraNodes);
+}
+}
 }
\ No newline at end of file
Index: modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeConfigSelfTest.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeConfigSelfTest.java	(date 1488459441000)
+++ modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeConfigSelfTest.java	(revision )
@@ -17,8 +17,11 @@
 
 package org.apache.ignite.internal.processors.service;
 
+import java.util.ArrayList;
+import java.util.List;
 import java.util.concurrent.CountDownLatch;
 import org.apache.ignite.Ignite;
+import org.apache.ignite.internal.IgniteInterruptedCheckedException;
 import org.apache.ignite.internal.util.lang.GridAbsPredicateX;
 import org.apache.ignite.services.ServiceConfiguration;
 import org.apache.ignite.testframework.GridTestUtils;
@@ -33,6 +36,9 @@
 /** Node singleton name. */
 private static final String NODE_SINGLE = "serviceConfigEachNode";
 
+/** Node singleton name. */
+private static

Re: Client got stucked on get operation

[Alper Tekinalp]

Hi.

We encountered the same situation again. That time we get the following
error:

12/Apr/2017 10:08:17 ERROR 72832749 exchange-worker-#199%null%
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture(L:495)
- Failed to reinitialize local partitions (preloading will be stopped):
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=46,
minorTopVer=45], nodeId=172e4264, evt=DISCOVERY_CUSTOM_EVT]
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:747)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:413)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:571)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:454)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1670)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
12/Apr/2017 10:08:18 ERROR 72833126 exchange-worker-#199%null%
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager(L:495)
- Runtime error caught during grid runnable execution: GridWorker
name=partition-exchanger,
gridName=null, finished=false, isCancelled=false, hashCode=148876,
interrupted=false, runner=exchange-worker-#199%null%
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.partitionMap(GridDhtPartitionTopologyImpl.java:973)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.createPartitionsFullMessage(GridCachePartitionExchangeManager.java:855)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createPartitionsMessage(GridDhtPartitionsExchangeFuture.java:966)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendAllPartitions(GridDhtPartitionsExchangeFuture.java:977)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendAllPartitions(GridDhtPartitionsExchangeFuture.java:1313)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceive(GridDhtPartitionsExchangeFuture.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$7.apply(GridCachePartitionExchangeManager.java:1295)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$7.apply(GridCachePartitionExchangeManager.java:1292)
at
org.apache.ignite.internal.util.future.GridFutureAdapter$ArrayListener.apply(GridFutureAdapter.java:456)
at
org.apache.ignite.internal.util.future.GridFutureAdapter$ArrayListener.apply(GridFutureAdapter.java:439)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1053)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:88)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:343)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:512)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1670)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)

After that exchange-worker dies and all put and get operations blocks.

1 - What does above error mean? When does it happen?
2 - Is there a way to avoid or recover from that state?

Regards.

On Thu, Apr 6, 2017 at 5:50 PM, Andrey Mashenkov  wrote:

> Hi Alper,
>
> I see no starvation here. Looks like WriteBehindStore waits for its queue
> has flushed.
> Threaddump is needed to understand if Flusher threads also waits for smth.
>
> On Thu, Apr 6, 2017 at 4:40 PM, Alper Tekinalp  wrote:
>
>> Hi Andrey.
>>
>> Ignite logs are at the attachment.
>>
>> Interruption exception is on 30/Mar/2017 1

Ignite server showing this error class org.apache.ignite.IgniteCheckedException: Failed to send message (node may have left the grid or TCP connection cannot be established due to firewall issues)

[Andrey Mashenkov]

Hi,

Please properly subscribe to the mailing list so that the community can
receive email notifications for your messages. To subscribe, send empty
email to user-subscr...@ignite.apache.org and follow simple instructions in
the reply.

Stopping node should cancel all its tasks automatically. There is no need
to stop task explicitly.
Do you mean that hanged task prevents node from being stopped?

You wrote:

How to stop distributing task to stopped node, which already have left the
> topology . We are facing problem in my application somehow tasks are going
> to the stopped node and getting exception like "Grid is in invalid state to
> perform this operation. It either not started yet or has already being or
> have stopped "
> Any suggestion please ?
> Thanks,
> Pankaj Pushp


-- 
Best regards,
Andrey V. Mashenkov

Re: Client got stucked on get operation

[Andrey Mashenkov]

Hi Alper,


Looks weird. Seems cache descriptor was not initialized by some reason or
cache was destroyed unexpectedly.
Most possibly, there is a race and there is no way to recover.


On Wed, Apr 12, 2017 at 3:00 PM, Alper Tekinalp  wrote:

> Hi.
>
> We encountered the same situation again. That time we get the following
> error:
>
> 12/Apr/2017 10:08:17 ERROR 72832749 exchange-worker-#199%null%
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture(L:495) - Failed to reinitialize local
> partitions (preloading will be stopped): GridDhtPartitionExchangeId 
> [topVer=AffinityTopologyVersion
> [topVer=46, minorTopVer=45], nodeId=172e4264, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
> at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.
> initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:747)
> at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.
> onCacheChangeRequest(CacheAffinitySharedManager.java:413)
> at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture.onCacheChangeRequest(
> GridDhtPartitionsExchangeFuture.java:571)
> at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFutur
> e.java:454)
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager$ExchangeWorker.body(
> GridCachePartitionExchangeManager.java:1670)
> at org.apache.ignite.internal.util.worker.GridWorker.run(
> GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> 12/Apr/2017 10:08:18 ERROR 72833126 exchange-worker-#199%null%
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager(L:495)
> - Runtime error caught during grid runnable execution: GridWorker 
> name=partition-exchanger,
> gridName=null, finished=false, isCancelled=false, hashCode=148876,
> interrupted=false, runner=exchange-worker-#199%null%
> java.lang.NullPointerException
> at org.apache.ignite.internal.processors.cache.distributed.dht.
> GridDhtPartitionTopologyImpl.partitionMap(GridDhtPartitionTopologyImpl.
> java:973)
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager.createPartitionsFullMessage(
> GridCachePartitionExchangeManager.java:855)
> at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture.createPartitionsMessage(
> GridDhtPartitionsExchangeFuture.java:966)
> at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture.sendAllPartitions(
> GridDhtPartitionsExchangeFuture.java:977)
> at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture.sendAllPartitions(
> GridDhtPartitionsExchangeFuture.java:1313)
> at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture.onReceive(GridDhtPartitionsExchangeFutur
> e.java:1142)
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager$7.apply(GridCachePartitionExchangeMana
> ger.java:1295)
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager$7.apply(GridCachePartitionExchangeMana
> ger.java:1292)
> at org.apache.ignite.internal.util.future.GridFutureAdapter$
> ArrayListener.apply(GridFutureAdapter.java:456)
> at org.apache.ignite.internal.util.future.GridFutureAdapter$
> ArrayListener.apply(GridFutureAdapter.java:439)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> notifyListener(GridFutureAdapter.java:271)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> notifyListeners(GridFutureAdapter.java:259)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> onDone(GridFutureAdapter.java:389)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> onDone(GridFutureAdapter.java:355)
> at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFutur
> e.java:1053)
> at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFutur
> e.java:88)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> onDone(GridFutureAdapter.java:343)
> at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.
> GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFutur
> e.java:512)
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager$ExchangeWorker.body(
> GridCachePartitionExchangeManager.java:1670)
> at org.apache.ignite.internal.util.worker.GridWorker.run(
> GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
>
> After that exchange-worker dies and all put and get operations blocks.
>
> 1 - What does above error mean? When does it happen?
> 2 -

Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[bintisepaha]

Thanks for trying, is the node filter an issue someone else is seeing?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Pessimistic-TXN-did-not-release-lock-on-a-key-all-subsequent-txns-failed-tp10536p11905.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Lots of cache creation become slow

[ctranxuan]

Thanks a lot for the answer! 
We'll try to run tests with these hints.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Lots-of-cache-creation-become-slow-tp11875p11906.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite server showing this error class org.apache.ignite.IgniteCheckedException: Failed to send message (node may have left the grid or TCP connection cannot be established due to firewall issue

[vdpyatkov]

Hi,

The message appear when operation try to execute on stopping (or starting)
node.
If the message was throwed then means node out of cluster.

Tasks which will be execute in the node should be rout to another (by
failover SPI)

Please, explain where are you sow problem?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-server-showing-this-error-class-org-apache-ignite-IgniteCheckedException-Failed-to-send-messa-tp11871p11907.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Slow on 1st time query "SQL Join"

[afedotov]

Hi Charles,

You are running the query from a client node what implies additional
network round trips.
Try to run queries from a server node. In my environment it reduced the
time from about 7 seconds to 220ms for the first run.

Kind regards,
Alex.

On Wed, Apr 12, 2017 at 9:21 AM, woo charles [via Apache Ignite Users] <
ml-node+s70518n11896...@n6.nabble.com> wrote:

> *Sorry for wrong calculation *
> *-> (i.e. 3 Server node stored 236MB [2.2MB * 20 table +3.2MB * 60 table]
> data)*
>
> *Best Regards,*
> *Charles*
>
> 2017-04-12 10:17 GMT+08:00 woo charles <[hidden email]
> >:
>
>> *Source
>> code: https://drive.google.com/open?id=0B_-zUEFkybdLQVF4U2dwTE11ajA
>> *
>>
>> *Below is a screen cap on GridGain's web console & the log of my client
>> program. *
>> *(i.e. 3 Server node stored 756MB [2.2MB * 10 table +3.2MB * 30 table]
>> data)*
>> [image: 內置圖片 2]
>>
>> Apr 12, 2017 9:50:10 AM java.util.logging.LogManager$RootLogger log
>> SEVERE: Failed to resolve default logging config file:
>> config/java.util.logging.properties
>> [09:50:10]__  
>> [09:50:10]   /  _/ ___/ |/ /  _/_  __/ __/
>> [09:50:10]  _/ // (7 7// /  / / / _/
>> [09:50:10] /___/\___/_/|_/___/ /_/ /___/
>> [09:50:10]
>> [09:50:10] ver. 1.8.0#20161205-sha1:9ca40dbe
>> [09:50:10] 2016 Copyright(C) Apache Software Foundation
>> [09:50:10]
>> [09:50:10] Ignite documentation: http://ignite.apache.org
>> [09:50:10]
>> [09:50:10] Quiet mode.
>> [09:50:10]   ^-- To see **FULL** console log here add
>> -DIGNITE_QUIET=false or "-v" to ignite.{sh|bat}
>> [09:50:10]
>> [09:50:10] OS: Linux 3.10.0-123.el7.x86_64 amd64
>> [09:50:10] VM information: Java(TM) SE Runtime Environment 1.8.0_121-b13
>> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.121-b13
>> [09:50:10] Initial heap size is 128MB (should be no less than 512MB, use
>> -Xms512m -Xmx512m).
>> [09:50:10] Configured plugins:
>> [09:50:10]   ^-- None
>> [09:50:10]
>> [09:50:10] Security status [authentication=off, tls/ssl=off]
>> [09:50:11] To start Console Management & Monitoring run
>> ignitevisorcmd.{sh|bat}
>> [09:50:11]
>> [09:50:11] Ignite node started OK (id=b663472c)
>> [09:50:11] Topology snapshot [ver=19, servers=3, clients=1, CPUs=8,
>> heap=3.1GB]
>> PreLoadDataSize = 1
>> NumOfTest = 2
>> /--- Test 0 ---\
>> Name = SQL_Select_2_Join_10
>> ActionType = SQL_SELECT_2_JOIN
>> Object class = com.performance.test.dao.Quote
>> Thread Size = 80
>> [09:50:20] New version is available at ignite.apache.org: 1.9.0
>> MaxTime(First Time): 12710
>> Thread [SQL_Select_2_Join_10] Average Time: 18.913ms - 0.018913s, Max
>> Time: 183ms
>> \-/
>> /--- Test 1 ---\
>> Name = QUERY_Quote_price_large_1000_Small_950
>> ActionType = QUERY
>> Object class = com.performance.test.dao.Quote
>> Thread Size = 80
>> MaxTime(First Time): 30
>> Thread [QUERY_Quote_price_large_1000_Small_950] Average Time: 118.752ms
>> - 0.118752s, Max Time: 1094ms
>> \-/
>>
>> *Also, I found that 1st **SQL J**oin query time reduced about 2 - 3s if
>> my program's memory **increase** from 128mb to 1gb.*
>> *Is it show that this problem is due to client side not server side?*
>>
>> *Best Regards,*
>> *Charles*
>>
>>
>> 2017-04-11 23:29 GMT+08:00 afedotov <[hidden email]
>> >:
>>
>>> I'm not able to reproduce the timings you specified. Probably I do
>>> something wrong.
>>> Could you please provide a log for that case?
>>> Also, it would be of great help if you provide the reproducer sources.
>>>
>>> Kind regards,
>>> Alex.
>>>
>>> On Tue, Apr 11, 2017 at 4:57 AM, woo charles [via Apache Ignite Users] 
>>> <[hidden
>>> email] > wrote:
>>>
 My testing program: https://drive.google.com/open?
 id=0B_-zUEFkybdLcW5LR3RXZnJfOFE

 It runs on linux system with 8cpu 24gb ram.
 3 Server node(each 1 gb) are created.
 20 set tables created(ie. 1 set table contain table Quote, StockInfo,
 BidAskBrokerQueue, PreviousQuote which mean 20*4 = 80 table created)
 Each table will insert 1 records.

 After inserted data, sql join "select q.stock_id, q.price , s.symbol
 from Quote0.Quote as q, StockInfo0.StockInfo as s where  q.stock_id =
 s.stock_id and q.stock_id = XXX" is perform.

 And about 13s is needed for the first sql query.


 2017-04-10 14:53 GMT+08:00 Sergi Vladykin <[hidden email]
 >:

> I think 13s is still too much. Can you share a reproducer?
>
> Sergi
>
> 2017-04-10 9:51 GMT+03:00 afedotov <[hidden email]
> 

Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[Andrey Gura]

As far as I know no one has such a problems.

On Wed, Apr 12, 2017 at 4:15 PM, bintisepaha  wrote:
> Thanks for trying, is the node filter an issue someone else is seeing?
>
>
>
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Pessimistic-TXN-did-not-release-lock-on-a-key-all-subsequent-txns-failed-tp10536p11905.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Repeatable cache updates

[nskovpin]

Hello, Ignite team!
Assume that i have a big cache A (key - id, value - date, etc ). This cache
is being updated every 5 minutes. My question is: what is the best way to
update my other caches, that were built from cache A (value has a field
"date"). I have some thoughts:
1) I can create broadcast or computeTask, than read A's local entries and
update another caches (but i should read all my entries, even they haven't
updated yet)
2) I can create cacheEvents and update another caches - but i've read that
events are designed more for auditing purposes. 
3) I can create continuous query, but i don't need to query my data:)



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Repeatable-cache-updates-tp11910.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Repeatable cache updates

[Andrey Mashenkov]

Hi,

3) Initial query is not mandatory, you can set it to null to receive
updates only.

Also, you can try CacheInterceptor to update other caches synchronously. It
can cause performance issues as
CacheInterceptor methods are called from sensitive part of code inside
synchronized block, but it should be ok,
if you update same key in another cache and it is one-way cache
synchronization (so, deadlock is not possible).


On Wed, Apr 12, 2017 at 7:18 PM, nskovpin  wrote:

> Hello, Ignite team!
> Assume that i have a big cache A (key - id, value - date, etc ). This cache
> is being updated every 5 minutes. My question is: what is the best way to
> update my other caches, that were built from cache A (value has a field
> "date"). I have some thoughts:
> 1) I can create broadcast or computeTask, than read A's local entries and
> update another caches (but i should read all my entries, even they haven't
> updated yet)
> 2) I can create cacheEvents and update another caches - but i've read that
> events are designed more for auditing purposes.
> 3) I can create continuous query, but i don't need to query my data:)
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Repeatable-cache-updates-tp11910.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Best regards,
Andrey V. Mashenkov

Error During data Loading using Ignite Data Streamer in Parallel

[rishi007bansod]

Hi,
 I am loading data from kafka to ignite data streamers in parallel in
multiple ignite nodes. But when I kill one of these nodes(for checking fault
tolerance), I am getting following error. Some Messages are also getting
lost.

class org.apache.ignite.IgniteCheckedException: Failed to finish operation
(too many remaps): 32
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:863)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$5.apply(DataStreamerImpl.java:828)
at
org.apache.ignite.internal.util.future.GridFutureAdapter$ArrayListener.apply(GridFutureAdapter.java:456)
at
org.apache.ignite.internal.util.future.GridFutureAdapter$ArrayListener.apply(GridFutureAdapter.java:439)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:271)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:259)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:389)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:355)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:343)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.submit(DataStreamerImpl.java:1716)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.update(DataStreamerImpl.java:1416)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.load0(DataStreamerImpl.java:932)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:576)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:544)
at
org.apache.ignite.stream.StreamAdapter.addMessage(StreamAdapter.java:184)
at
org.apache.ignite.stream.kafka.KafkaStreamer.access$100(KafkaStreamer.java:47)
at
org.apache.ignite.stream.kafka.KafkaStreamer$1.run(KafkaStreamer.java:156)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: class
org.apache.ignite.internal.cluster.ClusterTopologyCheckedException: Failed
to send request (node has left): 0a04411f-a797-4526-826a-96c52549b0d0
... 11 more
[21:45:24] (err) Failed to execute compound future reducer:
GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=1, done=false,
cancelled=false, err=null, futs=[false, false, true, false, false, true,
false, false]]class org.apache.ignite.IgniteCheckedException: DataStreamer
request failed [node=f48edaa8-74df-4503-bf9b-1fdc6d642744]
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1777)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:335)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1215)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:843)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:108)
at
org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:783)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745) 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Error-During-data-Loading-using-Ignite-Data-Streamer-in-Parallel-tp11912.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Lots of cache creation become slow

[Alexey Kuznetsov]

Cédric,

Just, curious, what for do you need 2000 caches on single node? :)


On Wed, Apr 12, 2017 at 8:47 PM, ctranxuan 
wrote:

> Thanks a lot for the answer!
> We'll try to run tests with these hints.
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Lots-of-cache-creation-become-slow-tp11875p11906.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Alexey Kuznetsov

Re: Repeatable cache updates

[Andrey Mashenkov]

Hi

2) Also you can subscribe to local node events and update other caches when
event is received on primary node for key to avoid excessive calls.



On Wed, Apr 12, 2017 at 7:35 PM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:

> Hi,
>
> 3) Initial query is not mandatory, you can set it to null to receive
> updates only.
>
> Also, you can try CacheInterceptor to update other caches synchronously.
> It can cause performance issues as
> CacheInterceptor methods are called from sensitive part of code inside
> synchronized block, but it should be ok,
> if you update same key in another cache and it is one-way cache
> synchronization (so, deadlock is not possible).
>
>
> On Wed, Apr 12, 2017 at 7:18 PM, nskovpin  wrote:
>
>> Hello, Ignite team!
>> Assume that i have a big cache A (key - id, value - date, etc ). This
>> cache
>> is being updated every 5 minutes. My question is: what is the best way to
>> update my other caches, that were built from cache A (value has a field
>> "date"). I have some thoughts:
>> 1) I can create broadcast or computeTask, than read A's local entries and
>> update another caches (but i should read all my entries, even they haven't
>> updated yet)
>> 2) I can create cacheEvents and update another caches - but i've read that
>> events are designed more for auditing purposes.
>> 3) I can create continuous query, but i don't need to query my data:)
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Repeatable-cache-updates-tp11910.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Slow on 1st time query "SQL Join"

[Sergi Vladykin]

Alex,

Why do we have such a huge difference between client nodes and server
nodes? Looks like we should fix it if possible. Even 7 seconds looks too
much for me.

Sergi

2017-04-12 18:11 GMT+03:00 afedotov :

> Hi Charles,
>
> You are running the query from a client node what implies additional
> network round trips.
> Try to run queries from a server node. In my environment it reduced the
> time from about 7 seconds to 220ms for the first run.
>
> Kind regards,
> Alex.
>
> On Wed, Apr 12, 2017 at 9:21 AM, woo charles [via Apache Ignite Users] 
> <[hidden
> email] > wrote:
>
>> *Sorry for wrong calculation *
>> *-> (i.e. 3 Server node stored 236MB [2.2MB * 20 table +3.2MB * 60 table]
>> data)*
>>
>> *Best Regards,*
>> *Charles*
>>
>> 2017-04-12 10:17 GMT+08:00 woo charles <[hidden email]
>> >:
>>
>>> *Source
>>> code: https://drive.google.com/open?id=0B_-zUEFkybdLQVF4U2dwTE11ajA
>>> *
>>>
>>> *Below is a screen cap on GridGain's web console & the log of my client
>>> program. *
>>> *(i.e. 3 Server node stored 756MB [2.2MB * 10 table +3.2MB * 30 table]
>>> data)*
>>> [image: 內置圖片 2]
>>>
>>> Apr 12, 2017 9:50:10 AM java.util.logging.LogManager$RootLogger log
>>> SEVERE: Failed to resolve default logging config file:
>>> config/java.util.logging.properties
>>> [09:50:10]__  
>>> [09:50:10]   /  _/ ___/ |/ /  _/_  __/ __/
>>> [09:50:10]  _/ // (7 7// /  / / / _/
>>> [09:50:10] /___/\___/_/|_/___/ /_/ /___/
>>> [09:50:10]
>>> [09:50:10] ver. 1.8.0#20161205-sha1:9ca40dbe
>>> [09:50:10] 2016 Copyright(C) Apache Software Foundation
>>> [09:50:10]
>>> [09:50:10] Ignite documentation: http://ignite.apache.org
>>> [09:50:10]
>>> [09:50:10] Quiet mode.
>>> [09:50:10]   ^-- To see **FULL** console log here add
>>> -DIGNITE_QUIET=false or "-v" to ignite.{sh|bat}
>>> [09:50:10]
>>> [09:50:10] OS: Linux 3.10.0-123.el7.x86_64 amd64
>>> [09:50:10] VM information: Java(TM) SE Runtime Environment 1.8.0_121-b13
>>> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.121-b13
>>> [09:50:10] Initial heap size is 128MB (should be no less than 512MB, use
>>> -Xms512m -Xmx512m).
>>> [09:50:10] Configured plugins:
>>> [09:50:10]   ^-- None
>>> [09:50:10]
>>> [09:50:10] Security status [authentication=off, tls/ssl=off]
>>> [09:50:11] To start Console Management & Monitoring run
>>> ignitevisorcmd.{sh|bat}
>>> [09:50:11]
>>> [09:50:11] Ignite node started OK (id=b663472c)
>>> [09:50:11] Topology snapshot [ver=19, servers=3, clients=1, CPUs=8,
>>> heap=3.1GB]
>>> PreLoadDataSize = 1
>>> NumOfTest = 2
>>> /--- Test 0 ---\
>>> Name = SQL_Select_2_Join_10
>>> ActionType = SQL_SELECT_2_JOIN
>>> Object class = com.performance.test.dao.Quote
>>> Thread Size = 80
>>> [09:50:20] New version is available at ignite.apache.org: 1.9.0
>>> MaxTime(First Time): 12710
>>> Thread [SQL_Select_2_Join_10] Average Time: 18.913ms - 0.018913s, Max
>>> Time: 183ms
>>> \-/
>>> /--- Test 1 ---\
>>> Name = QUERY_Quote_price_large_1000_Small_950
>>> ActionType = QUERY
>>> Object class = com.performance.test.dao.Quote
>>> Thread Size = 80
>>> MaxTime(First Time): 30
>>> Thread [QUERY_Quote_price_large_1000_Small_950] Average Time: 118.752ms
>>> - 0.118752s, Max Time: 1094ms
>>> \-/
>>>
>>> *Also, I found that 1st **SQL J**oin query time reduced about 2 - 3s if
>>> my program's memory **increase** from 128mb to 1gb.*
>>> *Is it show that this problem is due to client side not server side?*
>>>
>>> *Best Regards,*
>>> *Charles*
>>>
>>>
>>> 2017-04-11 23:29 GMT+08:00 afedotov <[hidden email]
>>> >:
>>>
 I'm not able to reproduce the timings you specified. Probably I do
 something wrong.
 Could you please provide a log for that case?
 Also, it would be of great help if you provide the reproducer sources.

 Kind regards,
 Alex.

 On Tue, Apr 11, 2017 at 4:57 AM, woo charles [via Apache Ignite Users]
 <[hidden email] >
 wrote:

> My testing program: https://drive.google.com/open?
> id=0B_-zUEFkybdLcW5LR3RXZnJfOFE
>
> It runs on linux system with 8cpu 24gb ram.
> 3 Server node(each 1 gb) are created.
> 20 set tables created(ie. 1 set table contain table Quote, StockInfo,
> BidAskBrokerQueue, PreviousQuote which mean 20*4 = 80 table created)
> Each table will insert 1 records.
>
> After inserted data, sql join "select q.stock_id, q.price , s.symbol
> from Quote0.Quote as q, StockInfo0.StockInfo as s where  q.stock_id =
> s.stock_id and q.stock_id = XXX" is perform.
>
> And ab

Re: Ignite on FreeBSD 11 and OpenJDK

[Kamil Misuth]

Hi Andrey,

I've built ignite-3477-master (commit hash 5839f481b7) today.
Apart from the fact that some other Configuration APIs changed, 
CacheMemoryMode disapeared. I guess this is related to 
http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-4758-introducing-cache-memory-policies-td14957.html


Anyway, I've got the following exception on the first try, since 
ignite-indexing 2.0.0 is compiled against H2 1.4.191 and Spring Boot 
1.5.2.RELEASE managed H2 version is 1.4.193 and apparently 
org.h2.result.Row changed from abstract class to an interface between 
the two versions.


Caused by: java.lang.IncompatibleClassChangeError: class 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Row has 
interface org.h2.result.Row as super class


After fixing the dependency issue, I've tried to create two node cluster 
and JVM SIGSEGVed in DirectNioClientWorker just as before.


Attaching crash logs from both nodes (running on the same machine 
FreeBSD 11) to this e-mail.


Kamil

On 2017-04-12 00:49, Kamil Misuth wrote:

Sure thing.

I will check out ignite-3477-master as soon as I have some time 
tomorrow.


Kamil


On 04/11/2017 05:48 PM, Andrey Gura wrote:

Thanks for provided information. I need additional time for problem
investigation.

You can also try code from ignite-3477-master branch. This branch
contains many memory related fixes but it isn't stable yet.

On Mon, Apr 10, 2017 at 11:37 PM, kimec.ethome.sk  
wrote:

Hi Andrey,

sorry, I've got ahead of my self.

I am on FreeBSD 11.0-RELEASE-p1 amd64
With OpenJDK Runtime Environment 1.8.0_121-b13 Oracle Corporation 
OpenJDK

64-Bit Server VM 25.121-b13
hw.model: Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz
hw.machine_arch: amd64
hw.ncpu: 8
hw.physmem: 8251813888

Core dump is 1 GB, so I guess that is no go. I am attaching crash log 
to

this e-mail.
I have uploaded the project I've used during my testing here
https://github.com/kimec/ignite-spring-boot .
The sample works perfectly well with stock ignite-core on Linux 
OpenJDK 8

xs64 CentOS 7 .

Kamil



On 2017-04-10 12:24, Andrey Gura wrote:

Hi,

could you please share core dump file? If not, it would be helpful 
to

know what is CPU architecture on this server.

On Mon, Apr 10, 2017 at 2:53 AM, Kamil Misuth  
wrote:

Greetings,

OpenJDK (7 and 8) HotSpot JVM SIGSEGVs on FreeBSD 11 as soon as 
node

joins a
topology and starts to communicate via DirectNioClientWorker.
The root cause is DirectByteBufferStreamImpl (both versions) which 
uses

GridUnsafe.getXXX/putXXX(Object object, offset, value) methods to
manipulate
DirectByteBuffer, whereas it should really be using
GridUnsafe.getXXX/putXXX(address, value), since DirectByteBuffer is
allocated on C heap (off java heap).
Notice that at least one instance of the same problem is known to 
exist

in
another project using Unsafe
https://issues.apache.org/jira/browse/CASSANDRA-8325 .
The OpenJDK source of Unsafe is more or less clear on this

http://hg.openjdk.java.net/jdk8u/jdk8u60/jdk/file/935758609767/src/share/classes/sun/misc/Unsafe.java#l391
I have prepared a simple fix here

https://github.com/apache/ignite/compare/1.9.0-rc2...kimec:freebsd-support 
.
However, I am not sure if the solution is right in regard to 
overall

ignite
performance.
I've tried to compile ignite-core with tests and after applying my
changes
was able to pass all the basic stuff until the performance test 
stage at
which point my machine run out of RAM and swap space (some 10 
GB)... Not
sure if this is how the tests are supposed to be. After compiling 
with
-DskipTests I was able to create FreeBSD 11 - CentOS 7 two node 
cluster

and
everything seemed OK (the two nodes shared an IGFS instance backed 
by

replicated caches).
Please note that OpenJDK on different systems as well as Oracle JDK 
(via
Linux compatility layer) on FreeBSD seem to be more forgiving and 
does

not
SIGSEGV.
I've based my branch on 1.9.0-rc2 since tag 1.9.0 has already POM 
with

version 2.0.

Kamil
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0008020efff9, pid=2291, tid=0x00018a6b
#
# JRE version: OpenJDK Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13)
# Java VM: OpenJDK 64-Bit Server VM (25.121-b13 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x8efff9]  JVM_handle_bsd_signal+0x1267d9
#
# Core dump written. Default location: /usr/home/kmisuth/git/ignite_examples/java.core
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---  T H R E A D  ---

Current thread (0x0008e7177000):  JavaThread "grid-nio-worker-tcp-comm-0-#17%null%" [_thread_in_vm, id=100971, stack(0x7fffdc5c5000,0x7fffdc6c5000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x

Registers:
RAX=0x0008025bed60, RBX=0x0008d2c7ce18, RCX=0x0008e2055cc5, RDX=0x
RSP=0x7f

Re: Concurrent job execution and FifoQueueCollisionSpi.parallelJobsNumber=1

[Ryan Ripken]

I tried the below example with Ignite 1.9 and I continue to see multiple 
jobs being executed at the same time on nodes that are configured with 
FifoQueueCollisionSpi and parallelJobsNumber:1


Am I misunderstanding the purpose of the parallelJobsNumber setting?

thanks,
Ryan


On 4/11/2017 5:25 PM, Ryan Ripken wrote:

Ignite Team -

I created a stripped down version of what I'm trying to do:

https://www.dropbox.com/s/zhxidn14cgi4dqg/IgniteTest.7z?dl=0

There are a couple variables in node.bat that will need to be edited 
to point at your java_home and to the path where the 7z is unzipped to.


I first start a generic node by running node.bat from the command line.

Then I run the IgniteTest main method from my IDE.

The needed jar files are included in a jar directory.  They are what I 
believe are the typical 1.5 Ignite jars.


Running it I see this output:

Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger
warning
WARNING: Peer class loading is enabled (disable it in production
for performance and deployment consistency reasons)
Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger
warning
WARNING: This operating system has been tested less rigorously:
Windows 10 10.0 amd64. Our team will appreciate the feedback if
you experience any problems running ignite in this environment.
Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger
warning
WARNING: Checkpoints are disabled (to enable configure any
GridCheckpointSpi implementation)
Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger
warning
WARNING: Swap space is disabled. To enable use FileSwapSpaceSpi.
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in

[jar:file:/J:/ignite/modules/rest-http/target/libs/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in

[jar:file:/J:/ignite/modules/visor-plugins/target/libs/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for
an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
Apr 11, 2017 5:02:48 PM org.apache.ignite.logger.java.JavaLogger
warning
WARNING: TcpDiscoveryMulticastIpFinder has no pre-configured
addresses (it is recommended in production to specify at least one
address in TcpDiscoveryMulticastIpFinder.getAddresses()
configuration property)
Apr 11, 2017 5:03:43 PM ignitetest.TestJob execute
WARNING: ***Multiple jobs in progress. NOT GOOD

***Multiple jobs in progress. NOT GOOD 
Apr 11, 2017 5:03:43 PM ignitetest.TestJob execute
WARNING: ***Multiple jobs in progress. NOT GOOD

***Multiple jobs in progress. NOT GOOD 


In trying to make a self-contained version I seem to have messed up 
the logging configuration so not all the log messages are being displayed.
If its absolutely essential I can work on sorting out the logging 
issue and send another version.


I haven't tried this example in 1.9 yet.  Perhaps I will try that 
tomorrow.


I used essentially the same pattern in GridGain 3.6 and didn't have 
any problems.  Perhaps I messed something up when moving to Ignite.  
I'd really appreciate any suggestions.


Thanks,
Ryan


On 4/11/2017 5:55 AM, vkulichenko wrote:

Ryan,

No, there are no known issues like that and I don't think there will be a
way to investigate it without being able to reproduce. Please let us know if
you have a reproducer.

-Val



--
View this message in 
context:http://apache-ignite-users.70518.x6.nabble.com/Concurrent-job-execution-and-FifoQueueCollisionSpi-parallelJobsNumber-1-tp8697p11884.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

visor failed to connect to cluster

[waterg]

The following error happened when starting visor command line



visor> open -cpath=../config/idreg-server-prod.xml
[18:24:55]__  
[18:24:55]   /  _/ ___/ |/ /  _/_  __/ __/
[18:24:55]  _/ // (7 7// /  / / / _/
[18:24:55] /___/\___/_/|_/___/ /_/ /___/
[18:24:55]
[18:24:55] ver. 1.8.0#20161205-sha1:9ca40dbe
[18:24:55] 2016 Copyright(C) Apache Software Foundation
[18:24:55]
[18:24:55] Ignite documentation: http://ignite.apache.org
[18:24:55]
[18:24:55] Quiet mode.
[18:24:55]   ^-- Logging to file
'/home/postgres_admin_1955/ignite/work/log/ignite-0a3215a4.0.log'
[18:24:55]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false
or "-v" to ignite.{sh|bat}
[18:24:55]
[18:24:55] OS: Linux 2.6.32.54-0.29.TDC.1.R.8-default amd64
[18:24:55] VM information: Java(TM) SE Runtime Environment 1.8.0_121-b13
Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.121-b13
[18:24:55] Configured plugins:
[18:24:55]   ^-- None
[18:24:55]
[18:24:55,699][SEVERE][main][IgniteKernal] Failed to start manager:
GridManagerAdapter [enabled=true,
name=o.a.i.i.managers.communication.GridIoManager]
class org.apache.ignite.IgniteCheckedException: Failed to get SPI
attributes.
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:249)
at
org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:231)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1584)
at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:857)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1794)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1598)
at
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1041)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:568)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:515)
at org.apache.ignite.Ignition.start(Ignition.java:322)
at
org.apache.ignite.visor.commands.open.VisorOpenCommand.open(VisorOpenCommand.scala:251)
at
org.apache.ignite.visor.commands.open.VisorOpenCommand.open(VisorOpenCommand.scala:219)
at
org.apache.ignite.visor.commands.open.VisorOpenCommand$$anonfun$2.apply(VisorOpenCommand.scala:306)
at
org.apache.ignite.visor.commands.open.VisorOpenCommand$$anonfun$2.apply(VisorOpenCommand.scala:306)
at
org.apache.ignite.visor.commands.VisorConsole.mainLoop(VisorConsole.scala:218)
at
org.apache.ignite.visor.commands.VisorConsole$.delayedEndpoint$org$apache$ignite$visor$commands$VisorConsole$1(VisorConsole.scala:330)
at
org.apache.ignite.visor.commands.VisorConsole$delayedInit$body.apply(VisorConsole.scala:319)
at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
at
scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.collection.immutable.List.foreach(List.scala:381)
at
scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
at scala.App$class.main(App.scala:76)
at
org.apache.ignite.visor.commands.VisorConsole$.main(VisorConsole.scala:319)
at
org.apache.ignite.visor.commands.VisorConsole.main(VisorConsole.scala)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
initialize TCP server: 0.0.0.0/0.0.0.0
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:1481)
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:232)
... 25 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind to
any port within range [startPort=49100, portRange=100,
locHost=0.0.0.0/0.0.0.0]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:1762)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:1478)
... 26 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
initialize NIO selector.
at
org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:670)
at
org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:289)
at
org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:88)
at
org.apache.ignite.internal.util.nio.GridNioServer$Builder.build(GridNioServer.java:2439)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:1711)
... 27 more
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Unknown Source)
   

Re: visor failed to connect to cluster

[Denis Magda]

Visor can’t initialize TcpCommunicationSpi because there no more ports left to 
bind to on your machine.

Look at this part of the configuration and adjust the port range for the 
communication spi:

   
   
   
   
   

and find out why all the ports in a range of 49100 + 100 are taken. Probably 
your machine doesn’t release ports fast enough.

—
Denis


> On Apr 12, 2017, at 3:37 PM, waterg  wrote:
> 
> The following error happened when starting visor command line
> 
> 
> 
> visor> open -cpath=../config/idreg-server-prod.xml
> [18:24:55]__  
> [18:24:55]   /  _/ ___/ |/ /  _/_  __/ __/
> [18:24:55]  _/ // (7 7// /  / / / _/
> [18:24:55] /___/\___/_/|_/___/ /_/ /___/
> [18:24:55]
> [18:24:55] ver. 1.8.0#20161205-sha1:9ca40dbe
> [18:24:55] 2016 Copyright(C) Apache Software Foundation
> [18:24:55]
> [18:24:55] Ignite documentation: http://ignite.apache.org
> [18:24:55]
> [18:24:55] Quiet mode.
> [18:24:55]   ^-- Logging to file
> '/home/postgres_admin_1955/ignite/work/log/ignite-0a3215a4.0.log'
> [18:24:55]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false
> or "-v" to ignite.{sh|bat}
> [18:24:55]
> [18:24:55] OS: Linux 2.6.32.54-0.29.TDC.1.R.8-default amd64
> [18:24:55] VM information: Java(TM) SE Runtime Environment 1.8.0_121-b13
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.121-b13
> [18:24:55] Configured plugins:
> [18:24:55]   ^-- None
> [18:24:55]
> [18:24:55,699][SEVERE][main][IgniteKernal] Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=o.a.i.i.managers.communication.GridIoManager]
> class org.apache.ignite.IgniteCheckedException: Failed to get SPI
> attributes.
>at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:249)
>at
> org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:231)
>at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1584)
>at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:857)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1794)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1598)
>at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1041)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:568)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:515)
>at org.apache.ignite.Ignition.start(Ignition.java:322)
>at
> org.apache.ignite.visor.commands.open.VisorOpenCommand.open(VisorOpenCommand.scala:251)
>at
> org.apache.ignite.visor.commands.open.VisorOpenCommand.open(VisorOpenCommand.scala:219)
>at
> org.apache.ignite.visor.commands.open.VisorOpenCommand$$anonfun$2.apply(VisorOpenCommand.scala:306)
>at
> org.apache.ignite.visor.commands.open.VisorOpenCommand$$anonfun$2.apply(VisorOpenCommand.scala:306)
>at
> org.apache.ignite.visor.commands.VisorConsole.mainLoop(VisorConsole.scala:218)
>at
> org.apache.ignite.visor.commands.VisorConsole$.delayedEndpoint$org$apache$ignite$visor$commands$VisorConsole$1(VisorConsole.scala:330)
>at
> org.apache.ignite.visor.commands.VisorConsole$delayedInit$body.apply(VisorConsole.scala:319)
>at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
>at
> scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
>at scala.App$$anonfun$main$1.apply(App.scala:76)
>at scala.App$$anonfun$main$1.apply(App.scala:76)
>at scala.collection.immutable.List.foreach(List.scala:381)
>at
> scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
>at scala.App$class.main(App.scala:76)
>at
> org.apache.ignite.visor.commands.VisorConsole$.main(VisorConsole.scala:319)
>at
> org.apache.ignite.visor.commands.VisorConsole.main(VisorConsole.scala)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize TCP server: 0.0.0.0/0.0.0.0
>at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:1481)
>at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:232)
>... 25 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to bind to
> any port within range [startPort=49100, portRange=100,
> locHost=0.0.0.0/0.0.0.0]
>at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetNioServer(TcpCommunicationSpi.java:1762)
>at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:1478)
>... 26 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> initialize NIO selector.
>at
> org.apache.ignite.internal.util.nio.GridNioServer.cr

Webinar: Apache Ignite as a backbone for microservices-based architectures

[Denis Magda]

Dear community,

Welcome you to join the next Apache Ignite related webinar where you can learn 
more about Service Grid component and how to apply it for microservices-based 
solutions.

Description and registration: http://bit.ly/2nEmyv1  
Tweet: https://twitter.com/ApacheIgnite/status/852165280700796928

*Prachi*, would you add the event to the news feed?
https://ignite.apache.org/news.html 

—
Denis

Re: Slow on 1st time query "SQL Join"

[woo charles]

I found that this time can be reduced to a value below 100ms if I already
selected some data from join query related table.
For example,
if I run 2 query "select * from Quote where stock_id = xxx" & "Select *
from StockInfo where stock_id = xxx"  first and then run the join query,
the time for 1st join query will become similar to other(around 10 -20 ms).
Why will it happen?

Also, How to run queries from a server node? I had try
"ignite.compute().run()" but it doesn't work.


thanks& best regards,
Charles

2017-04-13 0:48 GMT+08:00 Sergi Vladykin :

> Alex,
>
> Why do we have such a huge difference between client nodes and server
> nodes? Looks like we should fix it if possible. Even 7 seconds looks too
> much for me.
>
> Sergi
>
> 2017-04-12 18:11 GMT+03:00 afedotov :
>
>> Hi Charles,
>>
>> You are running the query from a client node what implies additional
>> network round trips.
>> Try to run queries from a server node. In my environment it reduced the
>> time from about 7 seconds to 220ms for the first run.
>>
>> Kind regards,
>> Alex.
>>
>> On Wed, Apr 12, 2017 at 9:21 AM, woo charles [via Apache Ignite Users] 
>> <[hidden
>> email] > wrote:
>>
>>> *Sorry for wrong calculation *
>>> *-> (i.e. 3 Server node stored 236MB [2.2MB * 20 table +3.2MB * 60
>>> table] data)*
>>>
>>> *Best Regards,*
>>> *Charles*
>>>
>>> 2017-04-12 10:17 GMT+08:00 woo charles <[hidden email]
>>> >:
>>>
 *Source
 code: https://drive.google.com/open?id=0B_-zUEFkybdLQVF4U2dwTE11ajA
 *

 *Below is a screen cap on GridGain's web console & the log of my client
 program. *
 *(i.e. 3 Server node stored 756MB [2.2MB * 10 table +3.2MB * 30 table]
 data)*
 [image: 內置圖片 2]

 Apr 12, 2017 9:50:10 AM java.util.logging.LogManager$RootLogger log
 SEVERE: Failed to resolve default logging config file:
 config/java.util.logging.properties
 [09:50:10]__  
 [09:50:10]   /  _/ ___/ |/ /  _/_  __/ __/
 [09:50:10]  _/ // (7 7// /  / / / _/
 [09:50:10] /___/\___/_/|_/___/ /_/ /___/
 [09:50:10]
 [09:50:10] ver. 1.8.0#20161205-sha1:9ca40dbe
 [09:50:10] 2016 Copyright(C) Apache Software Foundation
 [09:50:10]
 [09:50:10] Ignite documentation: http://ignite.apache.org
 [09:50:10]
 [09:50:10] Quiet mode.
 [09:50:10]   ^-- To see **FULL** console log here add
 -DIGNITE_QUIET=false or "-v" to ignite.{sh|bat}
 [09:50:10]
 [09:50:10] OS: Linux 3.10.0-123.el7.x86_64 amd64
 [09:50:10] VM information: Java(TM) SE Runtime Environment
 1.8.0_121-b13 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM
 25.121-b13
 [09:50:10] Initial heap size is 128MB (should be no less than 512MB,
 use -Xms512m -Xmx512m).
 [09:50:10] Configured plugins:
 [09:50:10]   ^-- None
 [09:50:10]
 [09:50:10] Security status [authentication=off, tls/ssl=off]
 [09:50:11] To start Console Management & Monitoring run
 ignitevisorcmd.{sh|bat}
 [09:50:11]
 [09:50:11] Ignite node started OK (id=b663472c)
 [09:50:11] Topology snapshot [ver=19, servers=3, clients=1, CPUs=8,
 heap=3.1GB]
 PreLoadDataSize = 1
 NumOfTest = 2
 /--- Test 0 ---\
 Name = SQL_Select_2_Join_10
 ActionType = SQL_SELECT_2_JOIN
 Object class = com.performance.test.dao.Quote
 Thread Size = 80
 [09:50:20] New version is available at ignite.apache.org: 1.9.0
 MaxTime(First Time): 12710
 Thread [SQL_Select_2_Join_10] Average Time: 18.913ms - 0.018913s, Max
 Time: 183ms
 \-/
 /--- Test 1 ---\
 Name = QUERY_Quote_price_large_1000_Small_950
 ActionType = QUERY
 Object class = com.performance.test.dao.Quote
 Thread Size = 80
 MaxTime(First Time): 30
 Thread [QUERY_Quote_price_large_1000_Small_950] Average Time:
 118.752ms - 0.118752s, Max Time: 1094ms
 \-/

 *Also, I found that 1st **SQL J**oin query time reduced about 2 - 3s
 if my program's memory **increase** from 128mb to 1gb.*
 *Is it show that this problem is due to client side not server side?*

 *Best Regards,*
 *Charles*


 2017-04-11 23:29 GMT+08:00 afedotov <[hidden email]
 >:

> I'm not able to reproduce the timings you specified. Probably I do
> something wrong.
> Could you please provide a log for that case?
> Also, it would be of great help if you provide the reproducer sources.
>
> Kind regards,
> Alex.
>
> On Tue, Apr 11, 2017 at 4:57 AM, woo charles [via Apache Ignite Users]
> <[hidden email] <

RE: OOM when using Ignite as HDFS Cache

[张帅]

Ping…

 

From: 张帅 [mailto:satan.stud...@gmail.com] On Behalf Of zhangshuai.u...@gmail.com
Sent: Wednesday, April 12, 2017 5:29 PM
To: user@ignite.apache.org
Subject: OOM when using Ignite as HDFS Cache

 

Hi there,

 

I’d like to use Ignite as HDFS Cache in my cluster but failed with OOM error. 
Could you help to review my configuration to help avoid it?

 

I’m using DUAL_ASYNC mode. The Ignite nodes can find each other to establish 
the cluster. There are very few changes in default-config.xml but attached for 
your review. The JVM heap size is limited to 1GB. The Ignite suffers from OOM 
exception when I’m running Hadoop benchmark TestDFSIO writing 4*4GB files. I 
think writing 4GB file to HDFS is in streaming so Ignite should work with it. 
It’s acceptable to slow down the write performance to wait Ignite write cached 
data to HDFS but not acceptable to lead crash or data lost.

 

The ignite log is attached as ignite_log.zip, pick some key messages here:

 

17/04/12 00:49:17 INFO [grid-timeout-worker-#19%null%] internal.IgniteKernal: 

Metrics for local node (to disable set 'metricsLogFrequency' to 0)

^-- Node [id=9b5dcc35, name=null, uptime=00:26:00:254]

^-- H/N/C [hosts=173, nodes=173, CPUs=2276]

^-- CPU [cur=0.13%, avg=0.82%, GC=0%]

^-- Heap [used=555MB, free=43.3%, comm=979MB]

^-- Non heap [used=61MB, free=95.95%, comm=62MB]

^-- Public thread pool [active=0, idle=0, qSize=0]

^-- System thread pool [active=0, idle=6, qSize=0]

^-- Outbound messages queue [size=0]

17/04/12 00:50:06 INFO [disco-event-worker-#35%null%] 
discovery.GridDiscoveryManager: Added new node to topology: TcpDiscoveryNode 
[id=553b5c1a-da0b-43cb-b691-b842352b3105, addrs=[0:0:0:0:0:0:0:1, 
10.152.133.46, 10.55.68.223, 127.0.0.1, 192.168.1.1], 
sockAddrs=[BN1APS0A98852E/10.152.133.46:47500, 
bn1sch010095221.phx.gbl/10.55.68.223:47500, /0:0:0:0:0:0:0:1:47500, 
/192.168.1.1:47500, /127.0.0.1:47500], discPort=47500, order=176, intOrder=175, 
lastExchangeTime=1491983403106, loc=false, ver=2.0.0#20170405-sha1:2c830b0d, 
isClient=false]

[00:50:06] Topology snapshot [ver=176, servers=174, clients=0, CPUs=2288, 
heap=180.0GB]

...

Exception in thread "igfs-client-worker-2-#585%null%" 
java.lang.OutOfMemoryError: GC overhead limit exceeded

  at java.util.Arrays.copyOf(Arrays.java:3332)

  at 
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)

  at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)

  at java.lang.StringBuffer.append(StringBuffer.java:270)

  at java.io.StringWriter.write(StringWriter.java:112)

  at java.io.PrintWriter.write(PrintWriter.java:456)

  at java.io.PrintWriter.write(PrintWriter.java:473)

  at java.io.PrintWriter.print(PrintWriter.java:603)

  at java.io.PrintWriter.println(PrintWriter.java:756)

  at java.lang.Throwable$WrappedPrintWriter.println(Throwable.java:764)

  at java.lang.Throwable.printStackTrace(Throwable.java:658)

  at java.lang.Throwable.printStackTrace(Throwable.java:721)

  at 
org.apache.log4j.DefaultThrowableRenderer.render(DefaultThrowableRenderer.java:60)

  at 
org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:87)

  at org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:413)

  at org.apache.log4j.AsyncAppender.append(AsyncAppender.java:162)

  at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)

  at 
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)

  at org.apache.log4j.Category.callAppenders(Category.java:206)

  at org.apache.log4j.Category.forcedLog(Category.java:391)

  at org.apache.log4j.Category.error(Category.java:322)

  at org.apache.ignite.logger.log4j.Log4JLogger.error(Log4JLogger.java:495)

  at org.apache.ignite.internal.GridLoggerProxy.error(GridLoggerProxy.java:148)

  at org.apache.ignite.internal.util.IgniteUtils.error(IgniteUtils.java:4281)

  at org.apache.ignite.internal.util.IgniteUtils.error(IgniteUtils.java:4306)

  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:126)

  at java.lang.Thread.run(Thread.java:745)

Exception in thread "LeaseRenewer:had...@namenode-vip.yarn3-dev-bn2.bn2.ap.gbl" 
java.lang.OutOfMemoryError: GC overhead limit exceeded

Exception in thread 
"igfs-delete-worker%igfs%9b5dcc35-3a4c-4a90-ac9e-89fdd65302a7%" 
java.lang.OutOfMemoryError: GC overhead limit exceeded

Exception in thread "exchange-worker-#39%null%" java.lang.OutOfMemoryError: GC 
overhead limit exceeded

…

17/04/12 01:40:10 WARN [disco-event-worker-#35%null%] 
discovery.GridDiscoveryManager: Stopping local node according to configured 
segmentation policy.

 

Looking forward to your help.

 

 

Regards,

Shuai Zhang

Help with Web agent

[Harish Patibandla]

Hi Everyone,
   I am unable to run web agent on the server , web console is up and
running but was unable to get the agent running .I am getting below error
[05:38:44,159][INFO ][main][AgentLauncher] Starting Apache Ignite Web
Console Agent...
[05:38:44,309][WARN ][main][AgentLauncher] Failed to find agent property
file: default.properties

Agent configuration:
URI to Ignite node REST server: http://localhost:8080
URI to Ignite Console server  : http://localhost:3000
Path to agent property file   : default.properties
Path to JDBC drivers folder   :
/home/hpatiba/apache-ignite-1.9.0-src/modules/web-console/web-agent/target/ignite-web-agent-1.9.0/jdbc-drivers

Security token is required to establish connection to the web console.
It is available on the Profile page: https://localhost/profile
Enter security tokens separated by comma:
[05:38:49,733][INFO ][EventThread][AgentLauncher] Connecting to:
http://localhost:3000
[05:38:49,820][INFO ][EventThread][AgentLauncher] Connection established.
[05:38:49,855][ERROR][EventThread][AgentLauncher] Connection closed: Agent
is failed to authenticate. Please check agent's token(s).

Regards
Harish

Re: Slow on 1st time query "SQL Join"

[afedotov]

Hi,

Sergi, when join query is called from client
It leads to createMissingCaches being called which makes a remote requests
of a dynamic cache creation for each registered but not enabled cache and
since there is a cache for each entity there are many requests to server
nodes.

Charles,
If you select some data from the joined table it leads to all dynamic cache
creation requests being sent therefore allowing to skip these on the next
query runs.
To disable client mode in your example just pass false to
Ignition.setClientMode(true)

Kind regards,
Alex



13 апр. 2017 г. 5:22 AM пользователь "woo charles [via Apache Ignite
Users]"  написал:

I found that this time can be reduced to a value below 100ms if I already
selected some data from join query related table.
For example,
if I run 2 query "select * from Quote where stock_id = xxx" & "Select *
from StockInfo where stock_id = xxx"  first and then run the join query,
the time for 1st join query will become similar to other(around 10 -20 ms).
Why will it happen?

Also, How to run queries from a server node? I had try
"ignite.compute().run()" but it doesn't work.


thanks& best regards,
Charles

2017-04-13 0:48 GMT+08:00 Sergi Vladykin <[hidden email]
>:

> Alex,
>
> Why do we have such a huge difference between client nodes and server
> nodes? Looks like we should fix it if possible. Even 7 seconds looks too
> much for me.
>
> Sergi
>
> 2017-04-12 18:11 GMT+03:00 afedotov <[hidden email]
> >:
>
>> Hi Charles,
>>
>> You are running the query from a client node what implies additional
>> network round trips.
>> Try to run queries from a server node. In my environment it reduced the
>> time from about 7 seconds to 220ms for the first run.
>>
>> Kind regards,
>> Alex.
>>
>> On Wed, Apr 12, 2017 at 9:21 AM, woo charles [via Apache Ignite Users] 
>> <[hidden
>> email] > wrote:
>>
>>> *Sorry for wrong calculation *
>>> *-> (i.e. 3 Server node stored 236MB [2.2MB * 20 table +3.2MB * 60
>>> table] data)*
>>>
>>> *Best Regards,*
>>> *Charles*
>>>
>>> 2017-04-12 10:17 GMT+08:00 woo charles <[hidden email]
>>> >:
>>>
 *Source
 code: https://drive.google.com/open?id=0B_-zUEFkybdLQVF4U2dwTE11ajA
 *

 *Below is a screen cap on GridGain's web console & the log of my client
 program. *
 *(i.e. 3 Server node stored 756MB [2.2MB * 10 table +3.2MB * 30 table]
 data)*
 [image: 內置圖片 2]

 Apr 12, 2017 9:50:10 AM java.util.logging.LogManager$RootLogger log
 SEVERE: Failed to resolve default logging config file:
 config/java.util.logging.properties
 [09:50:10]__  
 [09:50:10]   /  _/ ___/ |/ /  _/_  __/ __/
 [09:50:10]  _/ // (7 7// /  / / / _/
 [09:50:10] /___/\___/_/|_/___/ /_/ /___/
 [09:50:10]
 [09:50:10] ver. 1.8.0#20161205-sha1:9ca40dbe
 [09:50:10] 2016 Copyright(C) Apache Software Foundation
 [09:50:10]
 [09:50:10] Ignite documentation: http://ignite.apache.org
 [09:50:10]
 [09:50:10] Quiet mode.
 [09:50:10]   ^-- To see **FULL** console log here add
 -DIGNITE_QUIET=false or "-v" to ignite.{sh|bat}
 [09:50:10]
 [09:50:10] OS: Linux 3.10.0-123.el7.x86_64 amd64
 [09:50:10] VM information: Java(TM) SE Runtime Environment
 1.8.0_121-b13 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM
 25.121-b13
 [09:50:10] Initial heap size is 128MB (should be no less than 512MB,
 use -Xms512m -Xmx512m).
 [09:50:10] Configured plugins:
 [09:50:10]   ^-- None
 [09:50:10]
 [09:50:10] Security status [authentication=off, tls/ssl=off]
 [09:50:11] To start Console Management & Monitoring run
 ignitevisorcmd.{sh|bat}
 [09:50:11]
 [09:50:11] Ignite node started OK (id=b663472c)
 [09:50:11] Topology snapshot [ver=19, servers=3, clients=1, CPUs=8,
 heap=3.1GB]
 PreLoadDataSize = 1
 NumOfTest = 2
 /--- Test 0 ---\
 Name = SQL_Select_2_Join_10
 ActionType = SQL_SELECT_2_JOIN
 Object class = com.performance.test.dao.Quote
 Thread Size = 80
 [09:50:20] New version is available at ignite.apache.org: 1.9.0
 MaxTime(First Time): 12710
 Thread [SQL_Select_2_Join_10] Average Time: 18.913ms - 0.018913s, Max
 Time: 183ms
 \-/
 /--- Test 1 ---\
 Name = QUERY_Quote_price_large_1000_Small_950
 ActionType = QUERY
 Object class = com.performance.test.dao.Quote
 Thread Size = 80
 MaxTime(First Time): 30
 Thread [QUERY_Quote_price_large_1000_Small_950] Average Time:
 118.752ms - 0.118752s, Max Time: 1094ms
 \--