Re: DiscoveryMetricsProvider implementation ?

[Vinay B,]

Thanks. We used a shared FS store earlier on because I believe that was the
recommended configuration for large grids.

On Thu, Aug 25, 2016 at 8:22 PM, vkulichenko 
wrote:

> Hi Vinay,
>
> DiscoveryMetricsProvider is a different beast and it's an internal
> interface
> implemented by DiscoveryManager. It's not intended to be provided by user.
>
> The abstraction of the store was removed and all the metrics are stored in
> the local memory now (which is equivalent for
> GridTcpDiscoveryVmMetricsStore). What was the reason of using shared FS
> store?
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/DiscoveryMetricsProvider-implementation-tp7312p7321.
> html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

[ANNOUNCE] Apache Ignite 1.7.0 Released

[Denis Magda]

The Apache Ignite Community is pleased to announce the release of Apache Ignite 
1.7.0.

Apache Ignite In-Memory Data Fabric [1] is a high-performance, integrated and 
distributed in-memory platform for computing and transacting on large-scale 
data sets in real-time, orders of magnitude faster than possible with 
traditional disk-based or flash-based technologies.

The Fabric is a collection of independent and well integrated components some 
of which are the following:  
Advance Clustering
Data Grid
Compute Grid
Streaming & CEP
Service Grid

Apache Ignite 1.7.0 incorporates many improvements and bug fixes that are 
listed in the release notes [2].

Among the changes we have the one that we’re proud of and happy to tell the 
world about - the non-collocated distributed SQL joins [3]. This feature opens 
new horizons for Apache Ignite allowing its users executing the whole range of 
imaginable SQL queries covering all the possible and tricky use cases. You can 
read more details about this in the following blog post:
http://dmagda.blogspot.com/2016/08/big-change-in-apache-ignite-17-welcome.html 

 

If you’re ready to make your hands dirty with Apache Ignite 1.7.0 then the 
downloads of source and binary distributions as well as Maven artifacts' 
versions are listed in the following download section:
https://ignite.apache.org/download.cgi 

Please let us know [4] if you encounter any problems.

Regards,

The Apache Ignite Community

[1] https://ignite.apache.org 
[2] https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt 

[3] 
https://apacheignite.readme.io/docs/sql-queries#non-collocated-distributed-joins
 

[4] https://ignite.apache.org/community/resources.html#ask 

[ANNOUNCE] Apache Ignite 1.7.0 Released

[Denis Magda]

The Apache Ignite Community is pleased to announce the release of Apache Ignite 
1.7.0.

Apache Ignite In-Memory Data Fabric [1] is a high-performance, integrated and 
distributed in-memory platform for computing and transacting on large-scale 
data sets in real-time, orders of magnitude faster than possible with 
traditional disk-based or flash-based technologies.

The Fabric is a collection of independent and well integrated components some 
of which are the following:  
Advance Clustering
Data Grid
Compute Grid
Streaming & CEP
Service Grid

Apache Ignite 1.7.0 incorporates many improvements and bug fixes that are 
listed in the release notes [2].

Among the changes we have the one that we’re proud of and happy to tell the 
world about - the non-collocated distributed SQL joins [3]. This feature opens 
new horizons for Apache Ignite allowing its users executing the whole range of 
imaginable SQL queries covering all the possible and tricky use cases. You can 
read more details about this in the following blog post:
http://dmagda.blogspot.com/2016/08/big-change-in-apache-ignite-17-welcome.html 

 

If you’re ready to make your hands dirty with Apache Ignite 1.7.0 then the 
downloads of source and binary distributions as well as Maven artifacts' 
versions are listed in the following download section:
https://ignite.apache.org/download.cgi 

Please let us know [4] if you encounter any problems.

Regards,

The Apache Ignite Community

[1] https://ignite.apache.org 
[2] https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt 

[3] 
https://apacheignite.readme.io/docs/sql-queries#non-collocated-distributed-joins
 

[4] https://ignite.apache.org/community/resources.html#ask 

Clearing a distributed queue hangs after taking down one node

[juanma.cvega]

Hi,

I have come across a situation where a distributed queue hangs. My use case
requires a shared queue that is populated only from the oldest node in a
cluster. Then, the queue is consumed from the same node and the other nodes
in the cluster (in my case only another one). Every time there is a change
in the topology, the queue has to be cleared and repopulated again. 
I wrote a simple test case to replicate the issue. In this test, starting
two nodes work fine. The second one makes the first one clear the queue and
start populating it again. The problem comes when any node is stopped after
that. The code hangs when trying to clear the queue. 
Another problem I have is with the fairness of the queue consumption. The
idea is to have nodes to shard the data by consuming from the queue but
there is always one node taking almost all the data from it. In my case
example, this can be reproduced by using the same sleep time in both the
producer and the consumer.

