Hi Jay,
On 2/3/2015 8:10 AM, Jay McCarthy wrote:
On Mon, Feb 2, 2015 at 5:06 PM, George Neuner <gneun...@comcast.net>
<mailto:gneun...@comcast.net> wrote:
there are 43 servlets and counting, plus several auxiliary threads
and a large(ish) connection pool. Probably the number of servlets
will double before I'm done.
That sounds like a lot of servlets. I think I would try to consolidate.
Are you thinking that there might be problems with having many
servlets? The only issue I've seen was a one time situation where
the application clearly was running background tasks but stopped
responding to http requests.
No, I don't think there's a problem. It just seems mentally exhausting
to my feeble mind :)
<gripe>
In general I don't like browser interfaces - particularly for database
applications which often have complex 2-way communication patterns with
the server. Although there are exceptions, in general browser apps are
unwieldy and inefficient, and they require added middleware components
to get anything done. Even if the middleware does nothing else but
relay communication to/from the database, it still is needed to protect
the database against (simple) hacking of the browser application code.
I'd always prefer to deliver a proper (compiled) desktop client for a
database app, but platform independence is an issue. Java is a
non-starter in many businesses, and Racket is mostly unknown :-( (I use
it wherever I can), and thus I'm writing server middleware to support a
(cooperatively developed) browser application.
</gripe>
Does switching to the web language impact using serve/servlet
and dispatch-rules?
You can still use those, although there is only a benefit when
you are using continuations via send/suspend and
send/suspend/dispatch.
I'm sorry, but I'm not following.
The Web language only makes using the functions send/suspend and
send/suspend/dispatch different. If you don't use those two functions,
there is no reason to use the Web language.
Got it! I misunderstood you to mean that serve/servlet and dispatch
were only useful if you use continuations ... which, naturally, didn't
make any sense.
I think what I would do is write one server that is started with
serve/servlet where the servlet function (NB: An annoying thing about
the web-server is that in the old days a "servlet" was a file that
provided a (-> request response) function but now I think of it as
just the function because things like serve/servlet allow those to
come from anywhere) that implemented a simple dispatching to the other
logical servlets. Something like this:
(require
(prefix-in servlet1: "servlet1.rkt")
(prefix-in servlet2: "servlet2.rkt"))
(define (meta-servlet req)
(match (request-uri req)
[(list "servlet1" _ ...) (servlet1:start req)]
[(list "servlet2" _ ...) (servlet2:start req)]))
(module+ main
(serve/servlet meta-servlet))
This would mean that from the WS's perspective there is exactly one
servlet, so you would never have multiple instances, namespaces, or
anything like that.
Perhaps I'm missing something - maybe a terminology problem: perhaps
what I'm calling "servlets" you are thinking of simply as "threads" in
the server? Your example looks very similar to what I'm doing now with
dispatch-rules per some program example you pointed me to several months
ago.
(define-values (main-dispatch main-url)
(dispatch-rules
:
<lots of rules>
:
))
:
(serve/servlet main-dispatch... )
I know that this permits overlapped handling of multiple requests and so
multiple instances of any given dispatched function can be running
concurrently (in separate threads). Which is what I want. I certainly
don't want to do anything that would jeopardize concurrent request
handling. If anything, I'll need to go to multiple cores at some point.
George
____________________
Racket Users list:
http://lists.racket-lang.org/users
