lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shad Storhaug (JIRA)" <>
Subject [jira] [Commented] (LUCENENET-565) Port Lucene.Net.Replicator
Date Fri, 23 Jun 2017 17:46:00 GMT


Shad Storhaug commented on LUCENENET-565:

Andy Pook <> commented:

{quote}Not sure I have the right end of the stick here, but...

AspNetCore absolutely "supports" owin, Owin is at it's center (I was about to say "core").
There are several abstractions layered on top, so it may not be totally obvious.

The "Core" part of the name is definitely confusing. There is some historical relationship
between AspNet-Core and DotNet-Core but it's best to think of them as separate things. May
as well call it AspNetFred or AspNetVNext or AspNetRethoughtFromTheGroundUp.
It's such a big change that just a major version number bump wasn't seen as enough. It's more
that a breaking change. It a complete rewrite.

AspNetCore will run on top of both DotNetCore and DotNet-Framework (ie the "old" dot net.
4.5.1 onwards, I think).

netStandard is yet another thing. It is a standard defining the api's available for a given
implementation of dotnet. Lower versions of Standard define smaller sets of api's. So, if
you restrict your code to only using
netStandard-1.3 then it will run on smaller implementations of dotnet (think IoT) or be more
likely to be cross platform (think early versions of Xamarin or DotNetCore).
netStandard-2.0 is where it gets interesting as it becomes possible to easily reference "legacy"
assemblies from new DotNetCore code.
The idea is to be able to write against netStandard and have the same assembly runable on
any platform that supports that version of the Standard (Win, Mac, Linux at the mo and I believe
there are ARM implementations too, so RaspberryPi etc).

If you're looking for an http listener you should probably look into Kestrel. This is the
new http "server" layer. Cross platform, self hostable etc. They've been getting some really
nice perf out of it.

Hope I'm helping rather than frustrating even more.

Andy and Jens,

Thanks for the feedback. My original thought was to start with a generic (as much as possible)
library that we can build into at least 1 HTTP listener option for .NET Framework and at least
1 cross-platform HTTP listener option for .NET Core. If possible, it would be great to have
other HTTP listener options as well (such as a Windows Service, Console app for testing, etc)
but we could wait until later to build those. Maybe this is still too much since you technically
can run both .NET Core and .NET Framework on the same server (thus having a .NET Framework
main application (such as MVC) and a .NET Core hosted replicator), but it seems more natural
(to me) to use the same technology for all applications. At least, it would certainly make
sense for those who are using paid hosting that doesn't have .NET Core available yet.

If we have to choose only one, I would say use a .NET Core technology. I was looking at Kestrel,
but I got the impression that Kestrel is basically the cross-platform equivalent of IIS. That
is, it is a web server, but you still need to build some kind of a module (such as a middleware
plugin) to host on the web server. In the diagram here (,
we are talking about the "application code".

My thinking here is that we should make setup for this module as simple (yet configurable)
as possible, ideally a drop in DLL with a logical default configuration that "just works"
if put on a web server, but that could be configured via DI (for example, to customize the
routing) if hosted within an application. Maybe this will require a "base" assembly that can
be used within an application and a separate HTTP listener assembly (that uses the "base")
that is plug-and-play, but that is the general idea.


Thanks for doing the legwork - it pays to be thorough.

Although I think it would be great to get on .NET Standard 2.0, I don't think it really helps
anything here since we are talking about front-end applications for HTTP listeners and .NET
Standard only affects the sharing of back-end class libraries among front-end applications.
It may help if you look at how we test Lucene.Net - we build our assemblies on .NET Standard
1.5, but the assemblies (and version of NUnit) that test them are compiled and run on .NET

Certainly System.Net makes sense for the _client-side_ functionality (of which there is some
in Replicator), but for the actual "servlet" replacement there is no such functionality in
System.Net. Fortunately, there are a relatively small number of HTTP listener options in .NET,
many of which are now outdated.

Again, ideally we would have one option for .NET Framework and one for .NET Core, but if it
comes down to only having the time for a single option, we should use ASP.NET Core (Web API
or ASP.NET Core middleware). Of course, keep in mind that we would like as many framework
and hosting options as practical, so try to put as much code as possible into a shared location
so it is not repeated.

I haven't worked with these yet, but my advice is to use the one that has the least amount
of configuration required by whoever wants to install the ReplicationService. If there is
a trick to make either one "just work" with one file dropped into one folder, that would be
ideal and preferable to having to "run setup" or add a bunch of startup statements to the
code or configuration. That said, the latter are also certainly options. The URLs and requests/responses
of our ReplicationService should mimic those in Java:

bq. On a side note: I just noticed that the blue button next to the question mark at the bottom
of the "Comment" window is a preview button, which may help reduce the number of edits you
have to do :).

> Port Lucene.Net.Replicator
> --------------------------
>                 Key: LUCENENET-565
>                 URL:
>             Project: Lucene.Net
>          Issue Type: Task
>          Components: Lucene.Net.Replicator
>    Affects Versions: Lucene.Net 4.8.0
>            Reporter: Shad Storhaug
>            Priority: Minor
>              Labels: features

This message was sent by Atlassian JIRA

View raw message