This is the code I used. Any idea?

Thanks. 

import com.google.common.collect.Lists;
import org.apache.ignite.*;
import org.apache.ignite.cache.CacheMode;
import org.apache.ignite.configuration.AtomicConfiguration;
import org.apache.ignite.configuration.CollectionConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.events.EventType;
import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import
org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class IgniteTest {

   public static void main(String... args) throws InterruptedException {
  Ignite ignite = getIgnite();

  IgniteQueue queue = getQueue(ignite);

  IgniteCluster cluster = ignite.cluster();

  IgniteEvents events = ignite.events();

  IgniteAtomicLong counter = ignite.atomicLong("counter", 0, true);

  ExecutorService consumerThread = Executors.newSingleThreadExecutor();
  consumerThread.execute(() -> {
 while (true) {
System.out.println("Number taken: " + queue.take());
try {
   Thread.sleep(3500);
} catch (InterruptedException e) {
   e.printStackTrace();
}
 }
  });
  ExecutorService producerThread = Executors.newSingleThreadExecutor();
  producerThread.execute(() ->
events.localListen(event -> {
   if (cluster.forOldest().node().isLocal()) {
  System.out.println("Clearing...");
  queue.clear();
  System.out.println("I'm oldest!!");
   }
   return true;
}, EventType.EVT_NODE_FAILED, EventType.EVT_NODE_JOINED,
EventType.EVT_NODE_LEFT));
  Runtime.getRuntime().addShutdownHook(new
Thread(executorService1::shutdownNow));
  Runtime.getRuntime().addShutdownHook(new
Thread(executorService2::shutdownNow));
  while (true) {
 if (cluster.forOldest().node().isLocal()) {
long current = counter.getAndIncrement();
System.out.println("Number put: " + current);
queue.put(current);
Thread.sleep(1000);
 }
  }

   }

   private static IgniteQueue getQueue(Ignite ignite) {
  CollectionConfiguration cfg = new CollectionConfiguration();
  cfg.setBackups(1);
  cfg.setCollocated(false);
  return ignite.queue("queue", 0, cfg);
   }

   private static Ignite getIgnite() {
  IgniteConfiguration configuration = new IgniteConfiguration();
  TcpCommunicationSpi communicationSpi = new TcpCommunicationSpi();
  communicationSpi.setLocalPort(47200);
  communicationSpi.setLocalPortRange(2);
  TcpDiscoveryVmIpFinder tcpDiscoveryVmIpFinder = new
TcpDiscoveryVmIpFinder();
 
tcpDiscoveryVmIpFinder.setAddresses(Lists.newArrayList("localhost:47100..47101"));
  TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
  discoverySpi.setIpFinder(tcpDiscoveryVmIpFinder);
  discoverySpi.setLocalPort(47100);
  discoverySpi.setLocalPortRange(2);
  configuration.setDiscoverySpi(discoverySpi);
  configuration.setCommunicationSpi(communicationSpi);
  configuration.setGridName("PRICE_CHANGE_ALERTS_GRID");
  configuration.setIncludeEventTypes(EventType.EVT_NODE_FAILED,
EventType.EVT_NODE_JOINED, EventType.EVT_NODE_LEFT);
  AtomicConfiguration atomicConfiguration = new AtomicConfiguration();
  atomicConfiguration.setCacheMode(CacheMode.REPLICATED);
  configuration.setAtomicConfiguration(atomicConfiguration);
  return Ignition.start(configuration);
   }
}




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Clearing-a-distributed-queue-hangs-after-taking-down-one-node-tp7353.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Deploying service programmatically hangs the app

[juanma.cvega]

Hi,

apparently the issue we had was related to the service. It had injected some
other classes that weren't serialized. In the end we relied on checking
which node was the oldest to do the stuff we needed from only one node after
there has been a change in the topology. 

Thanks. 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Deploying-service-programmatically-hangs-the-app-tp6791p7352.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Limit on size of Apache Ignite value stored using Memcache protocol

[mrotundo]

Thanks! I will keep digging into this on my side and will follow up if any
progress is made.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Limit-on-size-of-Apache-Ignite-value-stored-using-Memcache-protocol-tp7279p7351.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

javax.cache.CacheException: Failed to find mapping description

[vikramT]

Hi,

I am using Ignite 1.7 over CDH 5.8, and trying to load complete table from
Hive to Ignite Cache.

