Re: Ignite client connection from windows machine - UNRELIANCE

[mahesh76private]

serverlogs.serverlogs

  


Attached. 
There is not much info there, but maybe you can see something here...

Also, by the way, if I reboot the ignite cluster (which I don't want to),
ignite clients from windows and Linux will start connecting without a
problem. 
Right now, we have only clients from linux connecting fine and clients on
windows fail. 

regards
Mahesh



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Trying to get MariaDB data loaded into Ignite through a web console created config

[Steven Castano]

Thanks… that got me much farther… I was able to generate a config, get the 
docker image built with the Dockerfile and deploy a running container which now 
connects back to the web console. It shows all of my caches created for each of 
the tables I wanted to import, but I can’t seem to figure out how to load the 
data. the LoadCaches.java file doesn’t want to run inside the docker container. 
So I appear to have all my caches, but they’re all empty. The screencast only 
shows how to run it in an IDE, not on the command line once it’s built.

*SMC

Steven Castano | stevenmcast...@yahoo.com 
Secure PGP Key: www.stevenmcastano.com/pgpkey 




> On Jun 14, 2019, at 6:38 PM, Denis Magda  wrote:
> 
> Hi Steven,
> 
> Please check out a series of screencast "Ignite Web Console - Automatic RDBMS 
> Integration" that shows how to use to complete this process:
> https://ignite.apache.org/screencasts.html 
> 
> 
> It might be the case that with docker you need to pass the settings 
> differently. Please, check docker configuration settings:
> https://apacheignite.readme.io/docs/docker-deployment 
> 
> 
> -
> Denis
> 
> 
> On Thu, Jun 13, 2019 at 1:44 PM Steven Castano  > wrote:
> So I was able to get a 2 node cluster started, v2.7.5 and got the web-console 
> running through a docker container. I’m even able to load the MariaDB JDBC 
> driver and connect to my database.
> 
> The problem I’m having is that when I’m done configuring things and I save 
> and download the .zip file for the cluster configuration… I don’t know where 
> to put it. No matter where I store it on my server I keep getting a “file not 
> found” type error when looking for the properties file.
> 
> Even when creating a cluster with all the defaults not even connected to 
> another database with no persistence, I still can’t get the downloaded 
> project files working. Is there something I’m missing, or maybe a good 
> tutorial online I can follow??
> 
> *SMC
> 
> Steven Castano | stevenmcast...@yahoo.com 
> Secure PGP Key: www.stevenmcastano.com/pgpkey 
> 
> 
> 
> 

Re: Adding SQL Support to an Existing Cache

[Denis Magda]

Please use DDL if you'd like to configure SQL dynamically:
https://apacheignite-sql.readme.io/docs/ddl

This page shows how to use both SQL and key-value APIs:
https://apacheignite-sql.readme.io/docs/sql-and-key-value-usage

-
Denis


On Wed, Jun 5, 2019 at 9:20 AM anicn  wrote:

> I'm curious to hear more about what considerations there are. For example:
> - Is any of the cache data duplicated in the table?
> - Are there indexes created for the primary key on this table?
> - Does the index incur a write performance penalty?
>
> Thanks!
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Trying to get MariaDB data loaded into Ignite through a web console created config

[Denis Magda]

Hi Steven,

Please check out a series of screencast "Ignite Web Console - Automatic
RDBMS Integration" that shows how to use to complete this process:
https://ignite.apache.org/screencasts.html

It might be the case that with docker you need to pass the settings
differently. Please, check docker configuration settings:
https://apacheignite.readme.io/docs/docker-deployment

-
Denis


On Thu, Jun 13, 2019 at 1:44 PM Steven Castano 
wrote:

> So I was able to get a 2 node cluster started, v2.7.5 and got the
> web-console running through a docker container. I’m even able to load the
> MariaDB JDBC driver and connect to my database.
>
> The problem I’m having is that when I’m done configuring things and I save
> and download the .zip file for the cluster configuration… I don’t know
> where to put it. No matter where I store it on my server I keep getting a
> “file not found” type error when looking for the properties file.
>
> Even when creating a cluster with all the defaults not even connected to
> another database with no persistence, I still can’t get the downloaded
> project files working. Is there something I’m missing, or maybe a good
> tutorial online I can follow??
>
> *SMC
>
> Steven Castano | stevenmcast...@yahoo.com
> Secure PGP Key: www.stevenmcastano.com/pgpkey
>
>
>
>

Re: 2.7.5 DEB package not in repository?

[Denis Magda]

Hi John,

The release procedures are not finished yet. We're still preparing some
images including DEB.

Dmitry, please update us here once we're ready.

-
Denis


On Fri, Jun 14, 2019 at 1:00 PM John Smith  wrote:

> I looked here: http://apache.org/dist/ignite/deb/ and it's not in Bintray
> either.
>
> Thanks
>

Re: How much data is actually in RAM?

[Michael Cherkasov]

Hi John,

if you have native persistence enabled that ignite will evict data to a
disk if there's no space in RAM.
BUT you have to specify maxSize for RAM! so Ignite really doesn't have a
limit for space, it's just limited by your disk and you will get IgniteOOM
at some point.

So your current configuration should fail because Ignite will try to
allocate 72 GB in memory on start.

>1- If I get this right... Each node is using about 1GB on-heap JVM memory
each for the ignite process to run. Correct? Should this be set a bit
higher or that's ok?
Ignite store data in off heap, but heap will be used for everything else,
like message processing, marshaling and unmarshaling data and etc.
If you use SQL, ignite will load data from off heap to on heap to send
record as a response to client. Usually SQL the main consumer of heap, so
you need to tune you heap size based on your needs.

>2- There is total 216GB off-heap so about 72GB off-heap per node. So how
much of that is stored in actual RAM in the remainder
>of what is left from 8GB of the physical host? Is that the 20% value
indicated in the docs? Or should maxSize be set to 6L and not 72L giving
2GB free to the OS and ignite process?
As I said, this option defines not max size for storage, but the max size
for storage in RAM! Ignite always will use RAM memory that you allocate to
it for data storage, only if it's not enough memory for data storage it
will evict data to a disk.

Thanks,
Mike.


пт, 14 июн. 2019 г. в 14:02, John Smith :

> Hi, so I have 3 machines with 8GB RAM and 96GB disk each.
>
> I have configured the persistence as
>
>  class="org.apache.ignite.configuration.DataRegionConfiguration">
>   
>
>   
>   
> 
>   
>
> Looking at the logs:
> Topology snapshot [ver=3, locNode=xx, servers=3, clients=0,
> state=INACTIVE, CPUs=12, offheap=216.0GB, heap=3.0GB]
>
> 1- If I get this right... Each node is using about 1GB on-heap JVM memory
> each for the ignite process to run. Correct? Should this be set a bit
> higher or that's ok?
> 2- There is total 216GB off-heap so about 72GB off-heap per node. So how
> much of that is stored in actual RAM in the remainder of what is left from
> 8GB of the physical host? Is that the 20% value indicated in the docs? Or
> should maxSize be set to 6L and not 72L giving 2GB free to the OS and
> ignite process?
>
>
>
>
>

Re: How much data is actually in RAM?

[Shane Duan]

It guess really depends how you use the cluster. For my use case, I have to
bump up heap to 8G to support concurrent queries (JDBC); otherwise, Ignite
could crash since Ignite need process results in heap.

On Fri, Jun 14, 2019 at 2:02 PM John Smith  wrote:

> Hi, so I have 3 machines with 8GB RAM and 96GB disk each.
>
> I have configured the persistence as
>
>  class="org.apache.ignite.configuration.DataRegionConfiguration">
>   
>
>   
>   
> 
>   
>
> Looking at the logs:
> Topology snapshot [ver=3, locNode=xx, servers=3, clients=0,
> state=INACTIVE, CPUs=12, offheap=216.0GB, heap=3.0GB]
>
> 1- If I get this right... Each node is using about 1GB on-heap JVM memory
> each for the ignite process to run. Correct? Should this be set a bit
> higher or that's ok?
> 2- There is total 216GB off-heap so about 72GB off-heap per node. So how
> much of that is stored in actual RAM in the remainder of what is left from
> 8GB of the physical host? Is that the 20% value indicated in the docs? Or
> should maxSize be set to 6L and not 72L giving 2GB free to the OS and
> ignite process?
>
>
>
>
>

How much data is actually in RAM?

[John Smith]

Hi, so I have 3 machines with 8GB RAM and 96GB disk each.

I have configured the persistence as


  

  
  

  

Looking at the logs:
Topology snapshot [ver=3, locNode=xx, servers=3, clients=0,
state=INACTIVE, CPUs=12, offheap=216.0GB, heap=3.0GB]

1- If I get this right... Each node is using about 1GB on-heap JVM memory
each for the ignite process to run. Correct? Should this be set a bit
higher or that's ok?
2- There is total 216GB off-heap so about 72GB off-heap per node. So how
much of that is stored in actual RAM in the remainder of what is left from
8GB of the physical host? Is that the 20% value indicated in the docs? Or
should maxSize be set to 6L and not 72L giving 2GB free to the OS and
ignite process?

2.7.5 DEB package not in repository?

[John Smith]

I looked here: http://apache.org/dist/ignite/deb/ and it's not in Bintray
either.

Thanks

Re: Ignite Visor Cache command hangs indefinitely.

[John Smith]

Hi, It's 100% that.

I'm just stating that my applications run inside a container network and
the Ignite is installed on it's own VMS. The networks see each other and
this works. Also Visor can connect. No problems.
It's only when for example we have a dev machine connect from WIFI and
while a full mesh cluster is created VISOR cannot reach that node.
Or what if a badly configured client connects and causes this issue.

All I'm saying if Ignite Visor is THE TOOL to debug and check cluster state
etc... It's a bit odd that it hangs for ever if it cannot reach a specific
client. I think that Visor/the protocol should know that it's a CLIENT ONLY
and not try to get stats from it. What do you think?



On Thu, 13 Jun 2019 at 09:52, Ilya Kasnacheev 
wrote:

> Hello!
>
> Please enable verbose logging and share logs from both visor, client and
> server nodes, so that we could check that.
>
> There should be messages related to connection attempts.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 13 июн. 2019 г. в 00:06, John Smith :
>
>> The clients are in the same low latency network, but they are running
>> inside container network. While ignite is running on it's own cluster. So
>> from that stand point they all see each other...
>>
>> On Wed, 12 Jun 2019 at 17:04, John Smith  wrote:
>>
>>> Ok thanks
>>>
>>> On Mon, 10 Jun 2019 at 04:48, Ilya Kasnacheev 
>>> wrote:
>>>
 Hello!

 As a rule, a faulty thick client can destabilize a cluster. Ignite's
 architecture assumes that all clients are collocated, i.e. that the network
 between any two nodes (including clients) is reliable, fast and 
 low-latency.

 It is not recommended to connect thick clients from different networks.
 Use thin clients where possible.

 You can file a ticket against Apache Ignite JIRA regarding visor
 behavior if you like.

 Regards,
 --
 Ilya Kasnacheev


 пт, 7 июн. 2019 г. в 23:15, John Smith :

> Correct. Should it not at least timeout and at least show what it has
> available? Basically we have a central cluster and various clients connect
> to it from different networks. As an example: Docker containers.
>
> We make sure that the clients are client nodes only and we avoid
> creating any caches on clients.
>
> On Fri, 7 Jun 2019 at 10:19, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com> wrote:
>
>> Hello!
>>
>> I think that Visor will talk to all nodes when trying to run caches
>> command, and if it can't reach client nodes the operation will never 
>> finish.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> ср, 5 июн. 2019 г. в 22:34, John Smith :
>>
>>> Hi, any thoughts on this?
>>>
>>> On Fri, 31 May 2019 at 10:21, John Smith 
>>> wrote:
>>>
 I think it should at least time out and show stats of the nodes it
 could reach? I don't see why it's dependant on client nodes.

 On Thu, 30 May 2019 at 11:58, John Smith 
 wrote:

> Sorry pressed enter to quickly
>
> So basically I'm 100% sure if visor cache command cannot reach the
> client node then it just stays there not doing anything.
>
> On Thu, 30 May 2019 at 11:57, John Smith 
> wrote:
>
>> Hi, running 2.7.0
>>
>> - I have a 4 node cluster and it seems to be running ok.
>> - I have clients connecting and doing what they need to do.
>> - The clients are set as client = true.
>> - The clients are also connecting from various parts of the
>> network.
>>
>> The problem with ignite visor cache command is if visor cannot
>> reach a specific client node it just seems to hang indefinitely.
>>
>> Choose node number ('c' to cancel) [0]: c
>> visor> cache
>>
>> It just stays like that no errors printed nothing...
>>
>

Re: Ignite Rest API is not working

[Kishan]

Checked the logs. The server was started on 8081 port as 8080 port was busy.
It's working now.

Thank you very much.

Kishan





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite Rest API is not working

[Evgenii Zhuravlev]

There is a chance that port 8080 was busy and it was bound to the next
port. I'd recommend checking Ignite logs to make sure that rest was started
and check the port.

Evgenii

пт, 14 июн. 2019 г. в 19:47, Kishan :

> I want to use REST API provided by ignite.
>
> I have downloaded the ignite binary version 2.6. I have copied
> 'ignite-rest-http' module from IGNITE_HOME/libs/optional/ to
> IGNITE_HOME/libs folder.
>
> Then i run the command bin/ignite.bat, I am able to bring up the service
> with this command, but when I try to hit
> 'http://localhost:8080/ignite?cmd=version' from the browser, it is giving
> me
> HTTP 404 error.
>
> I tried the same thing with different machine but it is giving me same
> error.
>
> Please let me know if I am missing something.
>
> Thanks in advance.
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Connect external application to Ignite cluster via REST

[Kishan]

We have ignite cluster up with four nodes. This cluster is hydrated with data
into its cache. We want an external application to connect with cluster and
get all the data objects of particular cache from the cluster via REST.

I am thinking of following approaches:
1) Using ignite's service grid and deploy service into the grid, But I am
not able to figure out a way to consume that service via REST call.
2) Someone suggested to bring up the service using ignite's compute task
which can be invoked via REST call. The problem with approach is that the
compute task won't return set of objects to REST client. 
3) Bringing up the Jetty web server using service deployed on service
grid(starting server in init method of service), and then make REST client
to connect with that web server.
4) Using thin clients provided by ignite(Problem with this is that client
will connect to only one cluster node, what if that node goes down)
5) Using REST APIs provided by ignite(As we want all the data objects of one
cache, we are thinking of using REST APIs which executes SQL query and
return output objects from cluster's cache)

Which approach will work and which is the best one?

Thanks in advance.




--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Ignite Rest API is not working

[Kishan]

I want to use REST API provided by ignite.

I have downloaded the ignite binary version 2.6. I have copied
'ignite-rest-http' module from IGNITE_HOME/libs/optional/ to
IGNITE_HOME/libs folder. 

Then i run the command bin/ignite.bat, I am able to bring up the service
with this command, but when I try to hit
'http://localhost:8080/ignite?cmd=version' from the browser, it is giving me
HTTP 404 error.

I tried the same thing with different machine but it is giving me same
error.

Please let me know if I am missing something.

Thanks in advance.




--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: [External]Re: Is there any way to force recover the cluster - copying running cluster datastore

[Ilya Kasnacheev]

Hello!

Yes, I believe that's the correct dir. It contains checkpoint markers which
you should remove.

Regards,
-- 
Ilya Kasnacheev


пт, 14 июн. 2019 г. в 17:30, Kamlesh Joshi :

> Hi Ilya,
>
>
>
> WAL markers you mean *cp* folder inside datastore ? or any other ?
>
>
>
> *Thanks and Regards,*
>
> *Kamlesh Joshi*
>
>
>
> *From:* Ilya Kasnacheev 
> *Sent:* Friday, June 14, 2019 6:59 PM
> *To:* user@ignite.apache.org
> *Subject:* Re: [External]Re: Is there any way to force recover the
> cluster - copying running cluster datastore
>
>
>
> The e-mail below is from an external source. Please do not open
> attachments or click links from an unknown or suspicious origin.
>
> Hello!
>
>
>
> If your node did not crash during a checkpoint, complerely removing WAL
> files and WAL markers should set you back to some stable state.
>
>
>
> If it did crash during a checkpoint, you can't start with corrupted WAL.
>
>
>
> Regards,
>
> --
>
> Ilya Kasnacheev
>
>
>
>
>
> ср, 12 июн. 2019 г. в 17:37, Kamlesh Joshi :
>
> Hi Denis,
>
>
>
> Only WAL disk is corrupted but datastore is intact by any way can we
> restore the cluster ? some data loss is fine. Any suggestion on this?
>
>
>
> *Thanks and Regards,*
>
> *Kamlesh Joshi*
>
>
>
> *From:* Kamlesh Joshi
> *Sent:* Thursday, June 6, 2019 7:52 PM
> *To:* user@ignite.apache.org
> *Subject:* RE: [External]Re: Is there any way to force recover the
> cluster - copying running cluster datastore
>
>
>
> Thanks for the update Denis.
>
>
>
> If one of the WAL disk gets failed, is there any way to start or recover
> the cluster forcefully ?
>
>
>
> *Thanks and Regards,*
>
> *Kamlesh Joshi*
>
>
>
> *From:* Denis Magda 
> *Sent:* Thursday, June 6, 2019 4:44 PM
> *To:* user@ignite.apache.org
> *Subject:* [External]Re: Is there any way to force recover the cluster -
> copying running cluster datastore
>
>
>
> The e-mail below is from an external source. Please do not open
> attachments or click links from an unknown or suspicious origin.
>
> I would discourage you from doing this if data consistency is prominent
> for you. What you see on the disk of one cluster node might be inconsistent
> with the whole cluster state and the actual/last updates in memory.
> Snapshots and backups can solve your task. Google for a solution provided
> by GridGain.
>
>
> -
>
> Denis
>
>
>
>
>
> On Wed, Jun 5, 2019 at 8:27 AM Kamlesh Joshi 
> wrote:
>
> Hi Team,
>
>
>
> We are trying to start another Ignite cluster by taking a
> copy of the running cluster’s datastore (source cluster’s datastore is
> getting modified in parallel). So, when we try to start the server node
> with copied datastore, it gives error as below. Also, giving cluster
> configuration for reference:
>
>
>
> *pageSize=#{4 * 1024}*
>
> *walMode=LOG_ONLY*
>
> *walFlushFrequency=6*
>
> *rebalanceThreadPoolSize=8*
>
> *rebalanceThrottle=100*
>
> *rebalanceBatchSize=#{32 * 1024 * 1024}*
>
> *storagePath=/datastore/datastore*
>
> *walPath=/datastore1/wal*
>
> *walArchivePath=/datastore1/archive*
>
> *metadataWorkDir=/datastore/metadataWorkDir*
>
>
>
>
>
> [2019-06-05T12:21:52,943][INFO ][main][GridCacheDatabaseSharedManager]
> Read checkpoint status [startMarker=null, endMarker=null]
>
> [2019-06-05T12:21:52,967][INFO ][main][PageMemoryImpl] Started page memory
> [memoryAllocated=128.0 MiB, pages=31744, tableSize=2.5 MiB,
> checkpointBuffer=100.0 MiB]
>
> [2019-06-05T12:21:52,968][INFO ][main][GridCacheDatabaseSharedManager]
> Checking memory state [lastValidPos=FileWALPointer [idx=0, fileOff=0,
> len=0], lastMarked=FileWALPointer [idx=0, fileOff=0, len=0],
> lastCheckpointId=----]
>
> [2019-06-05T12:21:52,973][ERROR][main][IgniteKernal%EDIFCustomer_DR]
> Exception during start processors, node will be stopped and close
> connections
>
> org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter []
>
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1742)
> ~[ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:980)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1069)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:955)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:854)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:724)
> 

