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 21:22:40 GMT
Ah, I see...

Kestrel _is_ an http listener.
It's pretty simple but fast. It doesn't support port sharing (nor Windows
auth, I think)

Here's a fairly straightforward example

The Program.Main sets up a "host" with Kestrel (essentially an http owin
The "UseKestrel" line is what defines the "listener". "UseWebListener"
would set it up to use httpsys.
WebHostBuilder lets you set up the hosting concerns. Listener type,
directories, config, IIS integration, static files etc etc (

As a separate concern, the Startup class configures the rest of the
pipeline (ie what to do with the requests In this
case it's just an owin style handler to response "hello world".
It's in this Start up class that you can configure mvc or whatever you want
to respond to the requests (including compression, auth, routing, config,
DI, etc etc).

There are _lots_ of options/possibilities.

currently kestrel is not supported for public facing use. There's more work
to do to harden it against attack. This why they currently recommend hiding
it behind a proxy. Generally the examples will set up  the proxy to also
host the process. So no need to create it as a service, the proxy will deal
with starting the process for you.

But, if I understand correctly, what you need is just the ability to start
an http endpoint for server to server stuff. So just run up kestrel like in
the example at the top.

Of course there are other options. A simple tcp socket, but then you'd need
to create some sort of custom protocol and deal with connection management.
Not hard, but tricky to get right (devil in the detail). DotNetty can help
here but that's another voyage of discovery.
I've also had good success using for persistent
chatty connections.

Pick you poison :)

On 23 June 2017 at 20:48, Shad Storhaug (JIRA) <> wrote:

>     [
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
> focusedCommentId=16061424#comment-16061424 ]
> 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. Or...
> Hope I'm helping
> {quote}
> Andy,
> 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
> (v6.4.14#64029)

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