Re: IP based discovery, dynamic nodes, and start() deadlock

Hullo Denis > Hope my answer made the things clearer for you, Denis Perfectly clear, thank you! So my attempt for economy with the addresses misfired.. Thanks for the additional notes as well, helps refine the code as I test more. Is it possible to add short mention about this to the cluster-c

Re: IP based discovery, dynamic nodes, and start() deadlock

Hello Erik, I got to the bottom of your issue, thanks for sharing the code. The reason why you have the deadlock is because the static IP finders don't have a local node's address in their list. If an IP finder has a local address in the list then the discovery will allow the node with this ad

Re: Distributed queue problem with peerClassLoading enabled

Hi Denis, I tried PRIVATE deployment mode but either I'm doing something wrong or distributed cache is not supported for this (and ISOLATED) mode. Is that so? When queue creation method is called, ie, the line: IgniteQueue queue = ignite.queue("myTaskQueue", 0, new CollectionConfiguration()

Re: Help with tuning for larger clusters

Joe, Thanks for the clarifications. Now we're on the same page. It's great that the cluster is initially assembled without any issue and you see that all 64 joined the topology. In regards to 'rebalancing timeout' warnings I have the following thoughts. First, I've opened a bug that describes y

Re: Help with tuning for larger clusters

Hi, Joe, >I double checked the config I posted, the one (I think) I'm currently running and the one I send with the logs and they all > seem to be the same Sorry , this is my mistake -- I picked up wrong config for analysis. Please disregard my previous suggestions. >>Each ignite node (i.e. ea

Re: IP based discovery, dynamic nodes, and start() deadlock

Hello Denis On 02/11/15 10:00, "Denis Magda" wrote: >- make sure that each node can reach each other over network. The ports that >the nodes are bound to might be closed by your firewall. In any case there >is always a way to set ports list to use for an IP finder: >https://apacheignite.rea

Re: The result of cross-cache SQL joins is incomplete.

Alex, thanks for providing the correct example! Shame on me, didn't pay much attention while was providing my version ;) -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/The-result-of-cross-cache-SQL-joins-is-incomplete-tp1723p1811.html Sent from the Apache Ignite

Re: The result of cross-cache SQL joins is incomplete.

iceguo and Deniss I think Denis provided slightly incorrect code snippet to work with async. One should use varable to work with async like this: IgniteCache asyncCache = cache.withAsync(); asyncCache.put(...); asyncCache.future().get(); Denis, take a look. On Mon, Nov 2, 2015 at 4:40 PM,

Re: Distributed queue problem with peerClassLoading enabled

Hi Mateusz, Seems that either PRIVATE or ISOLATED deployment mode perfectly fits for your task. Please try to switch to one of them. CONTINUOUS mode reloads previously deployed classes only when 'userInfo' changes. Refer to the documentation of this node. In short to fix this you should increase

Re: The result of cross-cache SQL joins is incomplete.

> There is another question, when I put table data into REPLICATED cache, This operation is synchronous or asynchronous? cache.put is synchronous. However, you can make behave him asynchronously this way: cache.withAsync().put(...) > If it is asynchronous, how can I know when this operation has

Re: The result of cross-cache SQL joins is incomplete.

> I compared the SQL querys between yours and mine, and I found something different. > For your SQL query "emp.depid = dep.id", dep.id is primary key of table > Department. > But for my SQL query "A.mid = B.mid", B.mid is NOT primary key of table B. Actually, I've provided you with the example

Re: Failed to find atomic long with given name

Hi, IgniteAtomicLong and other atomics or data structures are implemented using caches in Ignite. By default IgniteAtomicLong will be backed by a partitioned cache that doesn't have a backup. This should lead to the exception you see. So when you kill the first node that held the atomic long ther

Re: IP based discovery, dynamic nodes, and start() deadlock

Hi Erik, Discovery logic works the same for any kind of IP finders. IP finder is just a way to pass a list of TCP/IP addresses to use during the time a node joins a cluster. Muticast IP finder forms such a list automatically for you while in case of static IP finder you do this manually. If you

Re: Distributed queue problem with peerClassLoading enabled

Hi Artem, Thanks for your investigation! I will then eagerly wait for the resolution of this bug. Unfortunately the workarounds you suggested probably are not applicable to my main use case for Ignite, unless I misunderstood them. Here's my main use case (only for the development environment): I