lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Pook <>
Subject Re: [jira] [Commented] (LUCENENET-565) Port Lucene.Net.Replicator
Date Fri, 23 Jun 2017 18:27:19 GMT
Again, I'm not sure I'm understanding your concerns, but...

Kestrel will run on both Framework and Core. If what you're looking for in
an http listener you should only need to think about one thing.

Kestrel is "just" a (mostly) managed port listener which understands http.
It seems to be the direction MS is going for this type of thing. Although
there are swappable hosts (the other main one is WebListener (which is a
wrapper on Windows HttpSys).

The approach seems to be to use Kestrel, self-hosted in a console app, then
use IIS, Nginx, Apache etc as a proxy to deal with process management
(restarts on faiure etc).

The hosting and request handling mechanisms are completely decoupled.

There are many options for dealing with requests. Full MVC (in Core there
is no difference between mvc and webapi). Or dealing with the request
message directly owin style. Or Nancy. Or...

Hope I'm helping

On 23 June 2017 at 18:46, Shad Storhaug (JIRA) <> wrote:

>     [
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
> focusedCommentId=16061286#comment-16061286 ]
> 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.
> {quote}
> 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 (
> en-us/aspnet/core/fundamentals/servers/), 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.
> Jens,
> 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 Core.
> 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:
> apache/lucene/replicator/http/ReplicationService.html
> 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
> (v6.4.14#64029)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message