Re: Same Affinity For Same Key On All Caches

[Alper Tekinalp]

Hi Val,

We are using fair affinity function because we want to keep data more
balanced among nodes. When I change "new FairAffinityFunction(128)"  with
"new RendezvousAffinityFunction(false, 128)" I could not reproduce the
problem.


On Tue, Feb 28, 2017 at 7:15 AM, vkulichenko 
wrote:

> Andrey,
>
> Is there an explanation for this? If this all is true, it sounds like a bug
> to me, and pretty serious one.
>
> Alper, what is the reason for using fair affinity function? Do you have the
> same behavior with rendezvous (the default one)?
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Same-Affinity-For-Same-Key-On-All-
> Caches-tp10829p10933.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Alper Tekinalp

Software Developer
Evam Streaming Analytics

Atatürk Mah. Turgut Özal Bulv.
Gardenya 5 Plaza K:6 Ataşehir
34758 İSTANBUL

Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
www.evam.com.tr

Re: backup to swap

[Anil]

Hi Val,

I tried to find a way to move backup copies to swap  by looking at
following classes.

GridCacheSwapManager.java
GridCacheMapEntry.java
GridOffHeapProcessor.java
GridOffHeapPartitionedMap.java

I could not find where backup copies are created or would have overlooked.

Thanks

On 28 February 2017 at 09:34, vkulichenko 
wrote:

> Anil,
>
> Can you share what you tried? What exactly doesn't work? Please be more
> specific.
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/backup-to-swap-tp10255p10930.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Lucene like Contains phrase query

[vkulichenko]

Ranjit,

Everything is in memory. Full text index should work for you in my view. Can
you clarify what problems do you have with it?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Lucene-like-Contains-phrase-query-tp10808p10934.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Same Affinity For Same Key On All Caches

[vkulichenko]

Andrey,

Is there an explanation for this? If this all is true, it sounds like a bug
to me, and pretty serious one.

Alper, what is the reason for using fair affinity function? Do you have the
same behavior with rendezvous (the default one)?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Same-Affinity-For-Same-Key-On-All-Caches-tp10829p10933.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Node discovery using ActiveMQ

[vkulichenko]

This implementation was removed and currently there is only one out of the
box, based on TCP. I would highly recommend to use unless there is a very
strong reason to do otherwise.

-Val



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

Re: How to configure MongoDB Client? I'm getting NotSerializableException

[vkulichenko]

Mauricio,

According to exception, you injected CacheStoreSession in a non-transient
field. Making it transient might fix the issue, but generally I would not
recommend this. The purpose of store factory is exactly to avoid
serialization of the store and to create the instance on server side where
it will be used. Store itself very rarely can be serialized.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/How-to-configure-MongoDB-Client-I-m-getting-NotSerializableException-tp10767p10931.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: backup to swap

[vkulichenko]

Anil,

Can you share what you tried? What exactly doesn't work? Please be more
specific.

-Val



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

Re: Configuration Recommendations after ESX maintenance failure

[vkulichenko]

In this case you can try increasing failure detection timeout:
https://apacheignite.readme.io/docs/cluster-config#failure-detection-timeout

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Configuration-Recommendations-after-ESX-maintenance-failure-tp10878p10929.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

upsert example??

[Chris Berry]

Hi,

I am attempting to convert an existing application to use Apache Ignite. 

The current logic does an “upsert”  from a stream of data. And it will be very 
difficult to modify the existing code.

Something like this: 

public void upsertEntry(TKey key, NewInstanceFunctor newInstFunc, 
UpsertFunctor upsertFunc) {
TValue document = getAndNewIfReqd(key, newInstFunc);
document = upsertFunc.modifyForUpsert(document);
getIgniteCache().put(key, document);
}

public TValue getAndNewIfReqd(TKey key, NewInstanceFunctor newInstFunc) 
{
TValue document = getEntry(key);
if (document == null) {
document = newInstFunc.newInstance();
getIgniteCache().put(key, document);
}
return document;
}

So, in pseudo-code

1) get the document from the cache
2) if null, create a document and put it to the cache
3) modify the document
4) put the updated document to the cache
This is clearly inefficient.

I am pretty certain that I can accomplish this using a DataStreamer and a 
StreamTransformer??
I wonder if someone could point me at an example of how to do this??

Thanks,
— Chris 




 

 

cache namespace support

[shawn.du]

Hi,I have a use case like below:I want to store key-value caches in ignite, but each key-value has a namespace. key are unique in a namespace.Each cache entry has the same data type for both key and value.When query, We always query by key and namespace.  sometimes, we query all caches of a namespace or remove all entries in one namespace.I think there are two solutions:#1 create cache for each namespace, like use namespace as the cache name.  using the approach, there may many caches in ignite.  IMO, it is a bit dirty, I meant when using ignitevisor to show caches  you will see many caches. #2 create one cache, each cache entry has namespace,key and value. using (namespace,key) as the cache key.  This solution is clean. but you have to create a static class/complex configuration. also you have to use SQL to query all/remove all  data in a namespace.I think this is a very common use case. Can ignite support it in  lower layer for solution clean and  better performance?welcome your comments.






ThanksShawn

Re: Failure to start a bigger ignite cluster.

[atricuix]

Hi Andrey,

Attached the logs and config as requested.

Regards,
Aswin

igniteConfig.igniteConfig

  
ignite.log
  



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Failure-to-start-a-bigger-ignite-cluster-tp10852p10925.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: getOrCreateCache hang

[Matt Warner]

Something's not right. I'm seeing this as 100% reproducible on two different 
OSes. 

Are you running "mvn package" on both testIgnite1 and testIgnite2 and then 
starting the shaded JARs simultaneously from two different shell windows using 
"java-jar ignite?...-standalone.jar"?

Matt

> On Feb 27, 2017, at 8:58 AM, Nikolai Tikhonov  wrote:
> 
> I was not able reproduce it. Could you share full logs and thread dumps from 
> all nodes?
> 
>> On Mon, Feb 27, 2017 at 7:45 PM, Matt Warner  
>> wrote:
>> Using the test code I sent previously, I changed the ports to be a range but 
>> both clients still deadlock on getOrCreateCache.
>> 
>> Are you able to reproduce this using the test code I sent?
>> 
>> Matt
>> 
>> 
>>> On Mon, Feb 27, 2017 at 3:02 AM, Nikolai Tikhonov  
>>> wrote:
>>> Hi Matt!
>>> 
>>> Try to change ipFinder.setAddresses(Arrays.asList("127.0.0.1:47500")); to 
>>> ipFinder.setAddresses(Arrays.asList("127.0.0.1:47500..47505"));
>>> 
 On Fri, Feb 24, 2017 at 4:00 PM, Matt Warner  
 wrote:
 Hi Nikolai.
 
 I discovered the reason the two applications weren't seeing each other was 
 resolved by adding an explicit port number 
 (Arrays.asList("127.0.0.1:47500")). However, the two still deadlock when 
 running concurrently.
 
 The latest test shows one application blocked in getOrCreateCache, the 
 other blocked in Ignition.start. As soon as I kill the process stuck in 
 Iginition.start the other process continues successfully. I've attached 
 the latest test code.
 
 Any ideas?
 
 Matt
 
> On Wed, Feb 22, 2017 at 10:30 AM, Matt Warner [via Apache Ignite Users] 
> <[hidden email]> wrote:
> One other observation: with the third application acting as just the 
> server, and just one of the clients running, there is no issue. Only when 
> there are multiple clients do I get the deadlock on getOrCreateCache. 
> 
> Matt 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://apache-ignite-users.70518.x6.nabble.com/getOrCreateCache-hang-tp10737p10811.html
> To unsubscribe from getOrCreateCache hang, click here.
> NAML
 
 
  testIgnite.tar.gz (14K) Download Attachment
 
 View this message in context: Re: getOrCreateCache hang
 
 Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>> 
>> 
> 

Re: Missing records Ignite cache size grows

[diopek]

We appreciate any feedback on this issue. Thanks



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Missing-records-Ignite-cache-size-grows-tp10809p10923.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: IGNITE-4029

[David Bidorff]

I will, I'm trying to clean-up a test I built back when I opened the ticket.

I may not be able to post it today, but I'll try to do so tomorrow.



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

Re: IGNITE-4029

[Nikolai Tikhonov]

Hi,

I've left comment to ticket. Could you respond there?

On Mon, Feb 27, 2017 at 8:05 PM, David Bidorff 
wrote:

> Hi,
>
> I have been experiencing an issue on local ContinousQueries (I opened a
> ticket a few monthes ago) for a while and I was wondering if anyone with a
> better knowledge (than me) of the inner workings of the ContinuousQueries
> would have a few minutes to take a look?
>
> Thanks
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/IGNITE-4029-tp10920.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

IGNITE-4029

[David Bidorff]

Hi, 

I have been experiencing an issue on local ContinousQueries (I opened a
ticket a few monthes ago) for a while and I was wondering if anyone with a
better knowledge (than me) of the inner workings of the ContinuousQueries
would have a few minutes to take a look? 

Thanks



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

Re: getOrCreateCache hang

[Nikolai Tikhonov]

I was not able reproduce it. Could you share full logs and thread dumps
from all nodes?

On Mon, Feb 27, 2017 at 7:45 PM, Matt Warner 
wrote:

> Using the test code I sent previously, I changed the ports to be a range
> but both clients still deadlock on getOrCreateCache.
>
> Are you able to reproduce this using the test code I sent?
>
> Matt
>
>
> On Mon, Feb 27, 2017 at 3:02 AM, Nikolai Tikhonov 
> wrote:
>
>> Hi Matt!
>>
>> Try to change ipFinder.setAddresses(Arrays.asList("127.0.0.1:47500")); to
>> ipFinder.setAddresses(Arrays.asList("127.0.0.1:47500..47505"));
>>
>> On Fri, Feb 24, 2017 at 4:00 PM, Matt Warner 
>> wrote:
>>
>>> Hi Nikolai.
>>>
>>> I discovered the reason the two applications weren't seeing each other
>>> was resolved by adding an explicit port number (Arrays.asList("
>>> 127.0.0.1:47500")). However, the two still deadlock when running
>>> concurrently.
>>>
>>> The latest test shows one application blocked in getOrCreateCache, the
>>> other blocked in Ignition.start. As soon as I kill the process stuck in
>>> Iginition.start the other process continues successfully. I've attached the
>>> latest test code.
>>>
>>> Any ideas?
>>>
>>> Matt
>>>
>>> On Wed, Feb 22, 2017 at 10:30 AM, Matt Warner [via Apache Ignite Users]
>>> <[hidden email] >
>>> wrote:
>>>
 One other observation: with the third application acting as just the
 server, and just one of the clients running, there is no issue. Only when
 there are multiple clients do I get the deadlock on getOrCreateCache.

 Matt

 --
 If you reply to this email, your message will be added to the
 discussion below:
 http://apache-ignite-users.70518.x6.nabble.com/getOrCreateCa
 che-hang-tp10737p10811.html
 To unsubscribe from getOrCreateCache hang, click here.
 NAML
 

>>>
>>>
>>> *testIgnite.tar.gz* (14K) Download Attachment
>>> 
>>>
>>> --
>>> View this message in context: Re: getOrCreateCache hang
>>> 
>>>
>>> Sent from the Apache Ignite Users mailing list archive
>>>  at Nabble.com.
>>>
>>
>>
>

Re: Lucene like Contains phrase query

[Ranjit Sahu]

Hi Val,

As per my requirement i have to do  sql like with %text% query. The data i
have is almost 45M+ records. When i try the sql like query i think it does
not use the indexing and i am seeing the query time upto 10+ seconds. This
is in a cluster of 40+ nodes. Anything can be improved on this with some
sort of tuning ?

I tried with @QueryTextField also and thought i will filter out once i get
the results , but i am seeing more problems with this. I am still trying to
figure out this one.  Is the lucene index stays in memory ?

Any help is highly appreciated.

Thanks,
Ranjit

On Fri, Feb 24, 2017 at 3:33 AM, vkulichenko 
wrote:

> These are two different mechanisms. Use @QuerySqlField for SQL queries, or
> @QueryTextField for text (Lucene) queries.
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Lucene-like-Contains-phrase-query-tp10808p10845.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: getOrCreateCache hang

[Matt Warner]

Using the test code I sent previously, I changed the ports to be a range
but both clients still deadlock on getOrCreateCache.

Are you able to reproduce this using the test code I sent?

Matt

On Mon, Feb 27, 2017 at 3:02 AM, Nikolai Tikhonov 
wrote:

> Hi Matt!
>
> Try to change ipFinder.setAddresses(Arrays.asList("127.0.0.1:47500")); to
> ipFinder.setAddresses(Arrays.asList("127.0.0.1:47500..47505"));
>
> On Fri, Feb 24, 2017 at 4:00 PM, Matt Warner 
> wrote:
>
>> Hi Nikolai.
>>
>> I discovered the reason the two applications weren't seeing each other
>> was resolved by adding an explicit port number (Arrays.asList("
>> 127.0.0.1:47500")). However, the two still deadlock when running
>> concurrently.
>>
>> The latest test shows one application blocked in getOrCreateCache, the
>> other blocked in Ignition.start. As soon as I kill the process stuck in
>> Iginition.start the other process continues successfully. I've attached the
>> latest test code.
>>
>> Any ideas?
>>
>> Matt
>>
>> On Wed, Feb 22, 2017 at 10:30 AM, Matt Warner [via Apache Ignite Users] 
>> <[hidden
>> email] > wrote:
>>
>>> One other observation: with the third application acting as just the
>>> server, and just one of the clients running, there is no issue. Only when
>>> there are multiple clients do I get the deadlock on getOrCreateCache.
>>>
>>> Matt
>>>
>>> --
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>> http://apache-ignite-users.70518.x6.nabble.com/getOrCreateCa
>>> che-hang-tp10737p10811.html
>>> To unsubscribe from getOrCreateCache hang, click here.
>>> NAML
>>> 
>>>
>>
>>
>> *testIgnite.tar.gz* (14K) Download Attachment
>> 
>>
>> --
>> View this message in context: Re: getOrCreateCache hang
>> 
>>
>> Sent from the Apache Ignite Users mailing list archive
>>  at Nabble.com.
>>
>
>

Re: How to configure MongoDB Client? I'm getting NotSerializableException

[Mauricio Arroqui]

Val,

Thanks for you advice. I changed what you suggest and the exception
disappears, here's the piece of the final configuration:
...

  

  
  
...

But I don't understand why? My first SimulationCacheMongoStore has the non
serialized property MongoClient, but the second hasn't, so.. why the
java.io.NotSerializableException? 

Thanks for your patience.
Mauricio 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/How-to-configure-MongoDB-Client-I-m-getting-NotSerializableException-tp10767p10914.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: backup to swap

[Anil]

Hi Val,

I spent some time on figure out a way to move all backup copies to swap and
no luck.

Could you please help me out in achieving this ? Thanks.

Thanks.

On 28 January 2017 at 02:26, vkulichenko 
wrote:

> Anil,
>
> What exactly does not exist? There is a swap space implementation out of
> the
> box, and you only need to implement eviction policy.
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/backup-to-swap-tp10255p10293.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Same Affinity For Same Key On All Caches

[Andrey Mashenkov]

Hi Alper,

This is what I mean about primary\backup nodes for same key. It looks like
there is no guarantee what node will be primary for same key for different
caches.

Would you please check mapKeyToPrimaryAndBackups() method? You should get
same result for same key on different caches with same affinity function.


On Mon, Feb 27, 2017 at 6:44 PM, Alper Tekinalp  wrote:

> Hi.
>
> As I investigated the issue occurs when different nodes creates the
> caches.
>
> Say I have 2 nodes node1 and node2 and 2 caches cache1 and cache2. If I
> create cache1 on node1 and create cache2 on node2 with same
> FairAffinityFunction with same partition size, keys can map different nodes
> on different caches.
>
> You can find my test code and resuts as attachment.
>
> So is that a bug? Is there a way to force same mappings althought caches
> created on different nodes?
>
>
> On Fri, Feb 24, 2017 at 9:37 AM, Alper Tekinalp  wrote:
>
>> Hi.
>>
>> Thanks for your comments. Let me investigate the issue deeper.
>>
>> Regards.
>>
>> On Thu, Feb 23, 2017 at 11:00 PM, Dmitriy Setrakyan <
>> dsetrak...@apache.org> wrote:
>>
>>> If you use the same (or default) configuration for the affinity, then
>>> the same key in different caches will always end up on the same node. This
>>> is guaranteed.
>>>
>>> D.
>>>
>>> On Thu, Feb 23, 2017 at 8:09 AM, Andrey Mashenkov <
>>> andrey.mashen...@gmail.com> wrote:
>>>
 Val,

 Yes, with same affinity function entries with same key should be saved
 in
 same nodes.
 As far as I know, primary node is assinged automatically by Ignite. And
 I'm
 not sure that
 there is a guarantee that 2 entries from different caches with same key
 will have same primary and backup nodes.
 So, get operation for 1-st key can be local while get() for 2-nd key
 will
 be remote.


 On Thu, Feb 23, 2017 at 6:49 PM, Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:

 > Actually, this should work this way out of the box, as long as the
 same
 > affinity function is configured for all caches (that's true for
 default
 > settings).
 >
 > Andrey, am I missing something?
 >
 > -Val
 >
 > On Thu, Feb 23, 2017 at 7:02 AM, Andrey Mashenkov <
 > andrey.mashen...@gmail.com> wrote:
 >
 > > Hi Alper,
 > >
 > > You can implement you own affinityFunction to achieve this.
 > > In AF you should implement 2 mappings: key to partition and
 partition to
 > > node.
 > >
 > > First mapping looks trivial, but second doesn't.
 > > Even if you will lucky to do it, there is no way to choose what
 node wil
 > be
 > > primary and what will be backup for a partition,
 > > that can be an issue.
 > >
 > >
 > > On Thu, Feb 23, 2017 at 10:44 AM, Alper Tekinalp 
 wrote:
 > >
 > > > Hi all.
 > > >
 > > > Is it possible to configures affinities in a way that partition
 for
 > same
 > > > key will be on same node? So calling
 > > > ignite.affinity(CACHE).mapKeyToNode(KEY).id() with same key for
 any
 > > cache
 > > > will return same node id. Is that possible with a configuration
 etc.?
 > > >
 > > > --
 > > > Alper Tekinalp
 > > >
 > > > Software Developer
 > > > Evam Streaming Analytics
 > > >
 > > > Atatürk Mah. Turgut Özal Bulv.
 > > > Gardenya 5 Plaza K:6 Ataşehir
 > > > 34758 İSTANBUL
 > > >
 > > > Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
 > > > www.evam.com.tr
 > > > 
 > > >
 > >
 > >
 > >
 > > --
 > > Best regards,
 > > Andrey V. Mashenkov
 > >
 >



 --
 Best regards,
 Andrey V. Mashenkov

>>>
>>>
>>
>>
>> --
>> Alper Tekinalp
>>
>> Software Developer
>> Evam Streaming Analytics
>>
>> Atatürk Mah. Turgut Özal Bulv.
>> Gardenya 5 Plaza K:6 Ataşehir
>> 34758 İSTANBUL
>>
>> Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
>> www.evam.com.tr
>> 
>>
>
>
>
> --
> Alper Tekinalp
>
> Software Developer
> Evam Streaming Analytics
>
> Atatürk Mah. Turgut Özal Bulv.
> Gardenya 5 Plaza K:6 Ataşehir
> 34758 İSTANBUL
>
> Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
> www.evam.com.tr
> 
>

Re: Same Affinity For Same Key On All Caches

[Alper Tekinalp]

Hi.

As I investigated the issue occurs when different nodes creates the caches.

Say I have 2 nodes node1 and node2 and 2 caches cache1 and cache2. If I
create cache1 on node1 and create cache2 on node2 with same
FairAffinityFunction with same partition size, keys can map different nodes
on different caches.

You can find my test code and resuts as attachment.

So is that a bug? Is there a way to force same mappings althought caches
created on different nodes?


On Fri, Feb 24, 2017 at 9:37 AM, Alper Tekinalp  wrote:

> Hi.
>
> Thanks for your comments. Let me investigate the issue deeper.
>
> Regards.
>
> On Thu, Feb 23, 2017 at 11:00 PM, Dmitriy Setrakyan  > wrote:
>
>> If you use the same (or default) configuration for the affinity, then the
>> same key in different caches will always end up on the same node. This is
>> guaranteed.
>>
>> D.
>>
>> On Thu, Feb 23, 2017 at 8:09 AM, Andrey Mashenkov <
>> andrey.mashen...@gmail.com> wrote:
>>
>>> Val,
>>>
>>> Yes, with same affinity function entries with same key should be saved in
>>> same nodes.
>>> As far as I know, primary node is assinged automatically by Ignite. And
>>> I'm
>>> not sure that
>>> there is a guarantee that 2 entries from different caches with same key
>>> will have same primary and backup nodes.
>>> So, get operation for 1-st key can be local while get() for 2-nd key will
>>> be remote.
>>>
>>>
>>> On Thu, Feb 23, 2017 at 6:49 PM, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>>
>>> > Actually, this should work this way out of the box, as long as the same
>>> > affinity function is configured for all caches (that's true for default
>>> > settings).
>>> >
>>> > Andrey, am I missing something?
>>> >
>>> > -Val
>>> >
>>> > On Thu, Feb 23, 2017 at 7:02 AM, Andrey Mashenkov <
>>> > andrey.mashen...@gmail.com> wrote:
>>> >
>>> > > Hi Alper,
>>> > >
>>> > > You can implement you own affinityFunction to achieve this.
>>> > > In AF you should implement 2 mappings: key to partition and
>>> partition to
>>> > > node.
>>> > >
>>> > > First mapping looks trivial, but second doesn't.
>>> > > Even if you will lucky to do it, there is no way to choose what node
>>> wil
>>> > be
>>> > > primary and what will be backup for a partition,
>>> > > that can be an issue.
>>> > >
>>> > >
>>> > > On Thu, Feb 23, 2017 at 10:44 AM, Alper Tekinalp 
>>> wrote:
>>> > >
>>> > > > Hi all.
>>> > > >
>>> > > > Is it possible to configures affinities in a way that partition for
>>> > same
>>> > > > key will be on same node? So calling
>>> > > > ignite.affinity(CACHE).mapKeyToNode(KEY).id() with same key for
>>> any
>>> > > cache
>>> > > > will return same node id. Is that possible with a configuration
>>> etc.?
>>> > > >
>>> > > > --
>>> > > > Alper Tekinalp
>>> > > >
>>> > > > Software Developer
>>> > > > Evam Streaming Analytics
>>> > > >
>>> > > > Atatürk Mah. Turgut Özal Bulv.
>>> > > > Gardenya 5 Plaza K:6 Ataşehir
>>> > > > 34758 İSTANBUL
>>> > > >
>>> > > > Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
>>> > > > www.evam.com.tr
>>> > > > 
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Best regards,
>>> > > Andrey V. Mashenkov
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Andrey V. Mashenkov
>>>
>>
>>
>
>
> --
> Alper Tekinalp
>
> Software Developer
> Evam Streaming Analytics
>
> Atatürk Mah. Turgut Özal Bulv.
> Gardenya 5 Plaza K:6 Ataşehir
> 34758 İSTANBUL
>
> Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
> www.evam.com.tr
> 
>



-- 
Alper Tekinalp

Software Developer
Evam Streaming Analytics

Atatürk Mah. Turgut Özal Bulv.
Gardenya 5 Plaza K:6 Ataşehir
34758 İSTANBUL

Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
www.evam.com.tr

$ java -Xms1G -Xmx1G -cp "untitled2.jar:EvamEngine_4.3.15/corelib/*" Main 1 10
[18:31:52]__  
[18:31:52]   /  _/ ___/ |/ /  _/_  __/ __/
[18:31:52]  _/ // (7 7// /  / / / _/
[18:31:52] /___/\___/_/|_/___/ /_/ /___/
[18:31:52]
[18:31:52] ver. 1.8.3#20170215-sha1:0a000d89
[18:31:52] 2017 Copyright(C) Apache Software Foundation
[18:31:52]
[18:31:52] Ignite documentation: http://ignite.apache.org
[18:31:52]
[18:31:52] Quiet mode.
[18:31:52]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or 
"-v" to ignite.{sh|bat}
[18:31:52]
[18:31:52] OS: Mac OS X 10.12.2 x86_64
[18:31:52] VM information: Java(TM) SE Runtime Environment 1.8.0_77-b03 Oracle 
Corporation Java HotSpot(TM) 64-Bit Server VM 25.77-b03
[18:31:53] Configured plugins:
[18:31:53]   ^-- None
[18:31:53]
[18:31:54] 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.
[18:31:54] Security status [authentication=off, tls/ssl=off]
[18:31:56] Performance suggestions for grid  (fix if possible)
[18:31:56] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[18:31:56]   ^-- Disable grid events (rem

Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[bintisepaha]

Andrey, thanks for getting back.
The long pause is between 2 different threads, so isn't that normal?

Also the 9990 ms and 10 ms used earlier for some previous step in the tn, is
this how ignite breaks out the time? we have always seen the timeouts for
the value in ms that we set in our code. Also the stack trace does not come
from our code which it usually does on genuine timeouts that do not leave
the key locked.

We are trying 1.8 in UAT environment and will release to production soon.
Unfortunately this issue does not happen in UAT and we have no way of
reproducing it.

Is there any way we can force release a locked key without restarting the
whole cluster?

Thanks,
Binti





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Pessimistic-TXN-did-not-release-lock-on-a-key-all-subsequent-txns-failed-tp10536p10910.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Node discovery using ActiveMQ

[jpmoore40]

Thank you - I'm aware they are different products now but didn't Ignite
evolve from GridGain originally? The GridGain version we have been using was
an open source version dating back to 2009, whereas I think Ignite has only
came about as a separate product in 2014/5. I thought it may have had a
similar feature.

Thanks



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

Re: Parallel Queries

[Andrey Mashenkov]

Hi Anil,

Sure, you can run as many queries as you want.
Could you please clarify the use case?

On Mon, Feb 27, 2017 at 3:42 PM, Anil  wrote:

> Hi,
>
> Can single ignite client handle number of queries at time ?
>
> I have two clients and only i see two queries are executed parallel when i
> perform jmeter test.
>
> Am I missing anything here ? Please advice.
>
> Thanks.
>
>
>


-- 
Best regards,
Andrey V. Mashenkov

Re: Node discovery using ActiveMQ

[Andrey Mashenkov]

Hi,

Ignite and GridGain are different products.
It looks like GridJmsDiscoverySpi was never part of Ignite.

On Mon, Feb 27, 2017 at 3:21 PM, jpmoore40 
wrote:

> Hi,
>
> I'm migrating a very old GridGain installation to Ignite. We used to use
> ActiveMQ for node discovery using GridJmsDiscoverySpi but there doesn't
> seem
> to be a similar option with Ignite. Am I missing something or is this no
> longer possible?
>
> Thanks
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Node-discovery-using-ActiveMQ-tp10903.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Best regards,
Andrey V. Mashenkov

Parallel Queries

[Anil]

Hi,

Can single ignite client handle number of queries at time ?

I have two clients and only i see two queries are executed parallel when i
perform jmeter test.

Am I missing anything here ? Please advice.

Thanks.

Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[Andrey Gura]

I still don't see any cause of timeout in logs. But there is one
suspiciously long pause between two log records:

[INFO ] 2017-02-22 15:45:52.807 [pub-#1%DataGridServer-Production%]
OrderHolderSaveRunnable - Begin TXN for orderHolder save, saving 1
orders
[ERROR] 2017-02-22 15:46:01.406 [pub-#2%DataGridServer-Production%]
OrderHolderSaveRunnable - javax.cache.CacheException: class
org.apache.ignite.transactions.TransactionTimeoutException: Cache
transaction time
d out (was rolled back automatically)

It would be great to get thread dumps during this pause.

Did you try Apache Ignite 1.8 release?


On Thu, Feb 23, 2017 at 5:03 PM, bintisepaha  wrote:
> This is the actual error that looks like it is not coming from our code
>
> 109714 Feb 22, 2017 3:46:17 PM org.apache.ignite.logger.java.JavaLogger
> error
> 109715 SEVERE:  Failed to acquire lock for request:
> GridNearLockRequest [topVer=AffinityTopologyVersion [topVer=3153,
> minorTopVer=32], miniId=acdced25a51-c5e64ee6-1079-4b90-bb7b-5ec14032a859,
> implicitTx=f   alse, implicitSingleTx=false, onePhaseCommit=false,
> dhtVers=[null], subjId=f6663b00-24fc-4515-91ac-20c3b47d90ec, taskNameHash=0,
> hasTransforms=false, syncCommit=true, accessTtl=-1, retVal=true,
> firstClientRe   q=false, filter=null, super=GridDistributedLockRequest
> [nodeId=f6663b00-24fc-4515-91ac-20c3b47d90ec, nearXidVer=GridCacheVersion
> [topVer=98913254, time=1487796367155, order=1487785731866, nodeOrder=7],
> threa   dId=57, futId=8cdced25a51-c5e64ee6-1079-4b90-bb7b-5ec14032a859,
> timeout=9990, isInTx=true, isInvalidate=false, isRead=true,
> isolation=REPEATABLE_READ, retVals=[true], txSize=0, flags=0, keysCnt=1,
> super=Grid   DistributedBaseMessage [ver=GridCacheVersion
> [topVer=98913254, time=1487796367155, order=1487785731866, nodeOrder=7],
> committedVers=null, rolledbackVers=null, cnt=0, super=GridCacheMessage
> [msgId=2688455, de   pInfo=null, err=null, skipPrepare=false,
> cacheId=812449097, cacheId=812449097
> 109716 class
> org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException:
> Failed to acquire lock within provided timeout for transaction
> [timeout=9990, tx=org.apache.ignite.internal.processors.cache.dis
> tributed.dht.GridDhtTxLocalAdapter$1@7f2a8c8a]
> 109717 at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:3924)
> 109718 at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:3874)
> 109719 at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$2.applyx(GridEmbeddedFuture.java:91)
> 109720 at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:297)
> 109721 at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:290)
> 109722 at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:263)
> 109723 at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:251)
> 109724 at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:381)
> 109725 at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:347)
> 109726 at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:752)
> 109727 at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.access$600(GridDhtLockFuture.java:79)
> 109728 at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture$LockTimeoutObject.onTimeout(GridDhtLockFuture.java:1116)
> 109729 at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:159)
> 109730 at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 109731 at java.lang.Thread.run(Thread.java:745)
> 109732
> 109733 Feb 22, 2017 3:46:17 PM org.apache.ignite.logger.java.JavaLogger
> error
> 109716 class
> org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException:
> Failed to acquire lock within provided timeout for transaction
> [timeout=9990, tx=org.apache.ignite.internal.processors.cache.dis
> tributed.dht.GridDhtTxLocalAdapter$1@7f2a8c8a]
> 109717 at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:3924)
> 109718 at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:3874)
> 109719 at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$2.applyx(GridEmbeddedFuture.java:91)
> 109720 at
> org.apache.ignite.internal.

Re: Node fauliure

[Anil]

Hi Andrey,

thanks for looking into it. could you please share more details around the
bug ? this helps us.

Thanks.

On 27 February 2017 at 17:27, Andrey Mashenkov 
wrote:

> Thanks, It was very helpful.
>
> Seems, Offheap with swap enabled funcionality has a bug.
>
> On Mon, Feb 27, 2017 at 2:46 PM, Anil  wrote:
>
>> Hi Andrey,
>>
>> I set both off heap cache and swap enabled = true.
>>
>> Thanks
>>
>> On 27 February 2017 at 16:48, Andrey Mashenkov <
>> andrey.mashen...@gmail.com> wrote:
>>
>>> Hi Anil,
>>>
>>> One more question. Did you use Offheap cache or may be SwapEnabled=true
>>> is set?
>>>
>>>
>>> On Sat, Feb 25, 2017 at 5:14 AM, Anil  wrote:
>>>
 Thank you Andrey.

>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Andrey V. Mashenkov
>>>
>>
>>
>

Node discovery using ActiveMQ

[jpmoore40]

Hi,

I'm migrating a very old GridGain installation to Ignite. We used to use
ActiveMQ for node discovery using GridJmsDiscoverySpi but there doesn't seem
to be a similar option with Ignite. Am I missing something or is this no
longer possible?

Thanks 



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

Re: IGNITE-2680

[Anil]

Hi Val,

I have added the comment to the jira. Could you please take a look ? thanks.

Thanks.

Re: Node fauliure

[Andrey Mashenkov]

Thanks, It was very helpful.

Seems, Offheap with swap enabled funcionality has a bug.

On Mon, Feb 27, 2017 at 2:46 PM, Anil  wrote:

> Hi Andrey,
>
> I set both off heap cache and swap enabled = true.
>
> Thanks
>
> On 27 February 2017 at 16:48, Andrey Mashenkov  > wrote:
>
>> Hi Anil,
>>
>> One more question. Did you use Offheap cache or may be SwapEnabled=true
>> is set?
>>
>>
>> On Sat, Feb 25, 2017 at 5:14 AM, Anil  wrote:
>>
>>> Thank you Andrey.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Andrey V. Mashenkov
>>
>
>

Re: Node fauliure

[Anil]

Hi Andrey,

I set both off heap cache and swap enabled = true.

Thanks

On 27 February 2017 at 16:48, Andrey Mashenkov 
wrote:

> Hi Anil,
>
> One more question. Did you use Offheap cache or may be SwapEnabled=true is
> set?
>
>
> On Sat, Feb 25, 2017 at 5:14 AM, Anil  wrote:
>
>> Thank you Andrey.
>>
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: Node fauliure

[Andrey Mashenkov]

Hi Anil,

One more question. Did you use Offheap cache or may be SwapEnabled=true is
set?


On Sat, Feb 25, 2017 at 5:14 AM, Anil  wrote:

> Thank you Andrey.
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[Andrey Gura]

Hi

Timeout with value 9990 is ok because it is just the next step of
transaction and 10 ms was spend already for the previous steps of
transactions.

On Thu, Feb 23, 2017 at 8:48 AM, bintisepaha  wrote:
> Andrey,
>
> I finally have an error that might help. this happened again in production
> today for us.
> Ignite-Console-3.zip
> 
>
> This is the last update that threw an error, after this error every update
> just times out.
>
> The timeout=9990 in this error, none of our transactions have this timeout.
> Do you think this is an ignite bug? If you look at the stack trace, this is
> not happening due to our code.
>
> Although there is an error on marshaling. How can we further narrow it down?
>
> Thanks,
> Binti
>
>
>
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Pessimistic-TXN-did-not-release-lock-on-a-key-all-subsequent-txns-failed-tp10536p10828.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: getOrCreateCache hang

[Nikolai Tikhonov]

Hi Matt!

Try to change ipFinder.setAddresses(Arrays.asList("127.0.0.1:47500")); to
ipFinder.setAddresses(Arrays.asList("127.0.0.1:47500..47505"));

