Thanks for your help on replication over https questions. We deployed our website to a Windows Server 2012 R2 machine and we are getting the following error whenever we turn the replication on… I suspect there is something odd going on with the stateless.dll? Any hint on how to fix it?
Yes, actually. There was a breaking ABI change in the Stateless dep library. Did you happen to update it to the latest version? If so you’ll need to install the correct version. I put out a new version of the package that puts a hard maximum on the version to prevent this. Any version higher than 2.5.29 will cause problems.
For the next nuget release I will recompile with the latest version to get rid of this problem.
Thanks Jim! I confirmed that we are on 2.5.53… I cannot install the new version yet because I am using a custom build of Issue 433 to work around the https replication issue. I will try downgrade the package now.
For your information, the master branch has a revamped implementation of https that you might be interested in. It no longer requires the complicated registration process, and you can specify a certificate in code at runtime.
How can I turn on logging for Couchbase lite replication? When running on our production server, I can see the pull and push fired the initial connections but then they just sit there; there is no further request. Replication didn’t happen. I am trying to debug the issue. How picky is Couchbase lite on ssl certificate? If it uses a certificate that was issued to a different host, would couchbase reject the communication?
This is a topic of hot debate at the moment internally, but for right now you cannot enable more verbose logging without making a debug build of the library (I think this will be changing soon but the ultimate direction has not been decided yet).
Couchbase will reject a certificate whose name doesn’t match the host, but you can override it by setting a callback on ServicePointManager.ServerCertificateValidationCallback. For testing purposes you can just have a callback that returns true and it will accept anything regardless of error. If the connection were rejected though you should see a log with an exception. Do you see any logs at all?
Your answer implies there is logging (not verbose). Do I need to enable it by hooking it up with NLog or something? Coz at the moment, I don’t see any logging message from Couchbase… I wish your documentation has more content so I don’t have to waste your time
Logging goes to wherever Console.WriteLine goes (and if running a debugger, Debug.WriteLine as well). Sometimes that means that the messages are discarded or moved though, if your setup suppresses or redirects Console.Out.
@borrrden Sorry I don’t have much experience with MS System Diagnostics. I have been using log4net and nlog…
So I built Couchbase lite again using Visual Studio with the word “VERBOSE” in Conditional compilation symbols field. Is that all I need to do for the two couchbase dlls?
I then included the dlls in my project and added a configuration section in my web.config.
<trace autoflush=“true” indentsize=“4” >
Now I can see all messages from my application but no message from Couchbase… Am I missing something?
Honestly I don’t know much about log4net. However, I am fairly sure that the Couchbase Log output will not be redirected there unless you make your own logging implementation and register it in Couchbase Lite via the Log.SetLogger() API. The default implementation will simply output to Console.Out (pretty much like log4net.Appender.ConsoleAppender).
However, mentioning web.config makes me suspicious. If you are making a web application your console output might be redirected to a file or something behind your back since I suppose it is not displaying a console?
The version of Couchbase lite I am using relies on mono.security package to do replication over https. However, the package is not listed as a dependency on the Couchbase package…yet. Couchbase lite fails silently if it couldn’t load mono.security and will not issue a “get change” request. I only found the error in verbose debugging mode. It would be great if Couchbase can make the logging easier to implement. I would prefer to drop a configuration section in app.config or web.config to activate logging to a file to whatever directory specified in the config section… Thanks.
I actually had to patch Mono.Security because of the state that it is in. Are you currently on the latest master? The Mono.Security patches were specific to Mono (or so I thought). The custom Mono.Security project is checked into the repo at this location. I’ll double check on Windows that things are working as they do in OS X.
I would prefer to drop a configuration section in app.config or web.config to activate logging to a file to whatever directory specified in the config section… Thanks.
This is easier said than done when supporting 11 platforms However, I was able to very quickly write up a Log4Net and NLog adapter for the logging system. This will allow Couchbase Lite to leverage the power of these libraries on platforms that support them. They can’t be included directly into the library but they could be offered as an external assembly.
I thought that would be the case for logging The adapter sounds great!
I am still using issue/433. Our app is a asp.net web app deploys on windows server… Not sure why it runs mono however I can see it in the log. We are sending the project to testers tomorrow so, if don’t have to, I don’t want to update the couchbase packages now. Do I need to patch my version of mono? Can you please provide some instructions on how to do it? Thank you.
The mono patches were to make SSL work well on the server side for Mono platforms (meaning…everything except Windows). Ideally, I want Windows to use its internal implementation of the relevant classes. However, Mono.Security is used for generating X509 certificates since .NET has no built in way to do that. issue/433 does not exist as a branch anymore, but if you are using a commit on or after 65e468b58e896134824f4018816eb3751b295279 then it has switched over to the new way of doing things. Before that is another story. I’ll see if I can find anything on the latest master commit, and if you tell me your commit hash I’ll check that one out too.
Ohhhh you are way back there. This was my first attempt to close issue 433 before I realized the problems with Mono.Security. In this commit, Mono.Security is specified as a nuget package dependency on the Couchbase.Lite project. It looks like sometimes Visual Studio is not smart enough to copy it from that project’s output directory to a consuming project’s output directory. A quick workaround, though, would be to add a nuget dependency on Mono.Security in the consuming project (I assume that is what you did?).
Note: Mono.Security is only needed for generating a certificate. If you’ve already installed a certificate and bound it to the appropriate port then you don’t need to call GenerateCert, or anything. Could you show the log message that indicated that you needed Mono.Security?
If possible, it would be good to update as soon as you can. This branch that you have has already started heading in another direction. I checked the latest master and replication continues normally over SSL.