You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Raymond Wilson <ra...@trimble.com> on 2022/10/02 09:24:28 UTC
Ignite Async API call continutation behaviour
Way back in Ignite 2.8 we ran into an issue with continuations from Ignite
Async method calls that meant our code could continue to run on an Ignite
striped thread pool thread, with sometimes bad results.
At the time the pattern suggested was to use a .ContinueWith()
continuation, like this:
await _cache.PutAsync(key, value).ContinueWith(t => { },
CancellationToken.None, TaskContinuationOptions.None,
TaskScheduler.Default);
to ensure that the continuation after the PutAsync occurred on a .Net
thread pool thread. This worked with no further bad results.
A little while ago we upgraded to 2.13, and I note in this link (
https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations)
that the default behaviour has been changed.
My reading of this is that the example above can now be changed to:
await _cache.PutAsync(key, value);
with the continuation occurring on a .Net threadpool thread by default. Is
that correct?
This will allow us to remove the (quite a few) .ContinueWith() statements
which do add a layer of overhead on async calls.
Thanks,
Raymond.
--
<http://www.trimble.com/>
Raymond Wilson
Trimble Distinguished Engineer, Civil Construction Software (CCS)
11 Birmingham Drive | Christchurch, New Zealand
raymond_wilson@trimble.com
<https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
Re: Ignite Async API call continutation behaviour
Posted by Raymond Wilson <ra...@trimble.com>.
Thanks Pavel! :)
On Mon, Oct 3, 2022 at 6:50 PM Pavel Tupitsyn <pt...@apache.org> wrote:
> Hi Raymond,
>
> Yes, you can remove those ContinueWith() calls. Default behavior is now
> safe.
>
> On Mon, Oct 3, 2022 at 2:25 AM Raymond Wilson <ra...@trimble.com>
> wrote:
>
>> Jay,
>>
>> Thanks for the confirmation and the heads up regarding transactions.
>>
>> Raymond.
>>
>> On Mon, Oct 3, 2022 at 12:18 AM <ja...@gmx.de> wrote:
>>
>>> Hi Raymond,
>>>
>>>
>>>
>>> That’s what we did and it works perfectly.
>>>
>>>
>>>
>>> Please note however that async/await currently does not work inside
>>> transactions, should that concern you.
>>>
>>>
>>>
>>> Pavel wrote in Jan 2022:
>>>
>>> “
>>>
>>> > Is using async/await supported for optimistic serializable
>>> transactions (and we’re doing something wrong)
>>>
>>> > or are transactional operations currently supposed to be blocking in
>>> .NET?
>>>
>>>
>>>
>>> Short answer - yes, please use synchronous cache APIs when working with
>>> transactions.
>>>
>>>
>>>
>>> A transaction is owned by a specific thread. Transactional API calls
>>> should be done from this thread, and `Commit` should be called from this
>>> thread.
>>>
>>> When doing `await`, we most likely end up on another thread and lose
>>> transaction context.
>>>
>>>
>>>
>>> There were plans to make transactions work across multiple threads, but
>>> the ticket looks abandoned:
>>>
>>> https://issues.apache.org/jira/browse/IGNITE-4887
>>>
>>> “
>>>
>>>
>>>
>>> Issue 4887 is currently still open as I see it.
>>>
>>>
>>>
>>> Best Regard
>>>
>>> Jay
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Raymond Wilson <ra...@trimble.com>
>>> *Sent:* Sunday, 2 October 2022 11:24
>>> *To:* user <us...@ignite.apache.org>
>>> *Subject:* Ignite Async API call continutation behaviour
>>>
>>>
>>>
>>> Way back in Ignite 2.8 we ran into an issue with continuations from
>>> Ignite Async method calls that meant our code could continue to run on an
>>> Ignite striped thread pool thread, with sometimes bad results.
>>>
>>>
>>>
>>> At the time the pattern suggested was to use a .ContinueWith()
>>> continuation, like this:
>>>
>>>
>>>
>>> await _cache.PutAsync(key, value).ContinueWith(t => { },
>>> CancellationToken.None, TaskContinuationOptions.None,
>>> TaskScheduler.Default);
>>>
>>>
>>>
>>> to ensure that the continuation after the PutAsync occurred on a .Net
>>> thread pool thread. This worked with no further bad results.
>>>
>>>
>>>
>>> A little while ago we upgraded to 2.13, and I note in this link (
>>> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations)
>>> that the default behaviour has been changed.
>>>
>>>
>>>
>>> My reading of this is that the example above can now be changed to:
>>>
>>>
>>>
>>> await _cache.PutAsync(key, value);
>>>
>>>
>>>
>>> with the continuation occurring on a .Net threadpool thread by default.
>>> Is that correct?
>>>
>>>
>>>
>>> This will allow us to remove the (quite a few) .ContinueWith()
>>> statements which do add a layer of overhead on async calls.
>>>
>>>
>>>
>>> Thanks,
>>> Raymond.
>>>
>>>
>>>
>>> --
>>>
>>> <http://www.trimble.com/>
>>>
>>> *Raymond Wilson*Trimble Distinguished Engineer, Civil Construction
>>> Software (CCS)
>>> 11 Birmingham Drive | Christchurch, New Zealand
>>> raymond_wilson@trimble.com
>>>
>>>
>>> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
>>>
>>>
>>>
>>
>>
>> --
>> <http://www.trimble.com/>
>> Raymond Wilson
>> Trimble Distinguished Engineer, Civil Construction Software (CCS)
>> 11 Birmingham Drive | Christchurch, New Zealand
>> raymond_wilson@trimble.com
>>
>>
>> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
>>
>
--
<http://www.trimble.com/>
Raymond Wilson
Trimble Distinguished Engineer, Civil Construction Software (CCS)
11 Birmingham Drive | Christchurch, New Zealand
raymond_wilson@trimble.com
<https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
Re: Ignite Async API call continutation behaviour
Posted by Pavel Tupitsyn <pt...@apache.org>.
Hi Raymond,
Yes, you can remove those ContinueWith() calls. Default behavior is now
safe.
On Mon, Oct 3, 2022 at 2:25 AM Raymond Wilson <ra...@trimble.com>
wrote:
> Jay,
>
> Thanks for the confirmation and the heads up regarding transactions.
>
> Raymond.
>
> On Mon, Oct 3, 2022 at 12:18 AM <ja...@gmx.de> wrote:
>
>> Hi Raymond,
>>
>>
>>
>> That’s what we did and it works perfectly.
>>
>>
>>
>> Please note however that async/await currently does not work inside
>> transactions, should that concern you.
>>
>>
>>
>> Pavel wrote in Jan 2022:
>>
>> “
>>
>> > Is using async/await supported for optimistic serializable transactions
>> (and we’re doing something wrong)
>>
>> > or are transactional operations currently supposed to be blocking in
>> .NET?
>>
>>
>>
>> Short answer - yes, please use synchronous cache APIs when working with
>> transactions.
>>
>>
>>
>> A transaction is owned by a specific thread. Transactional API calls
>> should be done from this thread, and `Commit` should be called from this
>> thread.
>>
>> When doing `await`, we most likely end up on another thread and lose
>> transaction context.
>>
>>
>>
>> There were plans to make transactions work across multiple threads, but
>> the ticket looks abandoned:
>>
>> https://issues.apache.org/jira/browse/IGNITE-4887
>>
>> “
>>
>>
>>
>> Issue 4887 is currently still open as I see it.
>>
>>
>>
>> Best Regard
>>
>> Jay
>>
>>
>>
>>
>>
>>
>>
>> *From:* Raymond Wilson <ra...@trimble.com>
>> *Sent:* Sunday, 2 October 2022 11:24
>> *To:* user <us...@ignite.apache.org>
>> *Subject:* Ignite Async API call continutation behaviour
>>
>>
>>
>> Way back in Ignite 2.8 we ran into an issue with continuations from
>> Ignite Async method calls that meant our code could continue to run on an
>> Ignite striped thread pool thread, with sometimes bad results.
>>
>>
>>
>> At the time the pattern suggested was to use a .ContinueWith()
>> continuation, like this:
>>
>>
>>
>> await _cache.PutAsync(key, value).ContinueWith(t => { },
>> CancellationToken.None, TaskContinuationOptions.None,
>> TaskScheduler.Default);
>>
>>
>>
>> to ensure that the continuation after the PutAsync occurred on a .Net
>> thread pool thread. This worked with no further bad results.
>>
>>
>>
>> A little while ago we upgraded to 2.13, and I note in this link (
>> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations)
>> that the default behaviour has been changed.
>>
>>
>>
>> My reading of this is that the example above can now be changed to:
>>
>>
>>
>> await _cache.PutAsync(key, value);
>>
>>
>>
>> with the continuation occurring on a .Net threadpool thread by default.
>> Is that correct?
>>
>>
>>
>> This will allow us to remove the (quite a few) .ContinueWith() statements
>> which do add a layer of overhead on async calls.
>>
>>
>>
>> Thanks,
>> Raymond.
>>
>>
>>
>> --
>>
>> <http://www.trimble.com/>
>>
>> *Raymond Wilson*Trimble Distinguished Engineer, Civil Construction
>> Software (CCS)
>> 11 Birmingham Drive | Christchurch, New Zealand
>> raymond_wilson@trimble.com
>>
>>
>> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
>>
>>
>>
>
>
> --
> <http://www.trimble.com/>
> Raymond Wilson
> Trimble Distinguished Engineer, Civil Construction Software (CCS)
> 11 Birmingham Drive | Christchurch, New Zealand
> raymond_wilson@trimble.com
>
>
> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
>
Re: Ignite Async API call continutation behaviour
Posted by Raymond Wilson <ra...@trimble.com>.
Jay,
Thanks for the confirmation and the heads up regarding transactions.
Raymond.
On Mon, Oct 3, 2022 at 12:18 AM <ja...@gmx.de> wrote:
> Hi Raymond,
>
>
>
> That’s what we did and it works perfectly.
>
>
>
> Please note however that async/await currently does not work inside
> transactions, should that concern you.
>
>
>
> Pavel wrote in Jan 2022:
>
> “
>
> > Is using async/await supported for optimistic serializable transactions
> (and we’re doing something wrong)
>
> > or are transactional operations currently supposed to be blocking in
> .NET?
>
>
>
> Short answer - yes, please use synchronous cache APIs when working with
> transactions.
>
>
>
> A transaction is owned by a specific thread. Transactional API calls
> should be done from this thread, and `Commit` should be called from this
> thread.
>
> When doing `await`, we most likely end up on another thread and lose
> transaction context.
>
>
>
> There were plans to make transactions work across multiple threads, but
> the ticket looks abandoned:
>
> https://issues.apache.org/jira/browse/IGNITE-4887
>
> “
>
>
>
> Issue 4887 is currently still open as I see it.
>
>
>
> Best Regard
>
> Jay
>
>
>
>
>
>
>
> *From:* Raymond Wilson <ra...@trimble.com>
> *Sent:* Sunday, 2 October 2022 11:24
> *To:* user <us...@ignite.apache.org>
> *Subject:* Ignite Async API call continutation behaviour
>
>
>
> Way back in Ignite 2.8 we ran into an issue with continuations from Ignite
> Async method calls that meant our code could continue to run on an Ignite
> striped thread pool thread, with sometimes bad results.
>
>
>
> At the time the pattern suggested was to use a .ContinueWith()
> continuation, like this:
>
>
>
> await _cache.PutAsync(key, value).ContinueWith(t => { },
> CancellationToken.None, TaskContinuationOptions.None,
> TaskScheduler.Default);
>
>
>
> to ensure that the continuation after the PutAsync occurred on a .Net
> thread pool thread. This worked with no further bad results.
>
>
>
> A little while ago we upgraded to 2.13, and I note in this link (
> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations)
> that the default behaviour has been changed.
>
>
>
> My reading of this is that the example above can now be changed to:
>
>
>
> await _cache.PutAsync(key, value);
>
>
>
> with the continuation occurring on a .Net threadpool thread by default. Is
> that correct?
>
>
>
> This will allow us to remove the (quite a few) .ContinueWith() statements
> which do add a layer of overhead on async calls.
>
>
>
> Thanks,
> Raymond.
>
>
>
> --
>
> <http://www.trimble.com/>
>
> *Raymond Wilson*Trimble Distinguished Engineer, Civil Construction
> Software (CCS)
> 11 Birmingham Drive | Christchurch, New Zealand
> raymond_wilson@trimble.com
>
>
> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
>
>
>
--
<http://www.trimble.com/>
Raymond Wilson
Trimble Distinguished Engineer, Civil Construction Software (CCS)
11 Birmingham Drive | Christchurch, New Zealand
raymond_wilson@trimble.com
<https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
RE: Ignite Async API call continutation behaviour
Posted by ja...@gmx.de.
Hi Raymond,
That’s what we did and it works perfectly.
Please note however that async/await currently does not work inside transactions, should that concern you.
Pavel wrote in Jan 2022:
“
> Is using async/await supported for optimistic serializable transactions (and we’re doing something wrong)
> or are transactional operations currently supposed to be blocking in .NET?
Short answer - yes, please use synchronous cache APIs when working with transactions.
A transaction is owned by a specific thread. Transactional API calls should be done from this thread, and `Commit` should be called from this thread.
When doing `await`, we most likely end up on another thread and lose transaction context.
There were plans to make transactions work across multiple threads, but the ticket looks abandoned:
https://issues.apache.org/jira/browse/IGNITE-4887
“
Issue 4887 is currently still open as I see it.
Best Regard
Jay
From: Raymond Wilson <ra...@trimble.com>
Sent: Sunday, 2 October 2022 11:24
To: user <us...@ignite.apache.org>
Subject: Ignite Async API call continutation behaviour
Way back in Ignite 2.8 we ran into an issue with continuations from Ignite Async method calls that meant our code could continue to run on an Ignite striped thread pool thread, with sometimes bad results.
At the time the pattern suggested was to use a .ContinueWith() continuation, like this:
await _cache.PutAsync(key, value).ContinueWith(t => { }, CancellationToken.None, TaskContinuationOptions.None, TaskScheduler.Default);
to ensure that the continuation after the PutAsync occurred on a .Net thread pool thread. This worked with no further bad results.
A little while ago we upgraded to 2.13, and I note in this link (https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations) that the default behaviour has been changed.
My reading of this is that the example above can now be changed to:
await _cache.PutAsync(key, value);
with the continuation occurring on a .Net threadpool thread by default. Is that correct?
This will allow us to remove the (quite a few) .ContinueWith() statements which do add a layer of overhead on async calls.
Thanks,
Raymond.
--
<http://www.trimble.com/>
Raymond Wilson
Trimble Distinguished Engineer, Civil Construction Software (CCS)
11 Birmingham Drive | Christchurch, New Zealand
<ma...@trimble.com> raymond_wilson@trimble.com
<https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>