Re: Cache Node Concept

[afedotov]

Hi Abhishek.

It's rather an Ignite node running a cache instance and each cache instance
contains its part of overall cache data.

Kind regards,
Alex


5 мая 2017 г. 12:47 AM пользователь "abhishek jain [via Apache Ignite
Users]"  написал:

Hi,

Can we refer a cache instance running on a Ignite server as a node or cache
node ?

Say, a cache is distributed over various Ignite servers, so can we call
each instance in a server as node or cache node ?

Regards
Abhishek


--
If you reply to this email, your message will be added to the discussion
below:
http://apache-ignite-users.70518.x6.nabble.com/Cache-
Node-Concept-tp12442.html
To start a new topic under Apache Ignite Users, email
ml+s70518n1...@n6.nabble.com
To unsubscribe from Apache Ignite Users, click here

.
NAML





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

Re: Query search performance and scalability

[afedotov]

Hi Jessie.

What is the ping between physical nodes?
As well, please try adding two more nodes and share the results.
I think in your case the query is pretty fast initially, so adding more
nodes just add to the total time because of more network messages being
sent. In real life scenarios when executing a query takes several times
more than network overhead you will gain from scaling the cluster.



Kind regards,
Alex


5 мая 2017 г. 8:04 AM пользователь "waterg [via Apache Ignite Users]" <
ml+s70518n12447...@n6.nabble.com> написал:

Here's the cache configuration.
We were expecting to see positive scalability.
What would be reasons to prevent from that?

Btw, the cache has 300K entries in total.
Thank you!




















































On Thu, May 4, 2017 at 9:35 AM, Jessie Lin <[hidden email]
> wrote:

> Alex, thanks for reply.
> The query is fairly simple, colA =?
> colA is String.
> For 1 server 1 client scenario, they are the same server.
> For 2 server 1 client scenario, one server and client are on one server,
> the other server node is on another server.
> Working on a simplified code to reproduce the problem to share with you
>
> Jessie
>
>
> On Wed, May 3, 2017 at 11:14 PM, afedotov <[hidden email]
> > wrote:
>
>> That should be because of the overhead of network roundtrips between the
>> client and the servers. Are servers and client located on the same physical
>> machine?
>> Please provide the query and cache config.
>>
>> Kind regards,
>> Alex
>>
>> 4 мая 2017 г. 3:36 AM пользователь "waterg [via Apache Ignite Users]" 
>> <[hidden
>> email] > написал:
>>
>> I have a program that issues SQLQuery on colA, colA has a single column
>> index.
>> The cache has about 360K entries, and 298K unique values in colA.
>> I ran the query 1M times with different values.
>>
>> If the cache only has cache key, here's the results I ran with three
>> senario
>> With 1 server node: average search time is 35K nanosecs
>> With 1 server – 1 client: average search time is 128K nanosecs
>> With 2 server – 1 client: average search time is 276K nanosecs
>>
>> If the cache has Affinity Key, here's the results I ran with three
>> senario
>> With 1 server node: average search time is 59K nanosecs
>> With 1 server – 1 client: average search time is 148K nanosecs
>> With 2 server – 1 client: average search time is 287K nanosecs
>>
>> Could anyone advise why the search speed degrades as more nodes are
>> added?
>> Thank you!
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://apache-ignite-users.70518.x6.nabble.com/Query-search-
>> performance-and-scalability-tp12401.html
>> To start a new topic under Apache Ignite Users, email [hidden email]
>> 
>> To unsubscribe from Apache Ignite Users, click here.
>> NAML
>> 
>>
>>
>>
>> --
>> View this message in context: Re: Query search performance and
>> scalability
>> 
>>
>> Sent from the Apache Ignite Users mailing list archive
>>  at Nabble.com.
>>
>
>


--
If you reply to this email, your message will be added to the discussion
below:
http://apache-ignite-users.70518.x6.nabble.com/Query-search-performance-and-
scalability-tp12401p12447.html
To start a new topic under Apache Ignite Users, email
ml+s70518n1...@n6.nabble.com
To unsubscribe from Apache Ignite Users, click here

Re: Query search performance and scalability

[Jessie Lin]

Here's the cache configuration.
We were expecting to see positive scalability.
What would be reasons to prevent from that?

Btw, the cache has 300K entries in total.
Thank you!




















































On Thu, May 4, 2017 at 9:35 AM, Jessie Lin 
wrote:

> Alex, thanks for reply.
> The query is fairly simple, colA =?
> colA is String.
> For 1 server 1 client scenario, they are the same server.
> For 2 server 1 client scenario, one server and client are on one server,
> the other server node is on another server.
> Working on a simplified code to reproduce the problem to share with you
>
> Jessie
>
>
> On Wed, May 3, 2017 at 11:14 PM, afedotov 
> wrote:
>
>> That should be because of the overhead of network roundtrips between the
>> client and the servers. Are servers and client located on the same physical
>> machine?
>> Please provide the query and cache config.
>>
>> Kind regards,
>> Alex
>>
>> 4 мая 2017 г. 3:36 AM пользователь "waterg [via Apache Ignite Users]" 
>> <[hidden
>> email] > написал:
>>
>> I have a program that issues SQLQuery on colA, colA has a single column
>> index.
>> The cache has about 360K entries, and 298K unique values in colA.
>> I ran the query 1M times with different values.
>>
>> If the cache only has cache key, here's the results I ran with three
>> senario
>> With 1 server node: average search time is 35K nanosecs
>> With 1 server – 1 client: average search time is 128K nanosecs
>> With 2 server – 1 client: average search time is 276K nanosecs
>>
>> If the cache has Affinity Key, here's the results I ran with three
>> senario
>> With 1 server node: average search time is 59K nanosecs
>> With 1 server – 1 client: average search time is 148K nanosecs
>> With 2 server – 1 client: average search time is 287K nanosecs
>>
>> Could anyone advise why the search speed degrades as more nodes are
>> added?
>> Thank you!
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://apache-ignite-users.70518.x6.nabble.com/Query-search-
>> performance-and-scalability-tp12401.html
>> To start a new topic under Apache Ignite Users, email [hidden email]
>> 
>> To unsubscribe from Apache Ignite Users, click here.
>> NAML
>> 
>>
>>
>>
>> --
>> View this message in context: Re: Query search performance and
>> scalability
>> 
>>
>> Sent from the Apache Ignite Users mailing list archive
>>  at Nabble.com.
>>
>
>

Re: OOME on 2-node cluster with visor running repeatedly, Ignite 1.9

[Andrey Novikov]

 "nc - Total number of nodes in the grid" count server + client nodes. I
can't find metrics for server nodes.

I tried to check the heap dump in "mat" and found a large size of
TcpCommunicationSpi#recoveryDescs. Does anyone have an idea why this
happened?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/OOME-on-2-node-cluster-with-visor-running-repeatedly-Ignite-1-9-tp12409p12446.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: OOME on 2-node cluster with visor running repeatedly, Ignite 1.9

[tysli2016]

Thanks Andrey, is there an option to monitor the number of server nodes in
the grid?

I found "nc - Total number of nodes in the grid.", seems counting server +
client nodes, correct?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/OOME-on-2-node-cluster-with-visor-running-repeatedly-Ignite-1-9-tp12409p12445.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: OOME on 2-node cluster with visor running repeatedly, Ignite 1.9

[tysli2016]

Thank Evgenii!

By running the `${IGNITE_HOME}/bin/ignitevisorcmd.sh -e="'open
-cpath=${IGNITE_HOME}/config/default-config.xml;node'"`, it shows "Ignite
node stopped OK" at the end. Is it an indicator of visor stopped properly?

We use the visor output to check the number of Ignite servers running, this
checking is trigger by a cron job + shell script, so it starts a new visor
each time.

How could a shell script use an already started visor?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/OOME-on-2-node-cluster-with-visor-running-repeatedly-Ignite-1-9-tp12409p12444.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: CacheStore's Performance Drops Dramatically - Why?

[Matt]

Thank you for opening the ticket.

On Thu, May 4, 2017 at 4:43 PM, Denis Magda  wrote:

