RE: Continuous Queries with several remote filter on the same cache

[Roman.Koriakov]

Hi Denis,
A big thank you for the answer.
Could you please tell me where can I find this logic in the sources. Which 
package should I look into?

-Original Message-
From: Denis Magda  
Sent: Saturday, June 6, 2020 2:07 AM
To: dev 
Subject: Re: Continuous Queries with several remote filter on the same cache

Hi Roman,

Every continuous query is a unique entity that is processed by servers 
independently. With your example, the server node will execute all 20 filters 
for every cache insert/update operation. The server will notify through local 
listeners only those clients whose remote filters returned 'true'.

-
Denis


On Thu, Jun 4, 2020 at 8:44 PM  wrote:

> Hi Community,
>
> I ask this question here because I haven't found the answer in the 
> documentation.
>
> Could you please clarify how Continuous Queries work? What the 
> behavior of Continuous Queries if we have several clients with 
> different Remote Filters on the same cache? For example, if we have: 
> one server node with cache and we have up to 20 client nodes each of 
> them will execute Continuous Query on the same cache but with 
> different Remote Filters. Will each client get the data according to 
> its remote filter? Or it is supposed to have only one Remote Filter 
> for all clients and every client should filter data in its local event 
> listener?
> I would be grateful if you send some link which describes the behavior 
> of Continuous Queries more thoroughly.
> Best regards,
> Roman
>

Re: Client transactions withLabel

[Guru Stron]

Alex, one more question, can I somehow access the label from the client?

On Fri, 5 Jun 2020 at 01:43, Guru Stron  wrote:

> Thank you Alex !
>
> On Fri, 5 Jun 2020 at 01:23, Alex Plehanov 
> wrote:
>
>> Hello,
>>
>> The transaction label is helpful for diagnostic and exposed to some
>> diagnostic tools (SYS.TRANSACTIONS system view, control.sh commands, JMX
>> TransactionsMXBean, long-running transactions dump in logs), so you should
>> be able to set it by thin client, to view it later by these tools.
>>
>> пт, 5 июн. 2020 г. в 00:49, Guru Stron :
>>
>> > Hi Igniters,
>> >
>> > I'm trying to implement thin client transactions for .NET and was
>> wondering
>> > what is the point of transaction label in thin clients? I've browsed a
>> > little bit through Java implementation and don't see where it is used
>> cause
>> > it seems that it can be only set and there is no public APi to access
>> it.
>> >
>> > Thank you!
>> >
>>
>

[jira] [Created] (IGNITE-13129) .NET: Thin Client auto retry idempotent operations on node failure

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-13129:
---

 Summary: .NET: Thin Client auto retry idempotent operations on 
node failure
 Key: IGNITE-13129
 URL: https://issues.apache.org/jira/browse/IGNITE-13129
 Project: Ignite
  Issue Type: Bug
  Components: platforms, thin client
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.9


.NET Thin Client supports failover, but user code is still responsible for 
catching exceptions and retrying operations.

1. IgniteClientException does not provide a reliable way for the user code to 
understand whether this is a node failure or something else
2. We can introduce RetryPolicy configuration parameter with values like 
`Reads`, `IdempotentWrites`, `All` and retry corresponding operations 
automatically and transparently for the user



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: IGNITE-12702 - Discussion

[kartik somani]

Hello,

I have created a pull request for this issue

: https://github.com/apache/ignite/pull/7882
Can someone review?

Regards,
Kartik

On Mon, Apr 20, 2020 at 11:48 PM kartik somani <
kartiksomani.offic...@gmail.com> wrote:

> Hello Igniters,
>
> I have created pull request for IGNITE-12702. Can someone review this?
> https://github.com/apache/ignite/pull/7663
>
> regards,
> Kartik
>
> On Mon, Mar 23, 2020 at 11:28 PM Denis Magda  wrote:
>
>> Hi Kartik,
>>
>> Actually, it means quite the opposite. You should fill in the release
>> notes
>> field before the ticket is resolved/closed so that a release manager of a
>> next Ignite version adds a proper line to the final release notes with all
>> the changes.
>>
>> As for the docs, it's highly likely you don't need to update Ignite
>> technical documentation (apacheignite.readme.io), thus, the field should
>> be
>> disabled. However, see if APIs (Javadocs) require an update. Hope this
>> helps. Btw, this page elaborates more on our current docs process that is
>> being revisited and improved soon:
>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document
>>
>> -
>> Denis
>>
>>
>> On Sun, Mar 22, 2020 at 6:33 AM kartik somani <
>> kartiksomani.offic...@gmail.com> wrote:
>>
>> > Hello Igniters,
>> >
>> > I want to start working on ticket IGNITE-12702
>> > .  The flags on
>> this
>> > issue are "Docs Required, Release Notes Required". Does this mean I
>> have to
>> > first write/get docs and release notes before starting work on this?
>> >
>> > Regards,
>> > Kartik
>> >
>>
>

