Re: Regarding CQ monitoring and alerting

[Ilya Kasnacheev]

Hello!

I guess that CQ may stop working on node reconnect. You may need to handle
EVT_CLIENT_NODE_RECONNECTED and re-register all of your continuous queries.

Regards,
-- 
Ilya Kasnacheev


сб, 1 мая 2021 г. в 11:32, Devakumar J :

> Hi,
>
> We have wide usage of CQ listeners in the application registered from
> client
> nodes. But we observe randomly it stops working, i mean listener not
> notified on cache events, and it requires restarting the client node.
>
> Is there an easy way to alert immediately if CQ stops working?
>
>
> Thanks & Regards,
> Devakumar J
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: IgniteCheckedException: Requesting mapping from grid failed for [platformId=0, typeId=-1220482121]

[Pavel Tupitsyn]

Hi William,

This scenario is supported, but requires a bit of extra care:

1. Class names should match on Java and C# sides, including
namespace/package
Alternatively, enable simple name mapper on both sides so that
namespace/package part is ignored

2. Classes should be registered in Ignite.
Registration happens automatically on first use (e.g. cache.put).
However, if you do cache.put on C# side,
and cache.get on Java side, then Ignite on Java side does not yet know
this class.
You can force class registration by calling
ignite.binary().toBinary(new UserDocument(...))

Similar question on StackOverflow, including demo projects:
https://stackoverflow.com/questions/5387/apache-ignite-2-0-java-and-net-basicbinaryidmapper-no-longer-works