> Looks like the naming of ‘getWriteBehindFlushSize’ method is totally
> wrong. It confuses so many people. However, if we refer to the
> documentation of this method or look into the source code we will find out
> that it sets the maximum size of the write-behind queue/buffer on a single
> node. Once this size is reached data will be flushed to a storage in the
> sync mode.
>
> So, you need to set the flush size (maximum queue/buffer size) to a bigger
> value if you can’t keep up with updates and always switch to the sync mode.
>
> In any case, I’ve created a ticket to address both issues discussed here:
> https://issues.apache.org/jira/browse/IGNITE-5173
>
> Thanks for your patience.
>
> —
> Denis
>
> On May 3, 2017, at 10:10 AM, Jessie Lin 
> wrote:
>
> I thought flushsize could be set as several times higher than the batch
> size is that in a cluster, data nodes would flush in parallel. For example
> there's a cluster with 10 nodes, and flushSize is 10240, thread count = 2,
> batch size = 512. Then each node would flush out in 2 thread, and each
> thread flushes out in batch of 512.
>
> Could someone confirms or clarify the understanding? Thank you!
>
> On Wed, May 3, 2017 at 12:16 AM, Matt  wrote:
>
>> In fact, I don't see why you would need both batchSize and flushSize. If
>> I got it right, only the min of them would be used by Ignite to know when
>> to flush, why do we have both in the first place?
>>
>> In case they're both necessary for a reason I'm not seeing, I still
>> wonder if the default values should be batchSize > flushSize as I think or
>> not.
>>
>> On Wed, May 3, 2017 at 3:26 AM, Matt  wrote:
>>
>>> I'm writing to confirm I managed to fix my problem by fine tuning the
>>> config params for the write behind cache until the performance was fine. I
>>> still see single element inserts from time to time, but just a few of them
>>> every now and then not like before. You should definitely avoid synchronous
>>> single elements insertions, I hope that changes in future versions.
>>>
>>> Regarding writeBehindBatchSize and writeBehindFlushSize, I don't see
>>> the point of setting both values when batchSize < flushSize (default values
>>> are 512 and 10240 respectively). If I'm not wrong, the cache is flushed
>>> whenever the its size is equal to min(batchSize, flushSize). Since
>>> batchSize is less than flushSize, flushSize is never really used and the
>>> size of the flush is controlled by the size of the cache itself only.
>>>
>>> That is how it works by default, on the other hand if we swap their
>>> values (ie, batchSize=10240 and flushSize=512) the behavior would be
>>> the same (Ignite would call writeAll() with 512 elements each time), but
>>> the number of elements flushed would be controlled by the correct variable
>>> (ie, flushSize).
>>>
>>> Were the default values supposed to be the other way around or am I
>>> missing something?
>>>
>>> On Tue, May 2, 2017 at 9:13 PM, Denis Magda  wrote:
>>>
 Matt,

 Cross-posting to the dev list.

 Yes, Ignite switches to the synchronous mode once the buffer is
 exhausted. However, I do agree that it would be a right solution to flush
 multiple entries rather than one in the synchronous mode. *Igniters*, I was
 sure we had a ticket for that optimization but unable to find it.  Does
 anybody know the ticket name/number?

 To omit the performance degradation you have to tweak the following
 parameters so that the write-behind store can keep up with you updates:
 - setWriteBehindFlushThreadCount
 - setWriteBehindFlushFrequency
 - setWriteBehindBatchSize
 - setWriteBehindFlushSize

 Usually it helped all the times to Apache Ignite users.

 > QUESTION 2
 >
 > I've read on the docs that using ATOMIC mode (default mode) is better
 for performance, but I'm not getting why. If I'm not wrong using
 TRANSACTIONAL mode would cause the CacheStore to reuse connections (not
 call openConnection(autocommit=true) on each writeAll()).
 >
 > Shouldn't it be better to use transactional mode?

 Transactional mode enables 2 phase commit protocol:
 https://apacheignite.readme.io/docs/transactions#two-phase-commit-2pc

 This is why atomic operations are swifter in general.

 —
 Denis

 > On May 2, 2017, at 10:40 AM, Matt  wrote:
 >
 > No, only with inserts, I haven't tried removing at this rate yet but
 it may have the same problem.
 >
 > I'm debugging Ignite internal code and I may be onto something. The
 thing is Ignite has a cacheMaxSize (aka, WriteBehindFlushSize) and
 cacheCriticalSize (which by default is cacheMaxSize*1.5). When the cache
 reaches that size Ignite starts writing elements SYNCHRONOUSLY, as you can
 see in [1].
 >
 > I think this makes things worse since only one single val

Cache Node Concept

[Abhishek Jain]

Hi,

Can we refer a cache instance running on a Ignite server as a node or cache
node ?

Say, a cache is distributed over various Ignite servers, so can we call
each instance in a server as node or cache node ?

Regards
Abhishek

Re: Volatile Kubernetes Node Discovery

[Denis Magda]

Hi,

This seems to be a networking related issue. The Kubernetes IP finder did his 
job pretty well - all the nodes could share assigned IP addresses with each 
other and form a cluster by connecting via 47500 port properly defined in your 
config.

But right after that the nodes attempted to communicate directly with each 
other relying on communication SPI [1] and this is where they failed.

By default communication SPI binds to port 47100 (this happened accordingly to 
the logs), but one node could get through to the other node via this port:

Connection info [in=false, rmtAddr=/172.17.0.7:47100, 
locAddr=/172.17.0.4:47022, msgsSent=2, msgsAckedByRmt=0, descIdHash=899022737, 
msgsRcvd=0, lastAcked=0, descIdHash=899022737, bytesRcvd=0, bytesRcvd0=0, 
bytesSent=201, bytesSent0=0, opQueueSize=0, msgWriter=DirectMessageWriter 
[state=DirectMessageState [pos=0, stack=[StateItem 
[stream=DirectByteBufferStreamImplV2 [buf=java.nio.DirectByteBuffer[pos=0 
lim=32768 cap=32768], baseOff=140562938260976, arrOff=-1, tmpArrOff=0, 
tmpArrBytes=0, msgTypeDone=false, msg=null, mapIt=null, it=null, arrPos=-1, 
keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0, uuidState=0, 
uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true], state=0, 
hdrWritten=false], StateItem [stream=DirectByteBufferStreamImplV2 
[buf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
baseOff=140562938260976, arrOff=-1, tmpArrOff=0, tmpArrBytes=0, 
msgTypeDone=false, msg=null, mapIt=null, it=null, arrPos=-1, keyDone=false, 
readSize=-1, readItems=0, prim=0, primShift=0, uuidState=0, uuidMost=0, 
uuidLeast=0, uuidLocId=0, lastFinished=true], state=0, hdrWritten=false], 
StateItem [stream=DirectByteBufferStreamImplV2 
[buf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
baseOff=140562938260976, arrOff=-1, tmpArrOff=0, tmpArrBytes=0, 
msgTypeDone=false, msg=null, mapIt=null, it=null, arrPos=-1, keyDone=false, 
readSize=-1, readItems=0, prim=0, primShift=0, uuidState=0, uuidMost=0, 
uuidLeast=0, uuidLocId=0, lastFinished=true], state=0, hdrWritten=false], null, 
null, null, null, null, null, null]]], msgReader=null]

As you see the node tried to connect to /172.17.0.7:47100 from it’s own address 
172.17.0.4:47022. Make sure that all these port ranges are not blocked by 
firewalls.

 
[1] https://apacheignite.readme.io/docs/network-config
  
—
Denis

