RavenDB 4.0 RC 2 released

176 views
Skip to first unread message

Oren Eini (Ayende Rahien)

unread,
Nov 16, 2017, 10:31:04 AM11/16/17
to ravendb
Guys,
I wanted to give you the heads up as soon as possible.
The RC2 bits for 4.0 have landed.
The blog post will be out tomorrow, but you can already start getting it.

I'll have the full list of changes in the blog post.


Hibernating Rhinos Ltd  

Oren Eini l CEO Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

Justin A

unread,
Nov 16, 2017, 10:39:42 PM11/16/17
to RavenDB - 2nd generation document database




(Still was hoping for the testing story stuff to get included in RC2 ... :(  )

Justin A

unread,
Nov 16, 2017, 10:51:35 PM11/16/17
to RavenDB - 2nd generation document database
Is this picture correct?


Bernhard Glück

unread,
Nov 17, 2017, 12:29:03 AM11/17/17
to rav...@googlegroups.com
Lovin it :-) Just imported an old large database with insane indices ( don't ask ) and basically the time to import + all indices becoming none stale went from 52 min ( Raven 3.5 ) to under 1 minute.... insane. 

A question btw, since i am working with some other customers now, which is a JAVA shop.. will the Java driver for Raven 4 also support asynchronous execution ? If yes will you use Future/CompletableFuture or go to some other async library like RXJava, Reactor and will the basic reactive streams spec be implemented ? 

2017-11-17 4:51 GMT+01:00 Justin A <jus...@adler.com.au>:
Is this picture correct?


--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jens Pettersson

unread,
Nov 17, 2017, 7:30:23 AM11/17/17
to RavenDB - 2nd generation document database
Testing it out right now!

Will the blog post contain any more information on the RavenTestDriver and best practices for running unit/integration tests against something kind of like the old EmbeddableDocumentStore? We're running several tests with the TestDriver right now (setup taken from the example tests in the source code), and it's a bit clunky still. We have to define a Guid for each GetDocumentStore call we make because if two test METHODS have the same name (but in different classes) it share the actual db which might cause unexpected things to happen... However, now our database folder get's filled with directories with guid names...

I thought the TestDriver could run things in memory, but it seems it needs to write something to disk.

We also have problems running our test suite in Visual Studio with the xunit.visualstudio.runner now as it seems to hang when the test suite is finished... It never stops. Works fine with the built in Test Explorer and with dotnet test from command line. IIRC this worked in RC1...

//J

Oren Eini (Ayende Rahien)

unread,
Nov 17, 2017, 7:38:30 AM11/17/17
to ravendb
Yes

Hibernating Rhinos Ltd  

Oren Eini l CEO Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 


On Fri, Nov 17, 2017 at 5:51 AM, Justin A <jus...@adler.com.au> wrote:
Is this picture correct?


Oren Eini (Ayende Rahien)

unread,
Nov 17, 2017, 7:40:50 AM11/17/17
to ravendb
By default GetDocumentStore should generate different ids, not the same one.
How did you get this?


Can you send us a repro of the hanging issue?
--

mar...@ayende.com

unread,
Nov 17, 2017, 7:58:51 AM11/17/17
to RavenDB - 2nd generation document database
First versions of the 4 driver will contain only synchronous API. There is a plan to add the asynchronous API also, but the time frame for that is currently unknown.

Marcin Lewandowski
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

Jens Pettersson

unread,
Nov 17, 2017, 9:03:40 AM11/17/17
to RavenDB - 2nd generation document database
Inline-ish:
 
By default GetDocumentStore should generate different ids, not the same one.
How did you get this?

https://github.com/jenspettersson/RavenPerfs/blob/master/Bugs/Raven4.TestDriver.Tests/Raven4.TestDriver.Tests/TestClassOne.cs

This file has two classes, and the method "MyTest()" in both. This generates a database, for both tests, named "MyTest_1" (https://github.com/ravendb/ravendb/blob/cb0fb5b22e8790c2bfdbe1a643bb95b0c0ebe57e/src/Raven.TestDriver/RavenTestDriver.cs#L54 - it seems to always increment from 0). If these tests run at the same time, I get an exception:


Only one of the "MyTest" methods failed here. The same thing goes for the Theory test "MySecondTest".


Looking at the folder for the DataDir, I can see the following folders being created:



If a given test method would truly generate unique names you should at least see a MyTest_2 in there and probably a MySecondTest_2 as well...



However, the Concurrency Exception doesn't ALWAYS happens, it seems to happen more often if the computer is under load, which the next thing will describe...



Can you send us a repro of the hanging issue?

At the test session screenshot above, you can see that the stop button is always active, meaning the test runner doesn't think the test suite has completed. I can't even stop it, the only thing is to kill the devenv.exe process. The "hanging" is probably done by the resharper xunit runner. 

However, if I run "dotnet test" from the console, and and then count the number of dotnet-processes, it always increments by 1 after each run when running a Raven TestDriver-test

PS C:\RavenTestLab> @(get-process -ea silentlycontinue 'dotnet').count
0

PS C:\RavenTestLab>dotnet test

[TESTS RUNNING]

PS C:\RavenTestLab> @(get-process -ea silentlycontinue 'dotnet').count
1

PS C:\RavenTestLab>dotnet test

[TESTS RUNNING]

PS C:\RavenTestLab> @(get-process -ea silentlycontinue 'dotnet').count


PS C:\RavenTestLab>dotnet test

[TESTS RUNNING]

PS C:\RavenTestLab> @(get-process -ea silentlycontinue 'dotnet').count
3

etc...

This doesn't happen when I run a "standard xunit test" without the RavenTestDriver.

The first issue of concurrency of the database occured a lot more frequent after I've done several test runs and had hundreds of running dotnet processes (and quite some CPU load). 

This happens to me and my colleagues so it's not just something on my machine. dotnet --version -> 2.0.2

That's all I can find right now. 

//J
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

Jens Pettersson

unread,
Nov 17, 2017, 9:15:18 AM11/17/17
to RavenDB - 2nd generation document database
Hold it! I found out why it spawned dotnet processes that never was shut down!

My settings.json file looked like this:

{
    "ServerUrl": "http://127.0.0.1:0",
    "Setup.Mode": "Initial",
    "DataDir": "APPDRIVE:/RavenIntegrationTests",
    "RunInMemory": true
}


It's the "Setup.Mode": "Initial", that causes the hanging and processes!

{
    "ServerUrl": "http://127.0.0.1:0",
    "DataDir": "APPDRIVE:/RavenIntegrationTests",
    "RunInMemory": true
}


This works better!

However, it still doesn't generate unique database names...

//J

Oren Eini (Ayende Rahien)

unread,
Nov 18, 2017, 6:13:50 AM11/18/17
to ravendb
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.

Oren Eini (Ayende Rahien)

unread,
Nov 18, 2017, 6:14:26 AM11/18/17
to ravendb
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages