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 19:48:00 GMT


Shad Storhaug commented on LUCENENET-565:

Andy Pook <> commented:

{quote}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.

Hope I'm helping


Okay, maybe you can clear up my confusion. First of all, I am assuming that Kestrel is just
a web server. You can only run something on Kestrel if it is built using one of the HTTP listening
options (similar to using IIS to host an MVC application on the ASP.NET IIS HTTP module on
.NET Framework). Without the HTTP module running ASP.NET, it wouldn't work. In other words,
I thought that you need some sort of application framework to build the listener in, not just
run it in Kestrel without something like ASPNET Core. You seem to be saying that one application
can be built and run on Kestrel in either .NET Framework or .NET Core without a framework
of some kind? If that is true, can you provide a link to the documentation?

But then in another sentence you said that "The hosting and request handling mechanisms are
completely decoupled.", which seems to confirm my original assumption that a framework of
some kind is required to use it.

Certainly, we are trying to get the least amount of code and configuration that provides the
simplest, the most (and most up to date) deployment options. But also keep in mind, this is
a pretty simple listener with 3 different actions with 2 parameters each, not a full blown
application API. In fact, the Java code for this service is less than 150 lines. This is not
something we can't change around later if we get it wrong on the first try.

> 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