Re: Ignite client - slow startup

[Ilya Kasnacheev]

Hello!

It seems that you have hit
https://issues.apache.org/jira/browse/IGNITE-11767

It's not on any release yet, so decreasing history size looks like a decent
solution for now. You can do that with system property

IGNITE_EXCHANGE_HISTORY_SIZE


Regards,
-- 
Ilya Kasnacheev


пт, 14 июн. 2019 г. в 16:49, Dieter Guthardt :

> Hi,
>
> we're currently running a couple of servers with various Ignite
> scenarios - version 2.6 and 2.7.
> With and without persistence and some only get used to perform server
> based computations without any cache.
> It's quite satisfying except the startup time of the client applications
> is pretty slow especially running them from 'remote'.
>
> I realized depending on the cluster configuration the topology send
> around when connecting can get huge.
> Even the clusters without caches get really big and it's time consuming
> to connect.
>
> That's all related to the snapshot version, so higher the number so
> bigger the amount of data transferred and slower the connection.
> The client instance of Ignite gets bigger and bigger depending on the
> cluster, cache and snapshot history.
>
> Since I haven't found a satisfying answer yet I started digging into
> your code and found the following:
>
> In the class TcpDiscoverySpi you set the default history size of the
> discoCache to be 1000!
> After reducing the number to 10 I obtained a decent startup time.
>
> Debugging the ignite client instance now shows a constant size after
> reaching a snapshot version > 10.
>
> I was wondering why the history was set to 1000? How does a small number
> affect the cluster?
>
> Br,
>
> Will
>
>