On Fri, Feb 24, 2017 at 4:00 PM, Matt Warner 
wrote:

> Hi Nikolai.
>
> I discovered the reason the two applications weren't seeing each other was
> resolved by adding an explicit port number (Arrays.asList("127.0.0.1:47500")).
> However, the two still deadlock when running concurrently.
>
> The latest test shows one application blocked in getOrCreateCache, the
> other blocked in Ignition.start. As soon as I kill the process stuck in
> Iginition.start the other process continues successfully. I've attached the
> latest test code.
>
> Any ideas?
>
> Matt
>
> On Wed, Feb 22, 2017 at 10:30 AM, Matt Warner [via Apache Ignite Users] 
> <[hidden
> email] > wrote:
>
>> One other observation: with the third application acting as just the
>> server, and just one of the clients running, there is no issue. Only when
>> there are multiple clients do I get the deadlock on getOrCreateCache.
>>
>> Matt
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://apache-ignite-users.70518.x6.nabble.com/getOrCreateCa
>> che-hang-tp10737p10811.html
>> To unsubscribe from getOrCreateCache hang, click here.
>> NAML
>> 
>>
>
>
> *testIgnite.tar.gz* (14K) Download Attachment
> 
>
> --
> View this message in context: Re: getOrCreateCache hang
> 
>
> Sent from the Apache Ignite Users mailing list archive
>  at Nabble.com.
>

Re: How to submit job to Ignite Yarn application

[Nikolai Tikhonov]

Hi,

You can join Ignite client node to cluster (which was deployed to yarn) and
run any jobs/task. For it you need to configure VmIpFinder for client. See
the follwing example:





IP_ADDRESS_YARN_NODE:47500..47509
IP_ADDRESS_YARN_NODE1:47500..47509
IP_ADDRESS_YARN_NODE2:47500..47509







On Fri, Feb 10, 2017 at 9:49 PM, dpolacza  wrote:

> Hi,
> I have submitted ignite as yarn application like it is described in chapter
> "yarn-deployment".
> In this case Ignite should schedule resources in resourcemanager and
> install
> ignite nodes automatically
> But how to send job to this application?
> How "Configuration" object should be defined?
>
> Regards
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/How-to-submit-job-to-Ignite-Yarn-
> application-tp10550.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>