Problems with RavenFS in embedded mode

[Michael Davis]

I've been working on updating my current project (part of which is a WPF desktop application using RavenDB in embedded mode) to use RavenDB 3, but I ran into some trouble with changing the parts that used attachments to use RavenFS.  Whenever I tried to save a file, I would get what ultimately appeared to be a FileNotFoundException.  It seems as though the AsyncFilesSession is trying to make a web request despite being in embedded mode, and it's getting a 404 error from my local instance of IIS, which RavenDB is translating into a FileNotFoundException.

I traced through the code and ultimately found that when the session is opened, the FilesStore is creating a new instance of AsyncFilesServerClient for the new session instead of using the one it already has.  When running in embedded mode, the AsyncFilesServerClient owned by the FilesStore is configured not to actually send a web request (by setting the HttpJsonRequestFactory's HttpMessageHandler to an OwinClientHandler instance, I believe), but the new one being created for the session isn't inheriting that configuration.

I changed the code to pass the FilesStore's existing AsyncFilesServerClient to the new session, and that solved the problem I was having, so I'm submitting a pull request for that.  If there's a problem with doing it that way that I didn't consider, then passing the FilesStore's HttpJsonRequestFactory to the new AsyncFIlesServerClient should also work, I think.

[Oren Eini (Ayende Rahien)]

Nope, that looks fine, yes. Pulled and thanks.

Hibernating Rhinos Ltd  

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

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

 

--
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Davis]

Actually, something was bothering me about this, so I took another look, and I saw a problem with what I did.  By changing it to just use the FilesStore's AsyncFilesServerClient instead of creating a new one, I think I inadvertently made it impossible to open a session for any filesystem other than the one set as the default for the FilesStore.

I noticed that there was an unused SetupCommandsAsync() method right below OpenAsyncSession() that looked like it did what I wanted, so maybe someone just forgot to hook that up at some point.  I made a modification to that method so it would pull the ApiKey from the OpenFilesSessionOptions parameter and modified OpenAsyncSession() to use it.  I've pushed this change up to my fork of the repository, and it looks like it shows up in the pull request, which still seems to be open.

[Oren Eini (Ayende Rahien)]

Hm,

Basically, you can just use what we do for the DocumentStore.

[Michael Davis]

Looking at how this works in the DocumentStore, I think that's basically what the last revision I described is doing.  The FilesStore already had a SetupCommandsAsync() method like the one that handles this in the DocumentStore, but nothing was ever calling it.  My last change just made OpenAsyncSession() start using that method.  (I also made a change to SetupCommandsAsync() because it wasn't using the ApiKey from the OpenFilesSessionOptions passed to it.)

Are you seeing something wrong with what I did in my second revision?

[Oren Eini (Ayende Rahien)]

Pulled, this is fine, yes.