Re: Sql query cannot handle special character like ½

[Ilya Kasnacheev]

Hello!

I expect that your System.out is not unicode. Can you try writing to file,
sending this file over? Can you do System.out.println(column.charAt(pos))?

Regards,
-- 
Ilya Kasnacheev


чт, 13 июн. 2019 г. в 22:01, wengyao04 :

> Hi I try it, but it does not work
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Ignite client connection from windows machine - UNRELIANCE

[Ilya Kasnacheev]

Hello!

Can you please quote the complete stack trace?

Regards,
-- 
Ilya Kasnacheev


пт, 14 июн. 2019 г. в 12:48, mahesh76private :

> Hi,
>
> In our office, we have client nodes started on windows and Linux machines.
> we see that client nodes on linux always happen to connect to Ignite
> cluster
> properly
> However, once in a while *ALL* windows machines fail to connect
>
> Below is the log on of the windows machines. Any clue ?
>
>
> [15:05:34,795][INFO][main][IgniteKernal] Config URL: n/a
> [15:05:34,813][INFO][main][IgniteKernal] IgniteConfiguration
> [igniteInstanceName=null, pubPoolSize=8, svcPoolSize=7, callbackPoolSize=8,
> stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4, igfsPoolSize=8,
> dataStreamerPoolSize=8, utilityCachePoolSize=8,
> utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8,
>
> igniteHome=C:\Users\mahes\Desktop\apache\apache-ignite-2.7.0-bin\apache-ignite-2.7.0-bin,
>
> igniteWorkDir=C:\Users\mahes\Desktop\apache\apache-ignite-2.7.0-bin\apache-ignite-2.7.0-bin\work,
> mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@769e7ee8,
> nodeId=7d9f28d2-69db-49b5-9c20-219523108114, marsh=BinaryMarshaller [],
> marshLocJobs=false, daemon=false, p2pEnabled=true, netTimeout=1,
> sndRetryDelay=1000, sndRetryCnt=3, metricsHistSize=1,
> metricsUpdateFreq=2000, metricsExpTime=9223372036854775807,
> discoSpi=TcpDiscoverySpi [addrRslvr=null, sockTimeout=5, ackTimeout=0,
> marsh=null, reconCnt=10, reconDelay=2000, maxAckTimeout=60,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null],
> segPlc=STOP, segResolveAttempts=2, waitForSegOnStart=true,
> allResolversPassReq=true, segChkFreq=1, commSpi=TcpCommunicationSpi
> [connectGate=null,
>
> connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@1fa121e2
> ,
> enableForcibleNodeKill=false, enableTroubleshootingLog=false,
> locAddr=192.168.1.156, locHost=null, locPort=47100, locPortRange=100,
> shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=60,
> connTimeout=5000, maxConnTimeout=60, reconCnt=10, sockSndBuf=32768,
> sockRcvBuf=32768, msgQueueLimit=0, slowClientQueueLimit=0, nioSrvr=null,
> shmemSrv=null, usePairedConnections=false, connectionsPerNode=1,
> tcpNoDelay=true, filterReachableAddresses=false, ackSndThreshold=32,
> unackedMsgsBufSize=0, sockWriteTimeout=4, boundTcpPort=-1,
> boundTcpShmemPort=-1, selectorsCnt=1, selectorSpins=0, addrRslvr=null,
> ctxInitLatch=java.util.concurrent.CountDownLatch@7eac9008[Count = 1],
> stopping=false],
> evtSpi=org.apache.ignite.spi.eventstorage.NoopEventStorageSpi@4116aac9,
> colSpi=NoopCollisionSpi [], deploySpi=LocalDeploymentSpi [],
> indexingSpi=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@15de0b3c,
> addrRslvr=null,
>
> encryptionSpi=org.apache.ignite.spi.encryption.noop.NoopEncryptionSpi@489115ef
> ,
> clientMode=true, rebalanceThreadPoolSize=1, txCfg=TransactionConfiguration
> [txSerEnabled=false, dfltIsolation=REPEATABLE_READ,
> dfltConcurrency=PESSIMISTIC, dfltTxTimeout=0,
> txTimeoutOnPartitionMapExchange=0, pessimisticTxLogSize=0,
> pessimisticTxLogLinger=1, tmLookupClsName=null, txManagerFactory=null,
> useJtaSync=false], cacheSanityCheckEnabled=true, discoStartupDelay=6,
> deployMode=SHARED, p2pMissedCacheSize=100, locHost=null,
> timeSrvPortBase=31100, timeSrvPortRange=100, failureDetectionTimeout=1,
> sysWorkerBlockedTimeout=360, clientFailureDetectionTimeout=3,
> metricsLogFreq=6, hadoopCfg=null, connectorCfg=ConnectorConfiguration
> [jettyPath=null, host=null, port=11211, noDelay=true, directBuf=false,
> sndBufSize=32768, rcvBufSize=32768, idleQryCurTimeout=60,
> idleQryCurCheckFreq=6, sndQueueLimit=0, selectorCnt=4,
> idleTimeout=7000,
> sslEnabled=false, sslClientAuth=false, sslCtxFactory=null, sslFactory=null,
> portRange=100, threadPoolSize=8, msgInterceptor=null], odbcCfg=null,
> warmupClos=null, atomicCfg=AtomicConfiguration [seqReserveSize=1000,
> cacheMode=PARTITIONED, backups=1, aff=null, grpName=null], classLdr=null,
> sslCtxFactory=null, platformCfg=null, binaryCfg=null, memCfg=null,
> pstCfg=null, dsCfg=null, activeOnStart=true, autoActivation=true,
> longQryWarnTimeout=3000, sqlConnCfg=null,
> cliConnCfg=ClientConnectorConfiguration [host=null, port=10800,
> portRange=100, sockSndBufSize=0, sockRcvBufSize=0, tcpNoDelay=true,
> maxOpenCursorsPerConn=128, threadPoolSize=8, idleTimeout=0,
> jdbcEnabled=true, odbcEnabled=true, thinCliEnabled=true, sslEnabled=false,
> useIgniteSslCtxFactory=true, sslClientAuth=false, sslCtxFactory=null],
> mvccVacuumThreadCnt=2, mvccVacuumFreq=5000, authEnabled=false,
> failureHnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=[]]],
> commFailureRslvr=null]
> [15:05:34,819][INFO][main][IgniteKernal] Daemon mode: off
> [15:05:34,819][INFO][main][IgniteKernal] OS: Windows 10 10.0 amd64
> [15:05:34,819][INFO][main][IgniteKernal] OS user: mahes