Error: javax.cache.CacheException: Failed to find mapping description
[cache=InventoryOrdersCache, typeId=581285757]. Please configure JdbcType to
associate cache 'InventoryOrdersCache' with JdbcPojoStore.

Procedure:
1) Used Schema Export utility to import schema from Hive
2) Writing basic java program to import data to cache

Java and Log files

Log file:  ignite-5799638f.log
 
 
CacheConfig: CacheConfig.java
  
CacheConnection: CacheConnection.java

  
InventoryOrders: InventoryOrders.java

  
InventoryOrdersKey: InventoryOrdersKey.java

  

please provide immediate solution




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/javax-cache-CacheException-Failed-to-find-mapping-description-tp7350.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: IgniteCompute.broadcast() stuck

[bintisepaha]

It was hanging because all of our clients were stuck at the below

Thread dump 

Name: main 
State: WAITING on
org.apache.ignite.internal.ComputeTaskInternalFuture@3fd1be52 
Total blocked: 5  Total waited: 5,975 

Stack trace: 
sun.misc.Unsafe.park(Native Method) 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
 
org.apache.ignite.internal.AsyncSupportAdapter.saveOrGet(AsyncSupportAdapter.java:112)
 
org.apache.ignite.internal.IgniteComputeImpl.broadcast(IgniteComputeImpl.java:250)
 
com.tudor.datagridI.client.TradeOrderStoreHelper.processOrderHolders(TradeOrderStoreHelper.java:37)
 
com.tudor.datagridI.TradingDataAccessImpl.saveOrders(TradingDataAccessImpl.java:399)
 
orderserver.client.GridClient.updateOrderHoldersInGrid(GridClient.java:138) 
orderserver.Order.save(Order.java:3619) 
   - locked orderserver.Order@732871ce 
orderserver.Order.save(Order.java:3563) 
   - locked orderserver.Order@732871ce 
izi.izi_data_grid_ignite_test.OrderBooker.bookRegularOrder(OrderBooker.java:111)
 
izi.izi_data_grid_ignite_test.OrderBooker.bookOrder(OrderBooker.java:33) 
izi.izi_data_grid_ignite_test.Main.bookOrders(Main.java:47) 
izi.izi_data_grid_ignite_test.Main.runExc(Main.java:83) 
izi.izi_data_grid_ignite_test.Main.run(Main.java:35) 
izi.izi_data_grid_ignite_test.Runner.run(Runner.java:37) 
izi.izi_data_grid_ignite_test.Runner.main(Runner.java:17) 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/IgniteCompute-broadcast-stuck-tp7255p7349.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Local node seems to be disconnected from topology (failure detection timeout is reached)

[Vladislav Pyatkov]

Hello,

