<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="gmail_quote">Hi Jay,<br>
<br>
On 2/3/2015 8:10 AM, Jay McCarthy wrote:
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span class=""> On Mon, Feb 2, 2015 at
5:06 PM, George Neuner <a moz-do-not-send="true"
href="mailto:gneuner2@comcast.net" target="_blank"><gneuner2@comcast.net></a>
wrote: </span>
<blockquote type="cite">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. </blockquote>
<span class=""> That sounds like a lot of servlets. I think
I would try to consolidate.<br>
</span></blockquote>
<br>
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.</blockquote>
<div><br>
</div>
<div>No, I don't think there's a problem. It just seems mentally
exhausting to my feeble mind :)</div>
</blockquote>
<br>
</div>
<gripe><br>
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. <br>
<br>
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 <span
class="moz-smiley-s2"><span> :-( </span></span> (I use it
wherever I can), and thus I'm writing server middleware to support a
(cooperatively developed) browser application.<br>
</gripe><br>
<br>
<br>
<blockquote
cite="mid:CAJYbDamAhGQcYMS0hR_V-Ei9gdrPKn3tQG6ro1vCHJbv9uQ5sw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<blockquote type="cite"> Does switching to the web
language impact using serve/servlet and
dispatch-rules? </blockquote>
You can still use those, although there is only a
benefit when you are using continuations via
send/suspend and send/suspend/dispatch.<br>
</blockquote>
<br>
</span> I'm sorry, but I'm not following. <br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAJYbDamAhGQcYMS0hR_V-Ei9gdrPKn3tQG6ro1vCHJbv9uQ5sw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">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:
<div><br>
</div>
<div>(require</div>
<div> (prefix-in servlet1: "servlet1.rkt")</div>
<div> (prefix-in servlet2: "servlet2.rkt"))</div>
<div><br>
</div>
<div>(define (meta-servlet req)</div>
<div> (match (request-uri req)</div>
[(list "servlet1" _ ...) (servlet1:start req)]</div>
<div class="gmail_quote"> [(list "servlet2" _ ...)
(servlet2:start req)]))</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">(module+ main</div>
<div class="gmail_quote"> (serve/servlet meta-servlet))</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<tt> (define-values (main-dispatch main-url)</tt><tt><br>
</tt><tt> (dispatch-rules</tt><tt><br>
:<br>
<lots of rules><br>
:<br>
</tt><tt> ))</tt><tt><br>
</tt><tt> :<br>
(serve/servlet main-dispatch</tt><tt> ... )</tt><tt><br>
</tt><br>
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.<br>
<br>
George<br>
<br>
</body>
</html>