Re: Client transactions withLabel

[Alex Plehanov]

Guru,

There are no operations now to request a transaction label from the
server-side. But label can't be modified after transaction creation, so, if
you want to provide to user ability to get a label for a currently running
transaction, you can just store a label on the client-side when you start a
transaction.

вс, 7 июн. 2020 г. в 15:42, Guru Stron :

> Alex, one more question, can I somehow access the label from the client?
>
> On Fri, 5 Jun 2020 at 01:43, Guru Stron  wrote:
>
> > Thank you Alex !
> >
> > On Fri, 5 Jun 2020 at 01:23, Alex Plehanov 
> > wrote:
> >
> >> Hello,
> >>
> >> The transaction label is helpful for diagnostic and exposed to some
> >> diagnostic tools (SYS.TRANSACTIONS system view, control.sh commands, JMX
> >> TransactionsMXBean, long-running transactions dump in logs), so you
> should
> >> be able to set it by thin client, to view it later by these tools.
> >>
> >> пт, 5 июн. 2020 г. в 00:49, Guru Stron :
> >>
> >> > Hi Igniters,
> >> >
> >> > I'm trying to implement thin client transactions for .NET and was
> >> wondering
> >> > what is the point of transaction label in thin clients? I've browsed a
> >> > little bit through Java implementation and don't see where it is used
> >> cause
> >> > it seems that it can be only set and there is no public APi to access
> >> it.
> >> >
> >> > Thank you!
> >> >
> >>
> >
>

[jira] [Created] (IGNITE-13130) Possible memory leak in IgniteH2Indexing

[HubertL (Jira)]

HubertL created IGNITE-13130:


 Summary: Possible memory leak in IgniteH2Indexing
 Key: IGNITE-13130
 URL: https://issues.apache.org/jira/browse/IGNITE-13130
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.8.1
 Environment: Linux
Reporter: HubertL
 Attachments: Capture.PNG

Version 2.8 / 2.8.1 both leaks memory in my case where the cache is used. From 
the leak suspect report the leak can be attributed to the hash "runs" under 
org.apache.ignite.internal.processors.query.RunningQueryManager, which is 
called by IgniteH2Indexing to register queries. It seems some queries got 
registered but never removed (by RunningQueryManager.unregister()).  The 
following is the report from heap dump, both may be caused by the issue:
{quote}One instance of "java.util.concurrent.ConcurrentHashMap" loaded by 
"" occupies 348,001,008 (36.33%) bytes. The instance is 
referenced by org.apache.ignite.internal.processors.query.RunningQueryManager @ 
0x813ae260 , loaded by "org.springframework.boot.loader.LaunchedURLClassLoader 
@ 0x8000". The memory is accumulated in one instance of 
"java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "".

63,364 instances of 
"org.apache.ignite.internal.processors.query.h2.H2ConnectionWrapper", loaded by 
"org.springframework.boot.loader.LaunchedURLClassLoader @ 0x8000" occupy 
331,745,704 (34.63%) bytes. These instances are referenced from one instance of 
"java.util.concurrent.ConcurrentHashMap$Node[]", loaded by ""
{quote}
>From the source the only place where calls to RunningQueryManager.register() 
>which is not guarentee to be followed by unregister() is executeSelect() under 
>IgniteH2Indexing.java, where the call to registerRunningQuery (which in turn 
>calls RunningQueryManager.register()) is not matched by 
>RunningQueryManager.unregister() except where exception occurred (lines 1274 
>and 1333 of IgniteH2Indexing.java).  This is strange since other similar 
>functions (e.g. executeDml() above) puts RunningQueryManager.unregister() in a 
>finally block after calling register().

Is the unmatched call to register (in case of success) deliberate? Could this 
be the source of leak?

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)