RE: Cache Groups and PARTITIONED/REPLICATED

2017-08-01 Thread Juan Barani
default configuration, automatically the default config is partitioned, and the error appears. Then, it seems to be either I need to configure the CollectionConfiguration exactly the same as the AtomicConfiguration, or place the Collection in a different group altogether... Thanks, Juan From: Juan

Cache Groups and PARTITIONED/REPLICATED

2017-08-01 Thread Juan Barani
Hi! While trying the execute the very first snippet that creates a set in the documentation: https://apacheignite.readme.io/docs/queue-and-set#overview Ignite ignite = Ignition.ignite(); IgniteSet set = ignite.set( "setName", // Set name. null // Collection configuration. )

RE: TcpDiscoverySpi worker thread failed with assertion error

2017-07-10 Thread Juan Barani
on System.currentTimeMillis(), is not monotonic, so there is no guarantee that returned values will always be greater than all previous calls. please see the following ticket: https://issues.apache.org/jira/browse/IGNITE-5562 Thanks, Slava. 2017-07-10 12:34 GMT+03:00 Juan Barani

RE: TcpDiscoverySpi worker thread failed with assertion error

2017-07-10 Thread Juan Barani
Hi, One more thing, if we disable the assertions, would it be any direct impact besides the metrics? Thanks Juan From: Juan Barani [mailto:juan.bar...@unitedplanet.com] Sent: Monday, July 10, 2017 11:44 AM To: user@ignite.apache.org Subject: RE: TcpDiscoverySpi worker thread failed with

RE: TcpDiscoverySpi worker thread failed with assertion error

2017-07-10 Thread Juan Barani
Just to add something else to the scenario, can it happen that due to NTP adjustments in the servers then System.currentTimeMillis() returns a smaller value than before? May it be that using System.nanoTime() this problem does not appear? Thanks! Juan From: Juan Barani [mailto:juan.bar

TcpDiscoverySpi worker thread failed with assertion error

2017-07-10 Thread Juan Barani
Hi everyone, We are testing a new application running Ignite 2.0 with 3 nodes running on Azure platform. We left the cluster running a couple of days without load, and randomly one of the Nodes stopped with the following stacktrace: INFO 2017-07-07T23:07:28,475 - org.apache.ignite.internal.Ig

RE: How to correctly shut down Ignite Application

2017-05-10 Thread Juan Barani
: user@ignite.apache.org Subject: Re: How to correctly shut down Ignite Application Hi Juan, Looks like there is a bug, sometimes ignite choose ipv6 protocol to communicate with other nodes that causes strange communication errors. On Wed, May 10, 2017 at 1:01 PM, Juan Barani mailto:juan.bar

RE: How to correctly shut down Ignite Application

2017-05-10 Thread Juan Barani
Hi, Not necessarily is the case that the client cannot connect to the server. I experienced yesterday with ignite 2.0, that when a client is forced with: l_discoverySpi.setForceServerMode(true); it comes as isClient=false in the exception message, even if setClientMode=true. Since updating to