On Tue, May 4, 2021 at 6:46 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> Can you please share some simple reproducer project which highlights the
> issue?
>
> You can put it on github or similar.
>
> Did you enable simple name mapper, btw? The error is what you can expect
> when type names on Java and C# side do not match.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 4 мая 2021 г. в 06:26, William.L :
>
>> Hi,
>>
>> I used C# code (entity object class) to create and write to cache. And I
>> am
>> trying to use Java code to read (corresponding object class) from cache
>> but
>> running into IgniteCheckedException:
>>
>>
>>
>> Is this scenario supported?
>>
>> Here's the C# entity class:
>>
>>
>> Here's the corresponding Java class:
>>
>>
>> I am enable to write to the cache from the Java side and then read from
>> it.
>> The object written from the Java side does not show up in the SQL queries
>> (cache/table was created using the C# entity class).
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>

Help with affinityRun on collocated ignite queue

[ps594]

I am trying to understand the use case of  affinityRun / affinityCall

  
methods of IgniteQueue interface. Even after delving into documentation I
could not understand a good use case why would we want to run jobs on the
collocated queue using affinityRun method of queue interface, since
collocated queues are on the same node why can't I simply write my own
lambda function. Specifically what benefits does the affinityRun offers for
ignite queue (given affinityRun method is not supported for non-collocated
queues)?



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

Re: IgniteCheckedException: Requesting mapping from grid failed for [platformId=0, typeId=-1220482121]

[Ilya Kasnacheev]

Hello!

Can you please share some simple reproducer project which highlights the
issue?

You can put it on github or similar.

Did you enable simple name mapper, btw? The error is what you can expect
when type names on Java and C# side do not match.

Regards,
-- 
Ilya Kasnacheev


вт, 4 мая 2021 г. в 06:26, William.L :

> Hi,
>
> I used C# code (entity object class) to create and write to cache. And I am
> trying to use Java code to read (corresponding object class) from cache but
> running into IgniteCheckedException:
>
>
>
> Is this scenario supported?
>
> Here's the C# entity class:
>
>
> Here's the corresponding Java class:
>
>
> I am enable to write to the cache from the Java side and then read from it.
> The object written from the Java side does not show up in the SQL queries
> (cache/table was created using the C# entity class).
>
>
>
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Too many TCP discovery accepted incoming connections

[Ilya Kasnacheev]

Hello!

I'm not sure. Why?

Regards,
-- 
Ilya Kasnacheev


вс, 2 мая 2021 г. в 11:13, VeenaMithare :

> Hi Ilya,
>
> Could the issue be as mentioned here :
>
>
> http://apache-ignite-users.70518.x6.nabble.com/2-8-1-INFO-org-apache-ignite-spi-communication-tcp-TcpCommunicationSpi-Accepted-incoming-communicatin-tp33854p35224.html
>
> regards,
> Veena.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: [External]Re: Cluster becomes unresponsive if multiple clients join at a time

[Ilya Kasnacheev]

Hello!

I think the relevant ticket is
https://issues.apache.org/jira/browse/IGNITE-9558

It is poorly documented, I believe the prime condition is that client node
should not define any caches in its configuration.

Regards,
-- 
Ilya Kasnacheev


чт, 22 апр. 2021 г. в 16:07, Kamlesh Joshi :

> Thanks Ilya!
>
>
>
> I have observed PME related log entries in latest version as well. Does
> this mean these ‘some conditions’ are not met?
>
>
>
> Can you elaborate on this please ?
>
>
>
> *Thanks and Regards,*
>
> *Kamlesh Joshi*
>
>
>
> *From:* Ilya Kasnacheev 
> *Sent:* 22 April 2021 16:24
> *To:* user@ignite.apache.org
> *Subject:* Re: [External]Re: Cluster becomes unresponsive if multiple
> clients join at a time
>
>
>
> The e-mail below is from an external source. Please do not open
> attachments or click links from an unknown or suspicious origin.
>
> Hello!
>
>
>
> Yes, it should no longer be blocking assuming some conditions are met.
>
>
>
> Regards,
>
> --
>
> Ilya Kasnacheev
>
>
>
>
>
> чт, 22 апр. 2021 г. в 08:26, Kamlesh Joshi :
>
> Hi Ilya,
>
>
>
> Yeah even that’s what we were suspecting, PME triggering might be causing
> issue. We are using 2.7.6 version.
>
> So you are saying, in recent version i.e. 2.10.0 version don’t have
> blocking global PME ?
>
>
>
>
>
> *Thanks and Regards,*
>
> *Kamlesh Joshi*
>
>
>
> *From:* Ilya Kasnacheev 
> *Sent:* 21 April 2021 20:12
> *To:* user@ignite.apache.org
> *Subject:* [External]Re: Cluster becomes unresponsive if multiple clients
> join at a time
>
>
>
> The e-mail below is from an external source. Please do not open
> attachments or click links from an unknown or suspicious origin.
>
> Hello!
>
>
>
> What is the version used? Usually, adding a new thick client would trigger
> a PME (a global blocking operation). In recent versions, they should be
> able to join without exchange.
>
>
>
> You could use flavors of thin client if you need a massive number of those.
>
>
>
> Regards,
>
> --
>
> Ilya Kasnacheev
>
>
>
>
>
> ср, 21 апр. 2021 г. в 14:40, Kamlesh Joshi :
>
> Hi Igniters,
>
>
>
> We have observed that if multiple clients (say around 50) are joining
> within very short span of time, then cluster seemed unresponsive for
> sometime causing entire cluster traffic to go down.
>
> Have anyone encountered this behaviour before? Any parameters to be
> tweaked to avoid this?
>
>
>
> *Thanks and Regards,*
>
> *Kamlesh Joshi*
>
>
>
>
> "*Confidentiality Warning*: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, re-transmission, conversion to hard copy, copying,
> circulation or other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return email and delete this message and any attachments
> from your system.
>
> *Virus Warning:* Although the company has taken reasonable precautions to
> ensure no viruses are present in this email. The company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachment."
>
>
> "*Confidentiality Warning*: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, re-transmission, conversion to hard copy, copying,
> circulation or other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return email and delete this message and any attachments
> from your system.
>
> *Virus Warning:* Although the company has taken reasonable precautions to
> ensure no viruses are present in this email. The company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachment."
>
>
> "*Confidentiality Warning*: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, re-transmission, conversion to hard copy, copying,
> circulation or other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return email and delete this message and any attachments
> from your system.
>
> *Virus Warning:* Although the company has taken reasonable precautions to
> ensure no viruses are present in this email. The company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachment."
>

Re: Ignite 2.10. Performance tests in Azure

[Stephen Darlington]

> otherwise, why would we need specific transactional caches?

Transactional caches rollback the update in the event of failure; atomic caches 
do not.

> Regarding collocated computing:  We have to work in C++ and, since Ignite
> nodes use Java, I don't see how it is possible to send a C++ piece of code
> (like a lambda) so that it gets executed within the node... 

With C++ you’d need to deploy the code in advance.

You’re talking about peer-class loading, but that’s not a necessary part of 
colocated computing.

Regards,
Stephen