RE: [External]Re: Is there any way to force recover the cluster - copying running cluster datastore

[Kamlesh Joshi]

Hi Ilya,

WAL markers you mean cp folder inside datastore ? or any other ?

Thanks and Regards,
Kamlesh Joshi

From: Ilya Kasnacheev 
Sent: Friday, June 14, 2019 6:59 PM
To: user@ignite.apache.org
Subject: Re: [External]Re: Is there any way to force recover the cluster - 
copying running cluster datastore


The e-mail below is from an external source. Please do not open attachments or 
click links from an unknown or suspicious origin.
Hello!

If your node did not crash during a checkpoint, complerely removing WAL files 
and WAL markers should set you back to some stable state.

If it did crash during a checkpoint, you can't start with corrupted WAL.

Regards,
--
Ilya Kasnacheev


ср, 12 июн. 2019 г. в 17:37, Kamlesh Joshi 
mailto:kamlesh.jo...@ril.com>>:
Hi Denis,

Only WAL disk is corrupted but datastore is intact by any way can we restore 
the cluster ? some data loss is fine. Any suggestion on this?

Thanks and Regards,
Kamlesh Joshi

From: Kamlesh Joshi
Sent: Thursday, June 6, 2019 7:52 PM
To: user@ignite.apache.org
Subject: RE: [External]Re: Is there any way to force recover the cluster - 
copying running cluster datastore