> On May 3, 2017, at 12:04 AM, keinproblem  wrote:
> 
> Denis Magda-2 wrote
>>> Inside my service I'm using a IgniteCache in /Replicated/ mode from
>>> Ignite
>>> 1.9.
>>> Some replicas of this service run inside Kubernetes in form of Pods (1
>>> Container/Pod).
>>> I'm using the 
>>> /org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder/
>>> for the Node Discovery.
>> 
>> Do you mean that a part of the cluster is running outside of Kubernetes?
>> If it’s so this might be an issue because containerized Ignite nodes can’t
>> get trough the network and reach out your nodes that are outside.
>> 
>> —
>> Denis
>> 
>>> On May 2, 2017, at 12:20 PM, keinproblem <
> 
>> noli.m@
> 
>> > wrote:
>>> 
>>> Dear Apache Ignite Users Community,
>>> 
>>> This may be a well-known problem, although the currently available
>>> information does not provide enough help for solving this issue.
>>> 
>>> Inside my service I'm using a IgniteCache in /Replicated/ mode from
>>> Ignite
>>> 1.9.
>>> Some replicas of this service run inside Kubernetes in form of Pods (1
>>> Container/Pod).
>>> I'm using the 
>>> /org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder/
>>> for the Node Discovery.
>>> As I understood: each Pod is able to make an API Call to the Kubernetes
>>> API
>>> and retrieve the list of currently available nodes. This works properly.
>>> Even though the Pod's own IP will also be retrieved, which produces a
>>> somehow harmless 
>>> 
>>> Here is how I get my /IgniteCache/ the used /IgniteConfiguration/
>>> information:
>>> 
>>>   public IgniteCache getCacheInstance(){
>>>   final CacheConfiguration cacheConfiguration =
>>> new
>>> CacheConfiguration<>();
>>>   cacheConfiguration.setName("MyObjectCache");
>>>   return ignite.getOrCreateCache(cacheConfiguration);
>>>   }
>>> 
>>>   public static IgniteConfiguration getDefaultIgniteConfiguration(){
>>>   final IgniteConfiguration cfg = new IgniteConfiguration();
>>>   cfg.setGridLogger(new Slf4jLogger(log));
>>>   cfg.setClientMode(false);
>>> 
>>>   final TcpDiscoveryKubernetesIpFinder kubernetesPodIpFinder = new
>>> TcpDiscoveryKubernetesIpFinder();
>>> 
>>> kubernetesPodIpFinder.setServiceName(SystemDataProvider.getServiceNameEnv);
>>>   final TcpDiscoverySpi tcpDiscoverySpi = new TcpDiscoverySpi();
>>> 
>>> 
>>>   tcpDiscoverySpi.setIpFinder(kubernetesPodIpFinder);
>>>   tcpDiscoverySpi.setLocalPort(47500);//using a static port,
>>> to decrease potential failure causes
>>>   cfg.setFai

Re: what does remaps mean in DataStreamerImpl.java

[vdpyatkov]

Hi,

I have see that your grid suffer from long running operations:

[19:20:19,285][WARNING][grid-timeout-worker-#63%null%][GridCachePartitionExchangeManager]
Found long running cache future [startTime=19:18:55.302,
curTime=19:20:19.280, fut=GridDhtAtomicSingleUpdateFuture
[key=MyProject.TokenSecondMap [idHash=1526386777, hash=2035509954,
processingSecond=1174038983, token=3], nearReaderEntry=null]]
[19:20:19,286][WARNING][grid-timeout-worker-#63%null%][GridCachePartitionExchangeManager]
Found long running cache future [startTime=19:18:55.302,
curTime=19:20:19.280,
 ...

by that reason it can not changing topology fast.

This is topology before killing nodes:

[19:17:42,341][INFO][disco-event-worker-#100%null%][GridDiscoveryManager]
Topology snapshot [ver=30, servers=30, clients=0, CPUs=168, heap=120.0GB]

and the same minor topology version after remaping failed out:

[19:20:41,302][WARNING][exchange-worker-#103%null%][GridCachePartitionExchangeManager]
Ready affinity version: AffinityTopologyVersion [topVer=30, minorTopVer=10]

But actual exchange future have required 33 version already:

[topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0], nodeId=7484419b,
evt=NODE_FAILED]

Remap was failed, because grid had not been in time to change topology.

You should avoid message about long running operations (reduce the load or
change logic), otherwise exchange will going slow and you got the exception.
Also, long exchange can hang whole grid, not only lead to the streamer
exception.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/what-does-remaps-mean-in-DataStreamerImpl-java-tp12033p12440.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: CacheStore's Performance Drops Dramatically - Why?

[Denis Magda]

Looks like the naming of ‘getWriteBehindFlushSize’ method is totally wrong. It 
confuses so many people. However, if we refer to the documentation of this 
method or look into the source code we will find out that it sets the maximum 
size of the write-behind queue/buffer on a single node. Once this size is 
reached data will be flushed to a storage in the sync mode.

So, you need to set the flush size (maximum queue/buffer size) to a bigger 
value if you can’t keep up with updates and always switch to the sync mode.

In any case, I’ve created a ticket to address both issues discussed here:
https://issues.apache.org/jira/browse/IGNITE-5173 


Thanks for your patience.

—
Denis

> On May 3, 2017, at 10:10 AM, Jessie Lin  wrote:
> 
> I thought flushsize could be set as several times higher than the batch size 
> is that in a cluster, data nodes would flush in parallel. For example there's 
> a cluster with 10 nodes, and flushSize is 10240, thread count = 2, batch size 
> = 512. Then each node would flush out in 2 thread, and each thread flushes 
> out in batch of 512. 
> 
> Could someone confirms or clarify the understanding? Thank you!
> 
> On Wed, May 3, 2017 at 12:16 AM, Matt  > wrote:
> In fact, I don't see why you would need both batchSize and flushSize. If I 
> got it right, only the min of them would be used by Ignite to know when to 
> flush, why do we have both in the first place?
> 
> In case they're both necessary for a reason I'm not seeing, I still wonder if 
> the default values should be batchSize > flushSize as I think or not.
> 
> On Wed, May 3, 2017 at 3:26 AM, Matt  > wrote:
> I'm writing to confirm I managed to fix my problem by fine tuning the config 
> params for the write behind cache until the performance was fine. I still see 
> single element inserts from time to time, but just a few of them every now 
> and then not like before. You should definitely avoid synchronous single 
> elements insertions, I hope that changes in future versions.
> 
> Regarding writeBehindBatchSize and writeBehindFlushSize, I don't see the 
> point of setting both values when batchSize < flushSize (default values are 
> 512 and 10240 respectively). If I'm not wrong, the cache is flushed whenever 
> the its size is equal to min(batchSize, flushSize). Since batchSize is less 
> than flushSize, flushSize is never really used and the size of the flush is 
> controlled by the size of the cache itself only.
> 
> That is how it works by default, on the other hand if we swap their values 
> (ie, batchSize=10240 and flushSize=512) the behavior would be the same 
> (Ignite would call writeAll() with 512 elements each time), but the number of 
> elements flushed would be controlled by the correct variable (ie, flushSize).
> 
> Were the default values supposed to be the other way around or am I missing 
> something?
> 
> On Tue, May 2, 2017 at 9:13 PM, Denis Magda  > wrote:
> Matt,
> 
> Cross-posting to the dev list.
> 
> Yes, Ignite switches to the synchronous mode once the buffer is exhausted. 
> However, I do agree that it would be a right solution to flush multiple 
> entries rather than one in the synchronous mode. *Igniters*, I was sure we 
> had a ticket for that optimization but unable to find it.  Does anybody know 
> the ticket name/number?
> 
> To omit the performance degradation you have to tweak the following 
> parameters so that the write-behind store can keep up with you updates:
> - setWriteBehindFlushThreadCount
> - setWriteBehindFlushFrequency
> - setWriteBehindBatchSize
> - setWriteBehindFlushSize
> 
> Usually it helped all the times to Apache Ignite users.
> 
> > QUESTION 2
> >
> > I've read on the docs that using ATOMIC mode (default mode) is better for 
> > performance, but I'm not getting why. If I'm not wrong using TRANSACTIONAL 
> > mode would cause the CacheStore to reuse connections (not call 
> > openConnection(autocommit=true) on each writeAll()).
> >
> > Shouldn't it be better to use transactional mode?
> 
> Transactional mode enables 2 phase commit protocol: 
> https://apacheignite.readme.io/docs/transactions#two-phase-commit-2pc 
> 
> 
> This is why atomic operations are swifter in general.
> 
> —
> Denis
> 
> > On May 2, 2017, at 10:40 AM, Matt  > > wrote:
> >
> > No, only with inserts, I haven't tried removing at this rate yet but it may 
> > have the same problem.
> >
> > I'm debugging Ignite internal code and I may be onto something. The thing 
> > is Ignite has a cacheMaxSize (aka, WriteBehindFlushSize) and 
> > cacheCriticalSize (which by default is cacheMaxSize*1.5). When the cache 
> > reaches that size Ignite starts writing elements SYNCHRONOUSLY, as you can 
> > see in [1].
> >
> > I think this makes things worse since only one single value is fl

Re: Write behind and eventual consistency

[vkulichenko]

If it's this kind of batch processing, and if you're still waiting for a
batch to be processed completely before the next one can be processed, why
do you want to use write-behind? What is wrong with sync write-through in
this case?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Write-behind-and-eventual-consistency-tp12242p12438.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite TLS with TrustStore

[Andrey Mashenkov]

Hi,

You have to set either trustManagers or trustStoreFilePath.

Do you see any other errors on node start? Can Ignite find trustStore?
Does trustStore contains Root cert and all CA certificates, so certificate
path validation can be performed?

Store with root certificates locates in JRE/lib/security/cacerts file.
Looks like Ignite does not add it by deafult.



On Wed, May 3, 2017 at 10:05 PM, Swetad90  wrote:

> Does ignite looks for Truststore from any other default location or
> Is SSL/TLS keystore/trust store location varies for VMs?
>
> I tried enabled logging to capture the error, but don't seem to find any
> reason for this error-
>  Failed to initialize connection (missing SSL configuration on remote
> node?)
> [rmtAddr=/10.17.XX.XXX]
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Ignite-TLS-with-TrustStore-tp12362p12399.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Network Discovery inside docker containers

[Andrey Mashenkov]

Hi,

Yes, addressResolver should be helpful, but seems, there is a bug [1]

[1] https://issues.apache.org/jira/browse/IGNITE-5117

On Thu, Apr 27, 2017 at 10:15 AM, Lukas Lentner 
wrote:

> Ok,
>
>
>
> I heard from chat that I should use an https://ignite.apache.org/
> releases/1.8.0/javadoc/org/apache/ignite/configuration/
> BasicAddressResolver.html
>
> ADDRESS Resolver.
>
>
>
> I will look into it.
>
>
>
> Thankx
>
> Lukas
>
>
>
>
>
> 
>
>
>
> *Lukas Lentner, B. Sc.*
>
> St.-Cajetan-Straße 13
>
> 81669 München
>
> Deutschland
>
> Fon: +49 / 89  / 71 67 44 96
>
> Mobile:  +49 / 176 / 24 77 09 22
>
> E-Mail:  kont...@lukaslentner.de
>
> Website: www.LukasLentner.de
>
>
>
> IBAN:DE33 7019  0001 1810 17
>
> BIC: GENODEF1M01 (Münchner Bank)
>
>
>
> *Von:* Lukas Lentner [mailto:kont...@lukaslentner.de]
> *Gesendet:* Donnerstag, 27. April 2017 08:58
> *An:* user@ignite.apache.org
> *Betreff:* Network Discovery inside docker containers
>
>
>
> Hi,
>
>
>
> I have a question about Discovery in a Docker environment.
>
>
>
> I have multiple machines running multiple docker containers with ignite in
> it. I want to use JDBC Discovery. I give every container a dedicated
> communication port and discovery port.
>
> My understanding was that the Database Table should be filled with HOSTs
> and PORTs that can be reached from any ignite node so that they can find
> each other. So that’s why I exposed both ports through docker to the
> outside for each container without relaying it (changing the port number).
> You could call machine-1-ip:container-1-discovery-port to discover the
> “Container 1” inside “Machine 1”.
>
>
>
> To achive that I set discoveryLocalAddress to the ip of the docker host
> (the machine). But it seems that does not work because this address is also
> used to bind the socket inside the docker container.
>
>
>
> As I do not care on which network interface ignite is binding inside the
> docker container from this perspective I would not set the localAddress of
> the discoverySpi.
>
>
>
> How can I not set the local discovery address (because of binding) but
> still make the JDBC-Discovery-IP-Finder put the machine ip inside the
> database table?
>
>
>
> It is not about retrieving the machine ip. At all times I have that!
>
>
>
> Thankx
>
> Lukas
>
>
>
>
>
> 
>
>
>
> *Lukas Lentner, B. Sc.*
>
>
>
> St.-Cajetan-Straße 13
>
> 81669 München
>
> Deutschland
>
>
>
> Fon: +49 / 89  / 71 67 44 96
>
> Mobile:  +49 / 176 / 24 77 09 22
>
>
>
> E-Mail:  kont...@lukaslentner.de
>
> Website: www.LukasLentner.de
>
>
>
> IBAN:DE33 7019  0001 1810 17
>
> BIC: GENODEF1M01 (Münchner Bank)
>
>
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Nodes hanging when accessing queue

[Andrey Mashenkov]

Hi,

1. Yes, adding backups for datastructures cache (via AtomicConfiguration)
shoud help.

2. Seems, one or more of your nodes register with ipv6 address. Try to use
JVM option for all nodes: either -Djava.net.preferIPv4Stack=true or
 -Djava.net.preferIPv6Stack=true.

On Tue, May 2, 2017 at 5:17 PM, jpmoore40  wrote:

> Hi,
>
> I've been having a couple of issues with a shared IgniteQueue which seem to
> occur sporadically. I have a single publisher process which pushes data
> onto
> a queue, and several worker processes that pull the data from the queue and
> perform some processing. However these nodes are part of a larger qrid
> containing other nodes that submit and process IgniteCallables. I partition
> these using an environment variable clusterName=xxx so the IgniteCallables
> are only computed on a particular cluster group. This seemed like the best
> way of doing things as I am using the TcpDiscoveryJdbcIpFinder and didn't
> want to set up a different database for each discrete grid.
>
> Several times I have found that the publishers and workers accessing the
> IgniteQueue stop processing and there seem to be two separate problems
> occurring.
>
> The first was that I would get an exception such as the following when a
> node was stopped:
>
> java.lang.IllegalStateException: Cache has been stopped: datastructures_0
>   at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.checkStatus(
> GridCacheGateway.java:85)
>   at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(
> GridCacheGateway.java:68)
>   at
> org.apache.ignite.internal.processors.datastructures.
> GridCacheQueueProxy.contains(GridCacheQueueProxy.java:160)
>   at
> my.com.CrossFxCurvePubService.addToQueue(CrossFxCurvePubService.java:267)
>   ...
>
> This I think I solved (i.e. it hasn't happened since) by ensuring that the
> CollectionConfiguration was initialised with backups, though if anyone can
> confirm that would be helpful.
>
> However the second problem (which also causes the queue publisher and
> workers to stop processing) is accompanied by repeated blocks of messages
> such as the following:
>
> 2017-04-28 14:08:05,468 WARN  [grid-nio-worker-2-#11%null%] java.JavaLogger
> (JavaLogger.java:278) - Failed to process selector key (will close):
> GridSelectorNioSessionImpl [selectorIdx=2, queueSize=0,
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
> recovery=GridNioRecoveryDescriptor [acked=9, resendCnt=0, rcvCnt=8,
> sentCnt=9, reserved=true, lastAck=8, nodeLeft=false, node=TcpDiscoveryNode
> [id=c91ce074-964e-4497-ac77-a3828b301ed3, addrs=[0:0:0:0:0:0:0:1,
> 10.127.197.150, 127.0.0.1], sockAddrs=[/0:0:0:0:0:0:0:1:0,
> /10.127.197.150:0, /127.0.0.1:0], discPort=0, order=161, intOrder=84,
> lastExchangeTime=1493384810687, loc=false, ver=1.8.0#20161205-sha1:
> 9ca40dbe,
> isClient=true], connected=true, connectCnt=1, queueLimit=5120,
> reserveCnt=1], super=GridNioSessionImpl [locAddr=/10.127.246.164:60985,
> rmtAddr=/10.127.197.150:47100, createTime=1493384812272, closeTime=0,
> bytesSent=73469, bytesRcvd=1053, sndSchedTime=1493384869270,
> lastSndTime=1493384831058, lastRcvTime=1493384869270, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter
> [parser=o.a.i.i.util.nio.GridDirectParser@1b4d47c, directMode=true],
> GridConnectionBytesVerifyFilter], accepted=false]]
>
> 2017-04-28 14:08:05,470 WARN  [grid-nio-worker-2-#11%null%] java.JavaLogger
> (JavaLogger.java:278) - Closing NIO session because of unhandled exception
> [cls=class o.a.i.i.util.nio.GridNioException, msg=An existing connection
> was
> forcibly closed by the remote host]
>
> 2017-04-28 14:08:14,279 WARN  [disco-event-worker-#20%null%]
> java.JavaLogger
> (JavaLogger.java:278) - Node FAILED: TcpDiscoveryNode
> [id=c91ce074-964e-4497-ac77-a3828b301ed3, addrs=[0:0:0:0:0:0:0:1,
> 10.127.197.150, 127.0.0.1], sockAddrs=[/0:0:0:0:0:0:0:1:0,
> /10.127.197.150:0, /127.0.0.1:0], discPort=0, order=161, intOrder=84,
> lastExchangeTime=1493384810687, loc=false, ver=1.8.0#20161205-sha1:
> 9ca40dbe,
> isClient=true]
> 2017-04-28 14:08:14,287 INFO  [disco-event-worker-#20%null%]
> java.JavaLogger
> (JavaLogger.java:273) - Topology snapshot [ver=162, servers=6, clients=0,
> CPUs=24, heap=3.5GB]
> 2017-04-28 14:08:14,295 INFO  [exchange-worker-#24%null%] java.JavaLogger
> (JavaLogger.java:273) - Skipping rebalancing (nothing scheduled)
> [top=AffinityTopologyVersion [topVer=162, minorTopVer=0], evt=NODE_FAILED,
> node=c91ce074-964e-4497-ac77-a3828b301ed3]
>
> 2017-04-28 14:08:35,853 WARN  [grid-timeout-worker-#7%null%]
> java.JavaLogger
> (JavaLogger.java:278) - Found long running cache future
> [startTime=14:06:52.182, curTime=14:08:35.828,
> fut=GridPartitionedSingleGetFuture [topVer=AffinityTopologyVersion
> [topVer=161, minorTopVer=0], key=UserKeyCacheObjectImpl
> [val=GridCacheQueueItemKey
> [queueId=9c0396aab51-f5c26da7-4123

Re: Combined off heap size?

[Andrey Mashenkov]

Hi,

1. Ignite will throw GridOffHeapOutOfMemoryException if you try to allocate
more than 10G, and will remove entries from cache if it number exceeds 10k
(according to eviction policy).
If you want Ignite remove entries when its occupy more than 10G, then you
need to configure eviction policy maxMemory limit.
Also, offHeapMaxMemory is limit for cache data, but Ignite can allocate a
little more memory for system structures.

2. Are you sure it is possible to run out of 10Gb with 10k entries limit in
your case?
In 1.x version, each cache has its own offheap memory pool, this limitation
has been removed in 2.0 release.
However, there is no way to handle such multi tenancy in ignite as nodes
will be run in separate processes with own virtual memory.

Seems, LRUEvictionPolicy with maxMemory limit can fit your needs.

3. OS will start swapping if it is possible, otherwise JVM process should
end up with allocation failure.


On Tue, May 2, 2017 at 9:22 PM, Swetad90  wrote:

> Hi,
>
> I have a physical 8x32 server and I am using 4 data nodes in one cluster
> group(G1)
>
> I have the below config:
> 
>
> 
>
> 
>
> 
>  
>
> 
> 
> 
>
> So basically I am assigning 40GB of off-heap memory. I know that this is
> just assigned, nodes will use that memory as and when data comes in. Based
> on this scenario -
>
> 1. What will happen once I have exhausted 32 GB of memory. I don't have
> SWAP
> memory configured. How will Ignite behave?
>
> 2. If I have a separate cluster group of another 3 nodes(G2) on the same
> server being used by another application. They will also be affected as the
> current 4 nodes(in G1) will utilize all the memory of the server. Is there
> any other workaround/ best practices to handle such multi tenancy in
> ignite?
>
> 3. When it comes to this memory allocation, has OS anything to with it or
> everything is taken care by the JVM/ignite instance only.
>
> Thanks.
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Combined-off-heap-size-tp7137p12353.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Best regards,
Andrey V. Mashenkov

Re: embedded mode vs standalone mode

[Nikolai Tikhonov]

In this case you need to use standalone mode. In first job you need to
store data to IgniteRDD by IgniteRDD#saveValues. In second job you shoud
create RDD from the same cache and result of first job will be avaliable
threre.

On Mon, May 1, 2017 at 1:33 PM, Nikolai Tikhonov 
wrote:

> Hi,
>
> > In the embedded mode, can the "state" be shared across multiple Spark
> > applications, if the Ignite server within the Spark application not die?
>
> In embedded mode applications can share the state but only during lifespan.
>
> >If the "state" can only be shared in standalone mode, what is the value of
> embedded mode?
>
> In standalone mode you can use IgniteRDD and read data from Ignite.
>
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/embedded-mode-vs-standalone-mode-tp12317p12319.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Query search performance and scalability

[Jessie Lin]

Alex, thanks for reply.
The query is fairly simple, colA =?
colA is String.
For 1 server 1 client scenario, they are the same server.
For 2 server 1 client scenario, one server and client are on one server,
the other server node is on another server.
Working on a simplified code to reproduce the problem to share with you

Jessie


On Wed, May 3, 2017 at 11:14 PM, afedotov 
wrote:

> That should be because of the overhead of network roundtrips between the
> client and the servers. Are servers and client located on the same physical
> machine?
> Please provide the query and cache config.
>
> Kind regards,
> Alex
>
> 4 мая 2017 г. 3:36 AM пользователь "waterg [via Apache Ignite Users]" <[hidden
> email] > написал:
>
> I have a program that issues SQLQuery on colA, colA has a single column
> index.
> The cache has about 360K entries, and 298K unique values in colA.
> I ran the query 1M times with different values.
>
> If the cache only has cache key, here's the results I ran with three
> senario
> With 1 server node: average search time is 35K nanosecs
> With 1 server – 1 client: average search time is 128K nanosecs
> With 2 server – 1 client: average search time is 276K nanosecs
>
> If the cache has Affinity Key, here's the results I ran with three senario
> With 1 server node: average search time is 59K nanosecs
> With 1 server – 1 client: average search time is 148K nanosecs
> With 2 server – 1 client: average search time is 287K nanosecs
>
> Could anyone advise why the search speed degrades as more nodes are added?
> Thank you!
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Query-search-
> performance-and-scalability-tp12401.html
> To start a new topic under Apache Ignite Users, email [hidden email]
> 
> To unsubscribe from Apache Ignite Users, click here.
> NAML
> 
>
>
>
> --
> View this message in context: Re: Query search performance and scalability
> 
>
> Sent from the Apache Ignite Users mailing list archive
>  at Nabble.com.
>

Re: HDP, Hive + Ignite

[Ivan Veselovsky]

Hi, Alena, 

3. Looks like we have an answer why the initial topology version is so high:
you possibly do not restart the Visor process, is that true? If so, please
start next experiment with all nodes stopped, as well as the Visor process .
After that initial topology version should start with 1, it is not persisted
anywhere.
We should make sure each new started server joins successfully, with the 1st
attempt, and no "Node left topology" message ever appears. If it does, need
to investigate, why before further experiments. 

4. Ignite MR also makes all intermediate operations in memory, so I don't
see any obvious reasons of why Ignite MR vs. TEZ comparison is senseless. I
suppose, the above results (23 sec on Tez vs. 80 sec on IgniteMR) can be
explained by the fact that Ignite was running in 1-node mode, while Tez was
using several (6?) nodes.



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

Re: Binary serialization with multiple classloaders

[npordash]

Hi Sergei,

I have a similar use-case and as you've noticed you can write to the cache
just fine, but reading throws a ClassNotFoundException. At the moment you
have to switch to binary mode for the cache in order to do reads and then do
the deserialization directly.

I started a thread on this not too long ago which then got cross-posted to
the dev list:
http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td12055.html
http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html

-Nick




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Binary-serialization-with-multiple-classloaders-tp12408p12429.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: What is the mechanism of Ignite distributed messaging?

[Nikolai Tikhonov]

For this Ignite uses semaphore. You can configure count of permits by
TcpCommunicationSpi#setMessageQueueLimit.

On Tue, May 2, 2017 at 4:53 AM, ght230  wrote:

> I understand that this mechanism is similar to Kafka.
>
> Is there alse a place to keep the messages that have been sent by the
> sender
> but have not yet been received by the listener?
>
> If so,what is the size of the place? Is it can be configured?
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/What-is-the-mechanism-of-Ignite-distributed-messaging-
> tp12272p12331.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Lots of cache creation become slow

[ctranxuan]

Well, that was a new design assumption for the architecture of our PoC.
At the beginning, we wanted some "multi-tenant" caches with 1 continuous
query for each. Then, we've tried to switch with one cache and 1 continous
query for each key.
But, you're right. We have already started to challenge our PoC with 1
continous query for the whole cache. 

Thanks for the advice!



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

Re: Failed to send datagram message to remote node

[Nikolai Tikhonov]

Michaell,

Yes, sure. This is right place. ;) Did this problem gone when you disable
firewall?

On Tue, May 2, 2017 at 9:06 PM, Nikolai Tikhonov 
wrote:

> Hi,
>
> Seems that you did correct rules. Did you try disable firewall, is it
> works? Can you check the ports by iperf?
>
> On Mon, May 1, 2017 at 1:48 PM, Nikolai Tikhonov 
> wrote:
>
>> Hi,
>>
>> Are you sure that you allowed to send UDP message through this port?
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Failed-to-send-datagram-message-to-remote-
>> node-tp12316p12320.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>

Re: Resource Injection in .NET

[Pavel Tupitsyn]

There is no peer class loading in .NET (yet).

I'm working on this feature right now, hopefully it will be released in 2.1:
https://issues.apache.org/jira/browse/IGNITE-2492

On Thu, May 4, 2017 at 4:35 PM, Humphrey  wrote:

> Thanks.
>
> I can't seem to find the PeerClassLoading method in IgniteConfiguration. Is
> there one?
>
> Humphrey
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Resource-Injection-in-NET-tp12420p12424.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Resource Injection in .NET

[Humphrey]

Thanks.

I can't seem to find the PeerClassLoading method in IgniteConfiguration. Is
there one?

Humphrey



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

Re: Resource Injection in .NET

[Pavel Tupitsyn]

Alternatively, you can just call Ignition.GetIgnite().

On Thu, May 4, 2017 at 4:27 PM, Pavel Tupitsyn  wrote:

> It is similar to Java, use [InstanceResource] attribute:
>
> class MyJob : IComputeJob
> {
> [InstanceResource] private IIgnite _ignite;
>
> public object Execute()
> {
> Console.WriteLine(_ignite.Name);
>  ...
> }
> 
> }
>
>
> On Thu, May 4, 2017 at 4:19 PM, Humphrey  wrote:
>
>> This question is related to .NET with C#.
>>
>> I have a class that implements IComputeJob, which prints out a line in the
>> console.
>> How can I inlcude the IgniteInstanceName in the Console.WriteLine method?
>>
>> I know in Java you can inject the Ignite instace in the method, but I
>> don't
>> know how I should do it in C#.
>>
>> In Java:
>> @IgniteInstanceResource
>> private Ignite ignite;
>>
>> I'm just upgraded everything to ignite 2.0.0 with NUGET.
>>
>> Humphrey
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Resource-Injection-in-NET-tp12420.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>

Re: Resource Injection in .NET

[Pavel Tupitsyn]

It is similar to Java, use [InstanceResource] attribute:

class MyJob : IComputeJob
{
[InstanceResource] private IIgnite _ignite;

public object Execute()
{
Console.WriteLine(_ignite.Name);
 ...
}

}


On Thu, May 4, 2017 at 4:19 PM, Humphrey  wrote:

> This question is related to .NET with C#.
>
> I have a class that implements IComputeJob, which prints out a line in the
> console.
> How can I inlcude the IgniteInstanceName in the Console.WriteLine method?
>
> I know in Java you can inject the Ignite instace in the method, but I don't
> know how I should do it in C#.
>
> In Java:
> @IgniteInstanceResource
> private Ignite ignite;
>
> I'm just upgraded everything to ignite 2.0.0 with NUGET.
>
> Humphrey
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Resource-Injection-in-NET-tp12420.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: getting a basic error while running ignite

[Humphrey]

Caused by: java.lang.ClassNotFoundException: test.ignite.BasicTask 

The ignite server started with bin/ignite.sh doesn't have the BasicTask
class on it's classpath.

If you disable peerclassloading it won't work.

See:
https://ignite.apache.org/releases/1.9.0/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#setPeerClassLoadingEnabled(boolean)

Humphrey



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/getting-a-basic-error-while-running-ignite-tp12418p12421.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Resource Injection in .NET

[Humphrey]

This question is related to .NET with C#.

I have a class that implements IComputeJob, which prints out a line in the
console.
How can I inlcude the IgniteInstanceName in the Console.WriteLine method?

I know in Java you can inject the Ignite instace in the method, but I don't
know how I should do it in C#.

In Java:
@IgniteInstanceResource
private Ignite ignite;

I'm just upgraded everything to ignite 2.0.0 with NUGET.

Humphrey



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

Re: HDP, Hive + Ignite

[Alena Melnikova]

Hi Ivan,

1. Need more time for experiments... 

3. Yes, logs are full. I started every node with this command:
$IGNITE_HOME/bin/ignite.sh -v -J"-Xms10g -Xmx10g -XX:MaxMetaspaceSize=4g"
2>&1 | tee
/home/ignite/apache-ignite-hadoop-1.9.0-bin/work/log/ignite-node-dnX.log
I thought ver=72 because I did 72 attempts))
I don't know how to reset this counter. I stop ignite nodes Ctrl-C or Ctrl-Z
(then kill PID) or in Visor kill -k.

Look, there is no Ignite process, but now ver=109:
*[ignite@dev-dn1 ~]$ ps -ef | grep ignite*
ignite6796 21325  0 15:04 pts/500:00:00 ps -ef
ignite6797 21325  0 15:04 pts/500:00:00 grep ignite
root 21324 21290  0 May02 pts/500:00:00 su - ignite
ignite   21325 21324  0 May02 pts/500:00:00 -bash
root 27287 17525  0 May02 pts/100:00:00 su - ignite
ignite   27288 27287  0 May02 pts/100:00:00 -bash
*[ignite@dev-dn1 ~]$ $IGNITE_HOME/bin/ignite.sh -v -J"-Xms10g -Xmx10g
-XX:MaxMetaspaceSize=4g" 2>&1 | tee
/home/ignite/apache-ignite-hadoop-1.9.0-bin/work/log/ignite-node.log*
Ignite Command Line Startup, ver. 1.9.0#20170302-sha1:a8169d0a
2017 Copyright(C) Apache Software Foundation

[15:04:08,630][INFO ][main][IgniteKernal] 

>>>__    
>>>   /  _/ ___/ |/ /  _/_  __/ __/  
>>>  _/ // (7 7// /  / / / _/
>>> /___/\___/_/|_/___/ /_/ /___/   
>>> 
>>> ver. 1.9.0#20170302-sha1:a8169d0a
>>> 2017 Copyright(C) Apache Software Foundation
>>> 
>>> Ignite documentation: http://ignite.apache.org

[15:04:08,630][INFO ][main][IgniteKernal] Config URL:
file:/home/ignite/apache-ignite-hadoop-1.9.0-bin/config/default-config.xml
[15:04:08,630][INFO ][main][IgniteKernal] Daemon mode: off
[15:04:08,631][INFO ][main][IgniteKernal] OS: Linux 2.6.32-696.el6.x86_64
amd64
[15:04:08,631][INFO ][main][IgniteKernal] OS user: ignite
[15:04:08,631][INFO ][main][IgniteKernal] PID: 6891
[15:04:08,631][INFO ][main][IgniteKernal] Language runtime: Java Platform
API Specification ver. 1.8
[15:04:08,631][INFO ][main][IgniteKernal] VM information: Java(TM) SE
Runtime Environment 1.8.0_101-b13 Oracle Corporation Java HotSpot(TM) 64-Bit
Server VM 25.101-b13
[15:04:08,633][INFO ][main][IgniteKernal] VM total memory: 9.6GB
[15:04:08,633][INFO ][main][IgniteKernal] Remote Management [restart: on,
REST: on, JMX (remote: on, port: 49199, auth: off, ssl: off)]
[15:04:08,633][INFO ][main][IgniteKernal]
IGNITE_HOME=/home/ignite/apache-ignite-hadoop-1.9.0-bin
[15:04:08,633][INFO ][main][IgniteKernal] VM arguments: [-Xms1g, -Xmx1g,
-XX:+AggressiveOpts, -XX:MaxMetaspaceSize=256m,
-Djava.library.path=/usr/hdp/current/hadoop-client/lib/native/,
-DIGNITE_QUIET=false,
-DIGNITE_SUCCESS_FILE=/home/ignite/apache-ignite-hadoop-1.9.0-bin/work/ignite_success_6a954010-244e-42bb-9cf7-b4fbbf39519a,
-Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.port=49199,
-Dcom.sun.management.jmxremote.authenticate=false,
-Dcom.sun.management.jmxremote.ssl=false,
-DIGNITE_HOME=/home/ignite/apache-ignite-hadoop-1.9.0-bin,
-DIGNITE_PROG_NAME=/home/ignite/apache-ignite-hadoop-1.9.0-bin/bin/ignite.sh,
-Xms10g, -Xmx10g, -XX:MaxMetaspaceSize=4g]
[15:04:08,634][INFO ][main][IgniteKernal] Configured caches
['ignite-marshaller-sys-cache', 'ignite-sys-cache',
'ignite-hadoop-mr-sys-cache', 'ignite-atomics-sys-cache', 'igfs-meta',
'igfs-data']
[15:04:08,638][INFO ][main][IgniteKernal] 3-rd party licenses can be found
at: /home/ignite/apache-ignite-hadoop-1.9.0-bin/libs/licenses
[15:04:08,725][INFO ][main][IgnitePluginProcessor] Configured plugins:
[15:04:08,725][INFO ][main][IgnitePluginProcessor]   ^-- None
[15:04:08,725][INFO ][main][IgnitePluginProcessor] 
[15:04:08,786][INFO ][main][TcpCommunicationSpi] Successfully bound
communication NIO server to TCP port [port=47100, locHost=0.0.0.0/0.0.0.0,
selectorsCnt=4, selectorSpins=0, pairedConn=false]
[15:04:08,790][WARN ][main][TcpCommunicationSpi] Message queue limit is set
to 0 which may lead to potential OOMEs when running cache operations in
FULL_ASYNC or PRIMARY_SYNC modes due to message queues growth on sender and
receiver sides.
[15:04:08,810][WARN ][main][NoopCheckpointSpi] Checkpoints are disabled (to
enable configure any GridCheckpointSpi implementation)
[15:04:08,842][WARN ][main][GridCollisionManager] Collision resolution is
disabled (all jobs will be activated upon arrival).
[15:04:08,846][WARN ][main][NoopSwapSpaceSpi] Swap space is disabled. To
enable use FileSwapSpaceSpi.
[15:04:08,847][INFO ][main][IgniteKernal] Security status
[authentication=off, tls/ssl=off]
[15:04:09,292][INFO ][main][GridTcpRestProtocol] Command protocol
successfully started [name=TCP binary, host=0.0.0.0/0.0.0.0, port=11211]
[15:04:09,718][INFO ][main][IpcServerTcpEndpoint] IPC server loopback
endpoint started [port=10500]
[15:04:09,720][INFO ][main][IpcServerTcpEndpoint] IPC server loopback
endpoint started [port=11400]
[15:04:09,729][INFO ][main][HadoopProcessor] HADOOP_HOME is set to
/usr/hdp/current/hadoop-client
[15:04:09,730][INFO ][

getting a basic error while running ignite

[tuco.ramirez]

Hi, 

I am trying to run ignite server from the command line and client from the
java code(the way it would happen for us).

So, ignite server is started by 

bin/ignite.sh

The Java code for the client is 

package test.ignite;

import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCompute;
import org.apache.ignite.Ignition;
import org.apache.ignite.configuration.IgniteConfiguration;

public class BasicClient {
public static void main(String[] args){
Ignition.setClientMode(true);

IgniteConfiguration conf = new IgniteConfiguration();
//conf.setPeerClassLoadingEnabled(true);

Ignite ignite = Ignition.start(conf);

IgniteCompute async = ignite.compute();
async.broadcast(new BasicTask());
}
}



// Basic Task class is below.

package test.ignite;

import java.io.Serializable;

import org.apache.ignite.lang.IgniteRunnable;

public class BasicTask implements IgniteRunnable, Serializable {

private static final long serialVersionUID = 1L;

@Override
public void run() {
System.out.println("Hello");
}

}

It works if setPeerClassLoading is set to true, but on commenting it(the way
it will be in prod), i am getting the following error.

May 04, 2017 6:33:12 PM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Failed to obtain remote job result policy for result from
ComputeTask.result(..) method (will fail the whole task): GridJobResultImpl
[job=C4V2 [r=test.ignite.BasicTask@32a68f4f], sib=GridJobSiblingImpl
[sesId=3e49e83db51-39b9383d-8e16-484e-9549-ff0754a57192,
jobId=6e49e83db51-39b9383d-8e16-484e-9549-ff0754a57192,
nodeId=0e233007-058c-46e5-ab74-6d4388c6e118, isJobDone=false],
jobCtx=GridJobContextImpl
[jobId=6e49e83db51-39b9383d-8e16-484e-9549-ff0754a57192, timeoutObj=null,
attrs={}], node=TcpDiscoveryNode [id=0e233007-058c-46e5-ab74-6d4388c6e118,
addrs=[0:0:0:0:0:0:0:1, 10.150.186.57, 127.0.0.1],
sockAddrs=[tindfctmlxl0033.timesgroup.com/10.150.186.57:47501,
/0:0:0:0:0:0:0:1:47501, /127.0.0.1:47501], discPort=47501, order=2,
intOrder=2, lastExchangeTime=1493902991101, loc=false,
ver=1.9.0#20170302-sha1:a8169d0a, isClient=false], ex=class
o.a.i.IgniteException: test.ignite.BasicTask, hasRes=true,
isCancelled=false, isOccupied=true]
class org.apache.ignite.IgniteException: Remote job threw user exception
(override or implement ComputeTask.result(..) method if you would like to
have automatic failover for this exception).
at
org.apache.ignite.compute.ComputeTaskAdapter.result(ComputeTaskAdapter.java:101)
at
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1031)
at
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1024)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6650)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:1024)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:842)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:996)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1221)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1222)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:850)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:108)
at
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:790)
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.IgniteException: test.ignite.BasicTask
at
org.apache.ignite.internal.processors.job.GridJobWorker.initialize(GridJobWorker.java:451)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1108)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
... 7 more
Caused by: class org.apache.ignite.IgniteCheckedException:
test.ignite.BasicTask
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9826)
at
org.apache.ignite.internal.processors.job.GridJobWorker.initialize(GridJobWorker.java:432)
... 9 more
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
test.ignite.BasicTask
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(B

Re: OOME on 2-node cluster with visor running repeatedly, Ignite 1.9

[Andrey Novikov]

Hi tysli2016,

You can run connected to cluster visorcmd in background and register an
alert. When this alert is triggered, it may call custom user script.

More info can be found here:
https://apacheignite-tools.readme.io/docs/alerts-configuration



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/OOME-on-2-node-cluster-with-visor-running-repeatedly-Ignite-1-9-tp12409p12417.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: OOME on 2-node cluster with visor running repeatedly, Ignite 1.9

[Evgenii Zhuravlev]

Hi,

As i see, you run visor in internal mode, so, it creates a node each time.
Are you sure that you stop them properly?

Why do you need to start new visor each time? Just use already started
visor.

Evgenii




2017-05-04 11:57 GMT+03:00 tysli2016 :

> Got "OutOfMemoryError: Java heap space" with 2-node cluster with a `visor`
> running repeatedly.
>
> The server nodes are running on CentOS 7 inside Oracle VirtualBox VM with
> the same config:
> - 2 vCPUs
> - 3.5GB memory
> - Oracle JDK 2.8.0_121
>
> `default-config.xml` was modified to use non-default multicast group and 1
> backup:
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd";>
>  class="org.apache.ignite.configuration.IgniteConfiguration">
> 
>  class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
> 
>  class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.
> TcpDiscoveryMulticastIpFinder">
>  value="228.10.10.158"/>
> 
> 
> 
> 
> 
>  class="org.apache.ignite.configuration.CacheConfiguration">
> 
> 
> 
> 
> 
>
>
> The `visor` was running repeatedly in one of the nodes by a shell script:
> #!/bin/bash
> IGNITE_HOME=/root/apache-ignite-fabric-1.9.0-bin
> while true
> do
>   ${IGNITE_HOME}/bin/ignitevisorcmd.sh -e="'open
> -cpath=${IGNITE_HOME}/config/default-config.xml;node'"
> done
>
>
> The OOME thrown after the above settings running for 1 day.
> I have put ignite log, gc log, heap dump in `dee657c8.tgz`, which could be
> downloaded from
> https://drive.google.com/drive/folders/0BwY2dxDlRYhBSFJhS0ZWOVBiNk0?
> usp=sharing.
> `507f0201.tgz` contains ignite log and gc log from another node in the
> cluster, for reference just in case.
>
> Running `visor` repeatedly is just to reproduce the OOME more quickly, in
> production we run the `visor` once per 10 minutes to monitor the
> healthiness
> of the cluster.
>
> Questions:
> 1. Anything wrong with the configuration? Anything can be tuned to avoid
> OOME?
> 2. Is there any other built-in tools allow one to monitor the cluster,
> showing no. of server nodes is good enough.
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/OOME-on-2-node-cluster-with-visor-
> running-repeatedly-Ignite-1-9-tp12409.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Apache Flink meets Apache Ignite next week in London

[dromitlabs]

Is it going to be live streamed or maybe recorded to see later?

> On May 4, 2017, at 06:01, Christos Erotocritou  wrote:
> 
> Hello Igniters of London,
> 
> I know this has be shared already, the fellas at Apache Flink will be hosting 
> us this coming Wednesday, 10th of May, where we will dive into Ignite/Flink 
> Integration.
> 
> Speaker Bio:
> 
> Akmal B. Chaudhri is a Technical Evangelist for GridGain, specializing in Big 
> Data, NoSQL and NewSQL database technologies. His current interests also 
> include Apache Spark, Machine Learning, Data Science and how to become a Data 
> Scientist. He has over 25 years experience in IT and has previously held 
> roles as a developer, consultant, product strategist and technical trainer. 
> He has worked for several blue-chip companies, such as Reuters and IBM and 
> also the Big Data startups Hortonworks (Hadoop) and DataStax (Cassandra NoSQL 
> Database). He has regularly presented at many international conferences and 
> served on the program committees for a number of major conferences and 
> workshops. He has published and presented widely and edited or co-edited 10 
> books. He holds a BSc (1st Class Hons.) in Computing and Information Systems, 
> MSc in Business Systems Analysis and Design and a PhD in Computer Science. He 
> is a Member of the British Computer Society (MBCS) and a Chartered IT 
> Professional (CITP).
> 
> Abstract:
> 
> Apache Ignite 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 
> technologies. Ignite as a collection of independent, well-integrated, 
> in-memory components geared to improve performance and scalability of your 
> application. Some of these components include: Advanced Clustering, Data 
> Grid, SQL Grid, Streaming & CEP, Compute Grid, Service Grid, Ignite File 
> System. Ignite also has integrations for accelerating data processing 
> frameworks such as Hadoop and Spark. In addition to its own its own stream 
> processing capability, integrations also exist for JMS, MQTT, Apache Flume, 
> Apache Storm, Apache Kafka, Apache Camel, and Apache Flink, which will be 
> covered in the session.
> 
> RSVP: https://www.meetup.com/Apache-Flink-London-Meetup/events/239663941/
> 
> We hope to see you there!
> 
> Cheers,
> Christos

Re: what does remaps mean in DataStreamerImpl.java

[rishi007bansod]

Hi,
I have attached log file for one ignite node  ignite-b6321e0a.zip

  

Thanks



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/what-does-remaps-mean-in-DataStreamerImpl-java-tp12033p12414.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Continuous Query remote listener misses some events or respond really late

[Sasha Belyak]

Can you share you log files?

2017-05-03 19:05 GMT+07:00 begineer :

> 1) How you use ContinuousQuery: with initialQuery or without? : with
> initial
> query having same predicate
> 2) Did some nodes disconnect when you loose updates? no
> 3) Did you log entries in CQ.localListener? Just to be sure that error in
> CQ
> logic, not in your service logic. :
>  No log entries in remote filter, nor in locallistner
> 4) Can someone update old entries? Maybe they just get into CQ again after
> 4-5 hours by external update?
>--- I tried adding same events just to trigger event again, some time it
> moves ahead(event discovered), some times get stuck at same state.
> Also, CQ detects them at its won after long time mentioned, we dont add any
> event in this case.
> Regards,
> Surinder
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Continuous-Query-remote-listener-misses-some-events-
> or-respond-really-late-tp12338p12387.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: HDP, Hive + Ignite

