Hi Matt,
good questions, please see inline...
> Is this reasonable? My understanding was that a TCPNIOTransport is a
> resource (incl. thread pool, memory manager, etc) which can be
> shared amongst multiple NetworkListeners, and other Grizzly based
> protocol implementations. Clearly the NetworkListener implementation
> is contradicting my understanding since it assumes ownership of the
> transport (these are just two examples of methods doing this, there
> are others - e.g. configureThreadPool, pause, resume, etc).
Right, TCPNIOTransport is an abstraction, which has associated
resources like thread-pool, selector-threads etc, which is being
shared among children TCPNIOConnections. But again there could be
several TCPNIOTransports created, which will have own resources (may
be shared with other transports), which will be used by its children
TCPNIOConnections.
In http-server implementation, by default, each NetworkListener is
associated with own TCPNIOTransport, so they work independently.
>
> Typically, if I am developing an application which, for example,
> exposes multiple front ends such as HTTP and HTTPS (as well as LDAP
> and LDAPS in my case) I will want these front ends to share the same
> TCPNIOTransport and its associated resources, e.g. its thread pool.
Hmm, I'd expect opposite :)
IMO it depends on a usecase, so I agree we have to make sure it's
possible to configure shared transports as well.
> This is even more significant for proxy implementations which of
> course act as both server (frontend) and client (backend)
> simultaneously.
I think it's not a problem, inside the
HttpRequestProcessor.service(...) you should have access to a
Transport, so you can reuse it to create client connections.
> I appreciate that an API should permit each front-end / back-end to
> use its own transport, but presumably sharing should be allowed as
> well, shouldn't it?
Agree, it would be good.
> All this leaves me a bit confused about the ownership model and life-
> cycle of various core Grizzly classes:
> What is the ownership model of a TCPNIOTransport? Note that the
> default transport factory uses the same thread pool for all
> transports that it creates, so shutting down one transport will
> shutdown the thread pool for all transports.
Agree, it's a bug. If thread-pool was assigned by factory - Transport
shouldn't shut it down.
> What is the recommended approach to developing a server
> implementation which has multiple front-ends and/or backends and
> wishes to share the same thread pool and other infrastructure? A
> more fundamental question is: what things should be shared and what
> things should not? By "things" I mean selectors, thread pools,
> memory managers, etc.
IMO, it might not be a good idea to share a thread pool (though we
should make this possible) among multiple front-ends, the same
situation with selector threads etc.
> Finally, on an unrelated note, I spotted something else while
> looking at the NetworkListener implementation: is it possible to
> create a NetworkListener with custom filters inserted into the
> filter chain (e.g. IdleTimeoutFilter)? At the moment it looks like
> if I want to do this I must cut 'n' paste the content of
> org
> .glassfish
> .grizzly.http.server.HttpServer.configureListener(NetworkListener))
> and customize as needed, which seems a bit annoying. Admittedly, I
> can't see a generic way of allowing custom filters, since it would
> require some mechanism for specifying where the custom filters
> should be inserted.
Right. HttpServer is just a wrapper class, which is responsible for
configuring Transport, FilterChain etc and hide the complexity. So
currently FilterChain is being shared just for advanced usecases as an
extension point. We can add some finalizeFilterChain() method, which
developers will be able to override and customize FilterChain.
> As a bit of background, my ultimate goal is to implement a server
> application which exposes multiple listener front-ends (e.g. HTTP,
> HTTPS, LDAP, LDAPS, etc) as well as having proxy (i.e. client)
> functionality in the back-end for accessing potentially many remote
> servers using different protocols. I would like all these Grizzly
> based components to share the same thread pool and may be the
> selectors too (and other infrastructure such as memory support, etc).
Sounds very interesting!
As I told I'm not sure how good is the idea to share resources like
thread-pool and selector threads among different listeners, but admit
that we need to make this possible.
Currently I think we need to provide more functional HttpServer
builder mechanism, so developers will be able to not just create a
simple HttpServer, but be able to customize different resource
sharing, FilterChain customizer etc.
Thanks.
WBR,
Alexey.
>
> Cheers :-)
>
> Matt
>