Thanks for the update Denis.

If one of the WAL disk gets failed, is there any way to start or recover the 
cluster forcefully ?

Thanks and Regards,
Kamlesh Joshi

From: Denis Magda mailto:dma...@apache.org>>
Sent: Thursday, June 6, 2019 4:44 PM
To: user@ignite.apache.org
Subject: [External]Re: Is there any way to force recover the cluster - copying 
running cluster datastore


The e-mail below is from an external source. Please do not open attachments or 
click links from an unknown or suspicious origin.
I would discourage you from doing this if data consistency is prominent for 
you. What you see on the disk of one cluster node might be inconsistent with 
the whole cluster state and the actual/last updates in memory. Snapshots and 
backups can solve your task. Google for a solution provided by GridGain.

-
Denis


On Wed, Jun 5, 2019 at 8:27 AM Kamlesh Joshi 
mailto:kamlesh.jo...@ril.com>> wrote:
Hi Team,

We are trying to start another Ignite cluster by taking a copy 
of the running cluster’s datastore (source cluster’s datastore is getting 
modified in parallel). So, when we try to start the server node with copied 
datastore, it gives error as below. Also, giving cluster configuration for 
reference:

pageSize=#{4 * 1024}
walMode=LOG_ONLY
walFlushFrequency=6
rebalanceThreadPoolSize=8
rebalanceThrottle=100
rebalanceBatchSize=#{32 * 1024 * 1024}
storagePath=/datastore/datastore
walPath=/datastore1/wal
walArchivePath=/datastore1/archive
metadataWorkDir=/datastore/metadataWorkDir


