Async/Await support

[danielmarbach]

Task force: @colin-higgins @mauroservienti @DavidBoike @kbaley Connects to Particular/PlatformDevelopment#182

This is the RavenDB adapter epic which incorporates the work for making the RavenDB adapter async/await enabled. Please see this blog post about the reasoning behind it.

Plan of attack

• Make the timeout persister async
• Make the subscription persister async
• Make saga persister async
• Provide the document session to handlers via ext method on handler context
• Make the gateway persister async
• define/find what doco needs to be updated/created
  • Code snippet for v6
  • Doc page

[danielmarbach]

See also https://github.com/ravendb/ravendb/pull/606 (Pulled into Raven)

[mauroservienti]

I'd like to bring this forward. /cc @andreasohlund @danielmarbach

[danielmarbach]

@mauroservienti great!

[mauroservienti]

@andreasohlund why this is not approved anymore? Can I bring this forward or is it blocked?

[andreasohlund]

@mauroservienti this one is still approved, just got relabled when we where working with the new waffle boards. Go for it

[mauroservienti]

@danielmarbach @andreasohlund a couple of questions:

• currently all what deals with session management expects the session to be an IDocumentSession should I migrate all to IAsyncDocumentSession?
• if the previous is a yes this means the we should require the user to provide an async shared session and not a sync one;
• The TimeoutPersister does not use the user provided shared session, if any, is this intentional? (same for the SubscriptionPersister)

Thoughts?

[danielmarbach]

@mauroservienti

• I think so, yes
• Yes, therefore obsolete the old ones
• Intentional, both are called outside the handler infrastructure and doesn't need to share the session

Ok?

[andreasohlund]

@mauroservienti sync with @SzymonPobiega since he just made a core change that makes the storage session used by the outbox, sagas and the users explicit

[mauroservienti]

@danielmarbach thanks. On the intentional stuff, isn't the TimeoutPersister used (also, but not only) by saga timeouts, so in the context of an handler?

thanks @andreasohlund I'll ping @SzymonPobiega

[andreasohlund]

On the intentional stuff, isn't the TimeoutPersister used (also, but not only) by saga timeouts, so in the context of an handler?

The request happens on a handler yes but talking to the persister happens on one of the two TM satellites

[mauroservienti]

:+1:

[mauroservienti]

@colin-higgins ping me as you come online :smile:

[mauroservienti]

The actual implementation of vNext starts from the assumption that the RavenDB client we are going to use is 3.x meaning that we are going to force all users to migrate the RavenDB server to 3.x.

Is this what we really want? or given that the 2.5 client will work with a 3.0 server we should not force the upgrade?

[danielmarbach]

We need at least client version 3801 (if I remember correctly). Lower versions async API is completely broken when used inside a TransactionScope

https://github.com/ravendb/ravendb/pull/606

[mauroservienti]

@danielmarbach got it, thanks. Are we happy with fact that this implies that the user is forced to upgrade servers to v3?

[danielmarbach]

I think there is no way around it

[DavidBoike]

All items on the PoA are either done done or have issues tracking their progress with the Core V6 label.

[mauroservienti]

What about the retrospective?

[DavidBoike]

Ack, you're right. It wasn't in the PoA. We can hold it during async persistence sync time Monday. @mauroservienti should we reopen until that is done and documented?

[mauroservienti]

I'm off next week, what about handling the retrospective async in a different issue?

[DavidBoike]

Moved back to in progress. Issue is "done" except for a retrospective where we will ensure that it is "done done" and raise any ancillary issues before closing this one.

Retrospective tentatively scheduled for async persistence sync time on Tuesday March 15 (after time off for Mauro and Colin)

[DavidBoike]

Retrospective

Good

• It's done (kind of a gimme, thanks Colin)
• Simplified a few aspects of Raven from CoreV5
• Stabilized CI by doing a better job cleaning up databases
• More people who have familiarity with Raven now
• Helped to have several people (David,Colin, Kyle) in roughly in the same time zone for logistical reasons. Were able to do lots of pairing. Sorry Mauro. We still love you.
• Due diligence in eliminating problems in our code was awesome. Because we rock.
• Raven persistence was "done first" due in large part (perhaps) to regular attendance of this TF members during async persistence sync.

Bad

• Reviews of PRs, async work could have been faster (Some PRs sat for awhile)
  • Maintainer groups should help with this going forward
  • Being overcommitted is an occupational hazard
• We didn't have enough cross-pollination of knowledge between persistences.
• Raven persistence dominated async persistence slack channel, and others were not discussed much.

Room for improvement

• Still room for improvement on CI cleanup. Some tests still leak databases from time to time, but no longer the flood it was before. (see #116)
  • Could run the task regularly but limit it to databases older than ~1h
• Could be good to do quick demos/walkthroughs of code changes to the #demo channel to prevent siloing of knowledge.
• Be mindful of not leaving a "loner" in a time zone. It's too easy for the one person to be left out.
• Should upgrade the build agent image (TeamCity/Raven3 server versions) (see #170)