I recoment to use failureDetectionTimeout only for test, because this
timeout determines all timeout for all SPI (Communication, Dicovery).
Use specific timeout of DiscoverySPI for prevention of segmentation
(org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#setSocketTimeout).

The configuration lead to slow change of topology in case failure of node.

On Fri, Aug 26, 2016 at 2:49 PM, yucigou  wrote:

> The root cause of the problem just found is that the VMs are frozen
> sometimes.
>
> Our service team takes backup of the VMs once per day. During the backup,
> the VMs that our application servers are running on would be frozen for a
> few seconds usually, but sometimes more than 40 seconds! When I say a VM is
> frozen here, I mean it is frozen literally, and nothing is going to run
> during this period of time.
>
> So when one VM is frozen, the other Ignite node will consider it is down,
> and as a result, the node on the frozen VM is disconnected with topology
> segmented, etc.
>
> So the solution seems to be set the failureDetectionTimeout property to 60
> seconds, to tolerate the VM being frozen in its worst cases.
>
> My question is, would there be some side effects to set
> failureDetectionTimeout 60 seconds? Any advice in such a situation? Thank
> you.
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Local-node-seems-to-be-disconnected-
> from-topology-failure-detection-timeout-is-reached-tp6797p7347.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Vladislav Pyatkov

Re: Local node seems to be disconnected from topology (failure detection timeout is reached)

[yucigou]

The root cause of the problem just found is that the VMs are frozen
sometimes.

Our service team takes backup of the VMs once per day. During the backup,
the VMs that our application servers are running on would be frozen for a
few seconds usually, but sometimes more than 40 seconds! When I say a VM is
frozen here, I mean it is frozen literally, and nothing is going to run
during this period of time.

So when one VM is frozen, the other Ignite node will consider it is down,
and as a result, the node on the frozen VM is disconnected with topology
segmented, etc.

So the solution seems to be set the failureDetectionTimeout property to 60
seconds, to tolerate the VM being frozen in its worst cases. 

My question is, would there be some side effects to set
failureDetectionTimeout 60 seconds? Any advice in such a situation? Thank
you.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Local-node-seems-to-be-disconnected-from-topology-failure-detection-timeout-is-reached-tp6797p7347.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: LOOK THORUGH THIS ERROR

[Ravi Puri]

All classpaths have same jars. Any other options to cache data apart from
loadCache() method??



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/LOOK-THORUGH-THIS-ERROR-tp6977p7346.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: failureDetectionTimeout NotWritablePropertyException

[yucigou]

Hi Val,

I've just upgraded Spring from version 3.1.2.RELEASE to 3.2.17, and the
problem of setting failureDetectionTimeout is now gone.

(I'm not upgrading to 4.1.0.RELEASE, to keep other modules in my application
happy.)

Thanks for your help.
Yuci



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

Re: Spring application context resource is not injected exception while starting ignite in jdbc driver mode

[Nikolai Tikhonov]

Andery,

It's for guarantee consistency. We should update entries in store in one
transaction how in Ignite.

On Fri, Aug 26, 2016 at 2:01 PM, Andrey Gura  wrote:

> Val,
>
> Why we need store on client node in case of partitioned or replicated
> cache?
>
> On Fri, Aug 26, 2016 at 4:53 AM, vkulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Hi,
>>
>> This happens because JDBC driver tries to initialize the store. This is
>> needed for regular client nodes, but for the driver this doesn't make much
>> sense. I created a ticket: https://issues.apache.org/jira
>> /browse/IGNITE-3771
>>
>> -Val
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Spring-application-context-resource-is-not-
>> injected-exception-while-starting-ignite-in-jdbc-driver
>> -me-tp7299p7328.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>

Re: Spring application context resource is not injected exception while starting ignite in jdbc driver mode

[Andrey Gura]

Val,

Why we need store on client node in case of partitioned or replicated cache?

On Fri, Aug 26, 2016 at 4:53 AM, vkulichenko 
wrote:

> Hi,
>
> This happens because JDBC driver tries to initialize the store. This is
> needed for regular client nodes, but for the driver this doesn't make much
> sense. I created a ticket: https://issues.apache.org/
> jira/browse/IGNITE-3771
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Spring-application-context-resource-
> is-not-injected-exception-while-starting-ignite-in-jdbc-
> driver-me-tp7299p7328.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

Re: LOOK THORUGH THIS ERROR

[Vladislav Pyatkov]

Ravi,

The exception means, what wrong jar-file hits to a classpath your
application.
Please, use maven or other buld to to resolve dependencies and provide
example if this  doesn't help.

On Fri, Aug 26, 2016 at 1:17 PM, Ravi Puri 
wrote:

> I wont be able to use maven and neither uplaod a project.
>
> But I found the class error using debugger.
>
> It was found in cache.loadCache(null,1) . During this process it throws
> error. Is there any other way to load cache data using  IgniteCache Object.
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/LOOK-THORUGH-THIS-ERROR-tp6977p7340.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Spring application context resource is not injected exception while starting ignite in jdbc driver mode

[Vladislav Pyatkov]

Hello,

At this moment Ignite support only SELECT* SQL query.

You can use cache API directly for update or insert data. Ignite implements
JCache API for access to data, you can look article about this[1].

[1]: http://apacheignite.gridgain.org/docs/jcache

On Fri, Aug 26, 2016 at 9:32 AM, san  wrote:

> Hi,
>
> please let know, If JDBC driver is read only then what is the advantage we
> are getting.
> our scenario is
> 1. Populate cache using 'Automatic Persistence' in server.
> 2. client will connect to server using JDBC Driver and access the cache
> using standard sql queries.
> 3. And we are expecting if value is not there in server cache, then server
> should fetch from the db (ReadThrough)
> 4. as well as update the cache using standard sql query and server shall
> update the DB (WriteThrough)
>
> Advantage we are expecting from this is, we can access ignite server cache
> using sql query to do CRUD operation. server shall take care of DB reads
> and
> writes.
>
> In this model without change in existing DAO(JDBC code) layer  we can
> introduce ignite cache in-between application and  DB.
>
> please let know how to solve this issue. is  there any way to do it.
>
> Thanks,
> San
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Spring-application-context-resource-
> is-not-injected-exception-while-starting-ignite-in-jdbc-
> driver-me-tp7299p7332.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Vladislav Pyatkov

Re: LOOK THORUGH THIS ERROR

[Ravi Puri]

I wont be able to use maven and neither uplaod a project.

But I found the class error using debugger. 

It was found in cache.loadCache(null,1) . During this process it throws
error. Is there any other way to load cache data using  IgniteCache Object. 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/LOOK-THORUGH-THIS-ERROR-tp6977p7340.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: partitions' balance among ignite nodes

[Taras Ledkov]

Hi, blueh.

Please take a look at the issue 
https://issues.apache.org/jira/browse/IGNITE-3018.


I created partition distribution diagrams when i worked on the task.

Heatmaps are attached to the issue.

There are diagrams for 3, 64, 100, 128, 200, ..., 600 nodes.

Pay your attention to the left diagram (MD5 title). This is a current 
implementation available on the production.


Horizontally: type of node (primary,  backup0, backup 1);
Vertically: all nodes from topology;
Z-order: count of partitions.


On 26.08.2016 4:45, bluehu wrote:

I have test the partitions' balance among ignite nodes, parts=1024, backup=1

I use 32 ignite nodes to test, and found one node have 50 primary
partitions(max) but the other only have 21 primary partitions(min), in
addition, one node have 83 primary+backup partitions(max) but the other only
have 52 primary+backup partitions(min).

so it looks like bad partitions' balance among ignite nodes, do you have a
report on partitions' balance? and any suggestion if I want to deploy more
ignite nodes?





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/partitions-balance-among-ignite-nodes-tp7327.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.


--
Taras Ledkov
Mail-To: tled...@gridgain.com

Re: why allocated containers much more than INGNITE_NODE_COUNT?

[Nikolai Tikhonov]

Hi,

It's looks like your containers failed and ignite yarn tries to start new
containers. Could you share your configurations and logs from containers?

On Tue, Aug 23, 2016 at 5:18 AM, shirely  wrote:

> well, I tried to integrate ignite with yarn and set IGNITE_NODE_COUNT
> equals
> 2, but when running the ignite yarn application, I found the total
> allocated
> containers is 156 and kept increasing. I'm really confused, what is the
> relationship between ignite node and allocated containers?
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/why-allocated-containers-much-
> more-than-INGNITE-NODE-COUNT-tp7226.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Yarn Ignite Container Automatically exit when other yarn application running

[Nikolai Tikhonov]

Hi,

Could you please show logs from container which was failed?

On Fri, Aug 26, 2016 at 11:36 AM, percent620  wrote:

> Hello,
>
> I faced important issues. I have deployed yarn ignite application
> successfully. everything is okay.
>
>
> But today, when others running spark job on yarn(this job can't contain
> ignite),and faced error message as below
>
> *16/08/26 16:23:52 ERROR YarnScheduler: Lost executor 1 on : Container
> marked as failed: container_1455892346017_5494_01_02 on host:
> vmsecdomain010194054060.cm10. Exit status: -100. Diagnostics: Container
> released on a *lost* node
> *16/08/26 16:23:52 ERROR YarnScheduler: Lost an executor 1 (already
> removed): Pending loss reason.
>
> this is contain is yarn ignite container. I saw yarn contain logs and found
> that lost 1 electors on ignite.
>
>
> Why? Can anyone help me?
>
>
> Regarding yarn ignite integration, I use static ip discovery. I have
> specified all the workers ip ignite configuration, is this lead to error?
>
>
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Yarn-Ignite-Container-Automatically-exit-when-other-
> yarn-application-running-tp7335.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Yarn Ignite Container Automatically exit when other yarn application running

[percent620]

Hello, 

I faced important issues. I have deployed yarn ignite application
successfully. everything is okay.


But today, when others running spark job on yarn(this job can't contain
ignite),and faced error message as below

*16/08/26 16:23:52 ERROR YarnScheduler: Lost executor 1 on : Container
marked as failed: container_1455892346017_5494_01_02 on host:
vmsecdomain010194054060.cm10. Exit status: -100. Diagnostics: Container
released on a *lost* node
*16/08/26 16:23:52 ERROR YarnScheduler: Lost an executor 1 (already
removed): Pending loss reason.

this is contain is yarn ignite container. I saw yarn contain logs and found
that lost 1 electors on ignite.


Why? Can anyone help me?


Regarding yarn ignite integration, I use static ip discovery. I have
specified all the workers ip ignite configuration, is this lead to error?





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Yarn-Ignite-Container-Automatically-exit-when-other-yarn-application-running-tp7335.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: failureDetectionTimeout NotWritablePropertyException

[yucigou]

I just thought of the same thing, the version of Spring :-) But thanks very
much for the explanation. 

I'm currently using Spring version 3.1.2.RELEASE. I'll try a newer version
of Spring today, and hope it won't break any existing functionalities of the
application.



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