[2019-06-05T12:21:52,943][INFO ][main][GridCacheDatabaseSharedManager] Read 
checkpoint status [startMarker=null, endMarker=null]
[2019-06-05T12:21:52,967][INFO ][main][PageMemoryImpl] Started page memory 
[memoryAllocated=128.0 MiB, pages=31744, tableSize=2.5 MiB, 
checkpointBuffer=100.0 MiB]
[2019-06-05T12:21:52,968][INFO ][main][GridCacheDatabaseSharedManager] Checking 
memory state [lastValidPos=FileWALPointer [idx=0, fileOff=0, len=0], 
lastMarked=FileWALPointer [idx=0, fileOff=0, len=0], 
lastCheckpointId=----]
[2019-06-05T12:21:52,973][ERROR][main][IgniteKernal%EDIFCustomer_DR] Exception 
during start processors, node will be stopped and close connections
org.apache.ignite.IgniteCheckedException: Failed to start processor: 
GridProcessorAdapter []
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1742) 
~[ignite-core-2.6.0.jar:2.6.0]
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:980) 
[ignite-core-2.6.0.jar:2.6.0]
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
 [ignite-core-2.6.0.jar:2.6.0]
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
 [ignite-core-2.6.0.jar:2.6.0]
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151) 
[ignite-core-2.6.0.jar:2.6.0]
at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1069) 
[ignite-core-2.6.0.jar:2.6.0]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:955) 
[ignite-core-2.6.0.jar:2.6.0]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:854) 
[ignite-core-2.6.0.jar:2.6.0]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:724) 
[ignite-core-2.6.0.jar:2.6.0]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:693) 
[ignite-core-2.6.0.jar:2.6.0]
at org.apache.ignite.Ignition.start(Ignition.java:352) 
[ignite-core-2.6.0.jar:2.6.0]
at 
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
 [ignite-core-2.6.0.jar:2.6.0]
Caused by: org.apache.ignite.IgniteCheckedException: WAL history is too short 

Ignite client - slow startup

[Dieter Guthardt]

Hi,

we're currently running a couple of servers with various Ignite 
scenarios - version 2.6 and 2.7.
With and without persistence and some only get used to perform server 
based computations without any cache.
It's quite satisfying except the startup time of the client applications 
is pretty slow especially running them from 'remote'.


I realized depending on the cluster configuration the topology send 
around when connecting can get huge.
Even the clusters without caches get really big and it's time consuming 
to connect.


That's all related to the snapshot version, so higher the number so 
bigger the amount of data transferred and slower the connection.
The client instance of Ignite gets bigger and bigger depending on the 
cluster, cache and snapshot history.


Since I haven't found a satisfying answer yet I started digging into 
your code and found the following:


