I am curious why RavenPersistenenceEngine.Commit throws this exception.
Is there some work needed to be done still?
It took a few hours to find this, since I was investigating why message dispatcher was not being called. I see the events arrive in ravendb but none of the post commit hooks are executed.

The the raven implementation leverages queries when retrieving streams. Raven queries by design are eventually consistent. To get around this, WaitForNonStaleResultsAsOfLastWrite is leveraged to try to force consistency. This causes issues with timeouts when there are many indexes on the same database or when indexing is slow.

With Raven feature improvements, we should now be able to refactor the models to provide an implementation that doesn't rely on Queries for gets for a single stream & perhaps for replay by checkpointId.

I expect that getting by date will still require queries.

Until we can remove WaitForNonStaleResults, users should have a way of customizing the wait time to prevent the likelihood of timeouts. This should be used for Purging as well.

(Import from NEventStore/NEventStore#184)

CheckpointNumberIncrementListener is used to set the next checkpointId. This is listener is required by the RavenPersistenceEngine. However, it doesn't get added to the documentStore if the user instantiates the RavenPersistenceEngine directly, providing their own IDocumentStore.

We should move adding the listener as initinalization logic to inside RavenPersistenceEngine. However, RavenPersistenceEngine depends on IDocumentStore, which doesn't expose RegisterListener. We should consider changing the dependency to DocumentStoreBase.

This will be a breaking change to the RavenPersistenceEngine ctor contract.

(Issue imported from NEventStore/NEventStore#231 )

(Moved from NEventStore/NEventStore#110 , go there to see the rest of the thread)

Hi Jonathan,

We have uncovered recently a few issues when persisting events into RavenDB which are all related to how indexes work there. It would be nice to hear what you think about these:

By default RavenPersistenceEngine is constructed with ConsistentQueries option set to "false" which opens a time window when it is possible to create & save an aggregate, but then fail to load it back upon receiving next message delivering new update. That is because Raven was under pressure and couldn't update "RavenCommitsBy.." index fast enough.
If we enable ConsistentQueries then under heavy pressure we get Raven's timeout exceptions (Waited for 16,493ms for the query to return non stale result). It passes fine on second retry, since index is updated.
EventStore defines several "RavenCommitsBy... and "RavenSnapshot..." indexes per database, but they are all global (non AR or Saga specific) and if you have several aggregates/sagas who save into this EventStore -> staleness of these indexes is defined by new events coming to ANY of those, instead of being AR or Sage bound. Do you also see benefit of maintaining index per AR/Saga type?
Thanks,
Anton.

see NEventStore/Discussions#1

Hey, is it possible to add the latest release (6.0) dependent on Raven 3.0 to the NuGet library?

Hello,

Is there any update for RavenDB 4.0? I

Regards,
Gunpal Jain

GetCheckpoint should always return a token so that relying code doesn't have to check for null before using checkpoint.Value. Makes comparison easier as well.

see NEventStore/NEventStore#405