5

I've just tried connecting to my RavenDB windows instance from linux using mono. I'm getting a bizarre error with it, that seems to be mono related rather than raven related.

Here is my recreate code (works on windows):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Raven.Client.Document;

namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {

            try
            {
                var store = new DocumentStore()
                                {
                                    ConnectionStringName = "RavenDB",
                                    EnlistInDistributedTransactions = false

                                };
                store.Initialize();

                using (var session = store.OpenSession("system-events"))
                {
                    session.Store(new { Name = "Test" });
                    session.SaveChanges();
                }
                Console.WriteLine("done");
            }
            catch (Exception ex)
            {

                Console.WriteLine(ex.ToString());
            }

            Console.ReadKey();


        }
    }
}

and my mono version:

chris@x-ngx4:~/click/beta/Debug$ mono --version
Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-1ubuntu2.2)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            Included Boehm (with typed GC and Parallel Mark)

and the error:

chris@x-ngx4:~/click/beta/Debug$ mono ConsoleApplication2.exe
System.IO.IOException: Internal error (no progress possible) Flush
  at System.IO.Compression.DeflateStream.CheckResult (Int32 result, System.String where) [0x00000] in <filename unknown>:0
  at System.IO.Compression.DeflateStream.Flush () [0x00000] in <filename unknown>:0
  at System.IO.Compression.GZipStream.Flush () [0x00000] in <filename unknown>:0
  at Raven.Abstractions.Connection.HttpRequestHelper.WriteDataToRequest (System.Net.HttpWebRequest req, System.String data, Boolean disableCompression) [0x00000] in <filename unknown>:0
  at Raven.Client.Connection.HttpJsonRequest.Write (System.String data) [0x00000] in <filename unknown>:0
  at Raven.Client.Connection.ServerClient.DirectBatch (IEnumerable`1 commandDatas, System.String operationUrl) [0x00000] in <filename unknown>:0
  at Raven.Client.Connection.ServerClient+<>c__DisplayClass68.<Batch>b__67 (System.String u) [0x00000] in <filename unknown>:0
  at Raven.Client.Connection.ReplicationInformer.TryOperation[BatchResult[]] (System.Func`2 operation, System.String operationUrl, Boolean avoidThrowing, Raven.Abstractions.Data.BatchResult[]& result) [0x00000] in <filename unknown>:0
Chris
  • 1,241
  • 1
  • 14
  • 33
  • Version of RavenDB please? – Matt Johnson-Pint Dec 13 '12 at 16:39
  • 2.0.2170-Unstable on client and server – Chris Dec 13 '12 at 17:16
  • Does it make a difference if you use a regular class instead of the anonymous class when defining the document? – Matt Johnson-Pint Dec 13 '12 at 18:28
  • For reference, here are links to raven's [HttpRequestHelper](https://github.com/ayende/ravendb/blob/master/Raven.Abstractions/Connection/HttpRequestHelper.cs) and the mono implementation of [GZipStream](https://github.com/mono/mono/blob/master/mcs/class/System/System.IO.Compression/GZipStream.cs) and [DeflateStream](https://github.com/mono/mono/blob/master/mcs/class/System/System.IO.Compression/DeflateStream.cs). Still can't find the root cause though. – Matt Johnson-Pint Dec 13 '12 at 19:10

1 Answers1

6

I think I found it. DeflateStream has extern references to zlib. If you look at the zlib header file, you will find some comments:

deflate() returns Z_OK if some progress has been made (more input processed or more output produced), Z_STREAM_END if all input has been consumed and all output has been produced (only when flush is set to Z_FINISH), Z_STREAM_ERROR if the stream state was inconsistent (for example if next_in or next_out was Z_NULL), Z_BUF_ERROR if no progress is possible (for example avail_in or avail_out was zero). Note that Z_BUF_ERROR is not fatal, and deflate() can be called again with more input and more output space to continue compressing.

The message Internal error (no progress possible) is what DeflateStream returns when getting a Z_BUF_ERROR - but it doesn't continue, it treats it as a hard stop. It should treat it as a warning and continue. At least, that's my interpretation.

Can you raise this with the mono support team? I'm not active in that group. Thanks.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • Oh, that's interesting. Well, tbh. I'd call that API "broken" - IMHO status codes should not use name "ERROR" for something that's actually not a fatal error condition. Well, this should be an easy fix, but I'm wondering whether `Flush()` or `CloseZStream()` could also return `Z_BUF_ERROR` for non-fatal conditions. – Martin Baulig Dec 13 '12 at 19:59
  • I've emailed them details. Earlier I removed compression, suspecting an issue with the GZipStream, but this didn't resolve it. Instead I got a "401" - which makes no sense, as I wasn't using authentication. When I added auth details, I got the same response. I'm going to investigate tomorrow in more detail. However, fiddler wasn't co-operating, so will use wireshark to see what is going on. I'll update here accordingly. Cheers! – Chris Dec 13 '12 at 20:00
  • It'd also be good to know which data `ReadZStream()` is being called with - maybe it's something that zlib doesn't like for some reason, like corrupted data or something like that. – Martin Baulig Dec 13 '12 at 20:06
  • 1
    @Chris - can you set `store.JsonRequestFactory.DisableRequestCompression = true` and run it while capturing the http with wireshark or similar? The request body should then show the uncompressed value that is trying to go through gzip. – Matt Johnson-Pint Dec 13 '12 at 20:19
  • @MattJohnson Got it working through Fiddler - turns out mono isn't sending any auth headers... I think this issue might be related http://stackoverflow.com/questions/8392439/why-i-cant-make-httpwebrequest-working-with-ntlm-authentication – Chris Dec 14 '12 at 10:06
  • Mono 3.x has also received some NTLM fixes, I would try that version. – knocte Dec 14 '12 at 10:11
  • Has anyone figured this out? –  Sep 07 '14 at 11:08