In the class TcpDiscoverySpi you set the default history size of the 
discoCache to be 1000!

After reducing the number to 10 I obtained a decent startup time.

Debugging the ignite client instance now shows a constant size after 
reaching a snapshot version > 10.


I was wondering why the history was set to 1000? How does a small number 
affect the cluster?


Br,

Will

Re: [External]Re: Is there any way to force recover the cluster - copying running cluster datastore

[Ilya Kasnacheev]

Hello!

If your node did not crash during a checkpoint, complerely removing WAL
files and WAL markers should set you back to some stable state.

If it did crash during a checkpoint, you can't start with corrupted WAL.

Regards,
-- 
Ilya Kasnacheev


ср, 12 июн. 2019 г. в 17:37, Kamlesh Joshi :

> Hi Denis,
>
>
>
> Only WAL disk is corrupted but datastore is intact by any way can we
> restore the cluster ? some data loss is fine. Any suggestion on this?
>
>
>
> *Thanks and Regards,*
>
> *Kamlesh Joshi*
>
>
>
> *From:* Kamlesh Joshi
> *Sent:* Thursday, June 6, 2019 7:52 PM
> *To:* user@ignite.apache.org
> *Subject:* RE: [External]Re: Is there any way to force recover the
> cluster - copying running cluster datastore
>
>
>
> Thanks for the update Denis.
>
>
>
> If one of the WAL disk gets failed, is there any way to start or recover
> the cluster forcefully ?
>
>
>
> *Thanks and Regards,*
>
> *Kamlesh Joshi*
>
>
>
> *From:* Denis Magda 
> *Sent:* Thursday, June 6, 2019 4:44 PM
> *To:* user@ignite.apache.org
> *Subject:* [External]Re: Is there any way to force recover the cluster -
> copying running cluster datastore
>
>
>
> The e-mail below is from an external source. Please do not open
> attachments or click links from an unknown or suspicious origin.
>
> I would discourage you from doing this if data consistency is prominent
> for you. What you see on the disk of one cluster node might be inconsistent
> with the whole cluster state and the actual/last updates in memory.
> Snapshots and backups can solve your task. Google for a solution provided
> by GridGain.
>
>
> -
>
> Denis
>
>
>
>
>
> On Wed, Jun 5, 2019 at 8:27 AM Kamlesh Joshi 
> wrote:
>
> Hi Team,
>
>
>
> We are trying to start another Ignite cluster by taking a
> copy of the running cluster’s datastore (source cluster’s datastore is
> getting modified in parallel). So, when we try to start the server node
> with copied datastore, it gives error as below. Also, giving cluster
> configuration for reference:
>
>
>
> *pageSize=#{4 * 1024}*
>
> *walMode=LOG_ONLY*
>
> *walFlushFrequency=6*
>
> *rebalanceThreadPoolSize=8*
>
> *rebalanceThrottle=100*
>
> *rebalanceBatchSize=#{32 * 1024 * 1024}*
>
> *storagePath=/datastore/datastore*
>
> *walPath=/datastore1/wal*
>
> *walArchivePath=/datastore1/archive*
>
> *metadataWorkDir=/datastore/metadataWorkDir*
>
>
>
>
>
> [2019-06-05T12:21:52,943][INFO ][main][GridCacheDatabaseSharedManager]
> Read checkpoint status [startMarker=null, endMarker=null]
>
> [2019-06-05T12:21:52,967][INFO ][main][PageMemoryImpl] Started page memory
> [memoryAllocated=128.0 MiB, pages=31744, tableSize=2.5 MiB,
> checkpointBuffer=100.0 MiB]
>
> [2019-06-05T12:21:52,968][INFO ][main][GridCacheDatabaseSharedManager]
> Checking memory state [lastValidPos=FileWALPointer [idx=0, fileOff=0,
> len=0], lastMarked=FileWALPointer [idx=0, fileOff=0, len=0],
> lastCheckpointId=----]
>
> [2019-06-05T12:21:52,973][ERROR][main][IgniteKernal%EDIFCustomer_DR]
> Exception during start processors, node will be stopped and close
> connections
>
> org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter []
>
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1742)
> ~[ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:980)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1069)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:955)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:854)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:724)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:693)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at org.apache.ignite.Ignition.start(Ignition.java:352)
> [ignite-core-2.6.0.jar:2.6.0]
>
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
> [ignite-core-2.6.0.jar:2.6.0]
>
> Caused by: org.apache.ignite.IgniteCheckedException: WAL history is too
> short
> [descs=[org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDescriptor@4d6c2],
> start=FileWALPointer [idx=0, fileOff=0, len=0]]
>
> at
> 

Ignite client connection from windows machine - UNRELIANCE

[mahesh76private]

Hi, 

In our office, we have client nodes started on windows and Linux machines. 
we see that client nodes on linux always happen to connect to Ignite cluster
properly
However, once in a while *ALL* windows machines fail to connect 

Below is the log on of the windows machines. Any clue ?


[15:05:34,795][INFO][main][IgniteKernal] Config URL: n/a
[15:05:34,813][INFO][main][IgniteKernal] IgniteConfiguration
[igniteInstanceName=null, pubPoolSize=8, svcPoolSize=7, callbackPoolSize=8,
stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4, igfsPoolSize=8,
dataStreamerPoolSize=8, utilityCachePoolSize=8,
utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8,
igniteHome=C:\Users\mahes\Desktop\apache\apache-ignite-2.7.0-bin\apache-ignite-2.7.0-bin,
igniteWorkDir=C:\Users\mahes\Desktop\apache\apache-ignite-2.7.0-bin\apache-ignite-2.7.0-bin\work,
mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@769e7ee8,
nodeId=7d9f28d2-69db-49b5-9c20-219523108114, marsh=BinaryMarshaller [],
marshLocJobs=false, daemon=false, p2pEnabled=true, netTimeout=1,
sndRetryDelay=1000, sndRetryCnt=3, metricsHistSize=1,
metricsUpdateFreq=2000, metricsExpTime=9223372036854775807,
discoSpi=TcpDiscoverySpi [addrRslvr=null, sockTimeout=5, ackTimeout=0,
marsh=null, reconCnt=10, reconDelay=2000, maxAckTimeout=60,
forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null],
segPlc=STOP, segResolveAttempts=2, waitForSegOnStart=true,
allResolversPassReq=true, segChkFreq=1, commSpi=TcpCommunicationSpi
[connectGate=null,
connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@1fa121e2,
enableForcibleNodeKill=false, enableTroubleshootingLog=false,
locAddr=192.168.1.156, locHost=null, locPort=47100, locPortRange=100,
shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=60,
connTimeout=5000, maxConnTimeout=60, reconCnt=10, sockSndBuf=32768,
sockRcvBuf=32768, msgQueueLimit=0, slowClientQueueLimit=0, nioSrvr=null,
shmemSrv=null, usePairedConnections=false, connectionsPerNode=1,
tcpNoDelay=true, filterReachableAddresses=false, ackSndThreshold=32,
unackedMsgsBufSize=0, sockWriteTimeout=4, boundTcpPort=-1,
boundTcpShmemPort=-1, selectorsCnt=1, selectorSpins=0, addrRslvr=null,
ctxInitLatch=java.util.concurrent.CountDownLatch@7eac9008[Count = 1],
stopping=false],
evtSpi=org.apache.ignite.spi.eventstorage.NoopEventStorageSpi@4116aac9,
colSpi=NoopCollisionSpi [], deploySpi=LocalDeploymentSpi [],
indexingSpi=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@15de0b3c,
addrRslvr=null,
encryptionSpi=org.apache.ignite.spi.encryption.noop.NoopEncryptionSpi@489115ef,
clientMode=true, rebalanceThreadPoolSize=1, txCfg=TransactionConfiguration
[txSerEnabled=false, dfltIsolation=REPEATABLE_READ,
dfltConcurrency=PESSIMISTIC, dfltTxTimeout=0,
txTimeoutOnPartitionMapExchange=0, pessimisticTxLogSize=0,
pessimisticTxLogLinger=1, tmLookupClsName=null, txManagerFactory=null,
useJtaSync=false], cacheSanityCheckEnabled=true, discoStartupDelay=6,
deployMode=SHARED, p2pMissedCacheSize=100, locHost=null,
timeSrvPortBase=31100, timeSrvPortRange=100, failureDetectionTimeout=1,
sysWorkerBlockedTimeout=360, clientFailureDetectionTimeout=3,
metricsLogFreq=6, hadoopCfg=null, connectorCfg=ConnectorConfiguration
[jettyPath=null, host=null, port=11211, noDelay=true, directBuf=false,
sndBufSize=32768, rcvBufSize=32768, idleQryCurTimeout=60,
idleQryCurCheckFreq=6, sndQueueLimit=0, selectorCnt=4, idleTimeout=7000,
sslEnabled=false, sslClientAuth=false, sslCtxFactory=null, sslFactory=null,
portRange=100, threadPoolSize=8, msgInterceptor=null], odbcCfg=null,
warmupClos=null, atomicCfg=AtomicConfiguration [seqReserveSize=1000,
cacheMode=PARTITIONED, backups=1, aff=null, grpName=null], classLdr=null,
sslCtxFactory=null, platformCfg=null, binaryCfg=null, memCfg=null,
pstCfg=null, dsCfg=null, activeOnStart=true, autoActivation=true,
longQryWarnTimeout=3000, sqlConnCfg=null,
cliConnCfg=ClientConnectorConfiguration [host=null, port=10800,
portRange=100, sockSndBufSize=0, sockRcvBufSize=0, tcpNoDelay=true,
maxOpenCursorsPerConn=128, threadPoolSize=8, idleTimeout=0,
jdbcEnabled=true, odbcEnabled=true, thinCliEnabled=true, sslEnabled=false,
useIgniteSslCtxFactory=true, sslClientAuth=false, sslCtxFactory=null],
mvccVacuumThreadCnt=2, mvccVacuumFreq=5000, authEnabled=false,
failureHnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=[]]],
commFailureRslvr=null]
[15:05:34,819][INFO][main][IgniteKernal] Daemon mode: off
[15:05:34,819][INFO][main][IgniteKernal] OS: Windows 10 10.0 amd64
[15:05:34,819][INFO][main][IgniteKernal] OS user: mahes
[15:05:34,826][INFO][main][IgniteKernal] PID: 10608
[15:05:34,826][INFO][main][IgniteKernal] Language runtime: Java Platform API
Specification ver. 1.8
[15:05:34,826][INFO][main][IgniteKernal] VM information: Java(TM) SE Runtime
Environment 1.8.0_191-b12 Oracle Corporation Java HotSpot(TM) 64-Bit 

Re: Ignite Nodes Go Down - org.apache.spark.rpc.RpcTimeoutException: Futures timed out after [10 seconds]. This timeout is controlled by spark.executor.heartbeatInterval

[vinod.jv]

Thank you. Our application is huge and complicated. Will explore Standalone
also.
But, why is this inconsistent. We have seen the same job taking 20 min also
and even 2hrs also.
IN the yarn log that runs for 20 min we dont see any exceptions, whereas in
the job that runs for 2hrs we see all the exceptions that i mentioned
multiple times.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/