[Ivan Veselovsky]

Alena, I suppose, incorrect results in your environment may be a consequence
of topology troubles. In any way, to have some stable and reproducible
results you need to have stable Ignite cluster topology. To achieve that I
would recommend the following steps: 
1) kill all the Ignite processes on all the nodes (you may see them with "ps
-ef | grep ignite" in Unix shell).
2) start 1st Ignite node (preferably with "-v" option, and with a dedicated
console, redirecting the output to a file: "./ignite.sh -v ... |& tee
mylogfile " ) -- find first "Topology snapshot" line in the log. It should
say "Topology snapshot [ver=1, servers=1, clients=0, CPUs=..." . If topology
version is different from 1, that means something is wrong, possibly there
is a stale Ignite process this one attempts to join.



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

Re: Grid is in invalid state to perform this operation

[dkarachentsev]

Sam,

Please attach logs from your node.

-Dmitry



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Grid-is-in-invalid-state-to-perform-this-operation-tp12360p12411.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Apache Flink meets Apache Ignite next week in London

[Christos Erotocritou]

Hello Igniters of London,

I know this has be shared already, the fellas at Apache Flink will be hosting 
us this coming Wednesday, 10th of May, where we will dive into Ignite/Flink 
Integration.

Speaker Bio:

Akmal B. Chaudhri is a Technical Evangelist for GridGain, specializing in Big 
Data, NoSQL and NewSQL database technologies. His current interests also 
include Apache Spark, Machine Learning, Data Science and how to become a Data 
Scientist. He has over 25 years experience in IT and has previously held roles 
as a developer, consultant, product strategist and technical trainer. He has 
worked for several blue-chip companies, such as Reuters and IBM and also the 
Big Data startups Hortonworks (Hadoop) and DataStax (Cassandra NoSQL Database). 
He has regularly presented at many international conferences and served on the 
program committees for a number of major conferences and workshops. He has 
published and presented widely and edited or co-edited 10 books. He holds a BSc 
(1st Class Hons.) in Computing and Information Systems, MSc in Business Systems 
Analysis and Design and a PhD in Computer Science. He is a Member of the 
British Computer Society (MBCS) and a Chartered IT Professional (CITP).

Abstract:

Apache Ignite 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 
technologies. Ignite as a collection of independent, well-integrated, in-memory 
components geared to improve performance and scalability of your application. 
Some of these components include: Advanced Clustering, Data Grid, SQL Grid, 
Streaming & CEP, Compute Grid, Service Grid, Ignite File System. Ignite also 
has integrations for accelerating data processing frameworks such as Hadoop and 
Spark. In addition to its own its own stream processing capability, 
integrations also exist for JMS, MQTT, Apache Flume, Apache Storm, Apache 
Kafka, Apache Camel, and Apache Flink, which will be covered in the session.

RSVP: https://www.meetup.com/Apache-Flink-London-Meetup/events/239663941/ 

We hope to see you there!

Cheers,
Christos

OOME on 2-node cluster with visor running repeatedly, Ignite 1.9

[tysli2016]

Got "OutOfMemoryError: Java heap space" with 2-node cluster with a `visor`
running repeatedly.

The server nodes are running on CentOS 7 inside Oracle VirtualBox VM with
the same config:
- 2 vCPUs
- 3.5GB memory
- Oracle JDK 2.8.0_121

`default-config.xml` was modified to use non-default multicast group and 1
backup:
http://www.springframework.org/schema/beans";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="
   http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans.xsd";>



















The `visor` was running repeatedly in one of the nodes by a shell script:
#!/bin/bash
IGNITE_HOME=/root/apache-ignite-fabric-1.9.0-bin
while true
do
  ${IGNITE_HOME}/bin/ignitevisorcmd.sh -e="'open
-cpath=${IGNITE_HOME}/config/default-config.xml;node'"
done


The OOME thrown after the above settings running for 1 day.
I have put ignite log, gc log, heap dump in `dee657c8.tgz`, which could be
downloaded from 
https://drive.google.com/drive/folders/0BwY2dxDlRYhBSFJhS0ZWOVBiNk0?usp=sharing.
`507f0201.tgz` contains ignite log and gc log from another node in the
cluster, for reference just in case.

Running `visor` repeatedly is just to reproduce the OOME more quickly, in
production we run the `visor` once per 10 minutes to monitor the healthiness
of the cluster.

Questions:
1. Anything wrong with the configuration? Anything can be tuned to avoid
OOME?
2. Is there any other built-in tools allow one to monitor the cluster,
showing no. of server nodes is good enough.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/OOME-on-2-node-cluster-with-visor-running-repeatedly-Ignite-1-9-tp12409.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Binary serialization with multiple classloaders

[Sergei Egorov]

Hi!

I have a pluggable system where every plugin has its own classloader.
I want to save an object to the cache, and this object contains some other
objects from other classloaders.

Right now it fails with ClassNotFoundException during unwrapBinary
-> doReadObject -> IgniteUtils.forName

Is it even possible to save objects to the cache with classes from
different classloaders?

Thanks,

Sergei