You probably thought of this, but could you hand the ports themselves
over to the worker places after the dispatch but before any other
processing happened? Or maybe just make each place run the entire
server and then hand the ports over before dispatching and dispatch
inside each worker place?
Robby
On Tue, Dec 1, 2015 at 5:18 PM, George Neuner <gneun...@comcast.net> wrote:
> Hi all,
>
> I'm not sure exactly how to phrase my questions, so let me give a bit of
> background.
>
> I have a fairly large (and growing) web middleware application that uses
> serve/servlet and currently exposes about 90 function URLs, all of the form
> "/api/<category>/<function>". The application grew precipitously and right
> now there is a lot of duplication in the code - there are many instances of
> groups of functions within a "category" that can be implemented via a common
> parameter driven function. I was hoping to refactor to use symbol-arg
> dispatch here practical.
>
> I know the code can be refactored that way. The problem is the "practical"
> part.
>
>
> There are a small number of heavily used URL functions which I would like to
> separate out into a "place" which can be replicated to take advantage of
> multiple cores. I have some good reasons [not relevant here] for not
> wanting to use separate processes.
>
> Within a single servlet instance I know that dispatch rules are evaluated in
> order: e.g., in
>
> :
> [ ("api" "foo" "static") #:method "get" do-static ]
> [ ("api" "foo" (symbol-arg) #:method "get" do-dynamic ]
> :
>
> there is no problem handling "/api/foo/static" separately from other foo
> related URLs
>
>
> However, continuing with this example, if do-static were moved into a
> separate place listening on the same port, then the symbol-arg version might
> erroneously capture and fail a request for the "static" version.
>
>
> Making the places listen on separate ports is logistically complicated. My
> application hides behind Apache, which would need reconfiguration for every
> "special" ProxyPass URL whenever the application changed how it dispatched.
> Although possible, mucking with Apache is inconvenient and yet-another-thing
> to remember to do. It would be better if everything could be handled
> entirely within the Racket application.
>
> I thought of keeping all the dispatch in one place, handing off specific
> functions to "worker" places. But that too is problematic: the application
> is, in part, a specialized search engine ... the functions I want to
> separate can, and do, produce large amounts of data that would be
> impractical to relay through a common dispatcher place.
>
> I thought of passing the TCP port to the worker place so it could respond
> directly. I know the port is accessible inside response/output, but in that
> context it seems like it might be difficult to use a place(d) function to
> generate the response data. [Maybe not, I haven't tried it, but I'm
> concerned about trapping / handling / logging errors.]
>
>
> It seems to make the most sense to have places dispatch their own set of
> requests. However, if I want them to use the same listen port, it appears
> that I have to fully enumerate dispatch rule URLs - negating the possibility
> of using symbol-arg dispatch to handle commonalities. Obviously I can
> dispatch to stubs that redirect to a common function where possible, but it
> seems like there should be a less convoluted solution.
>
> Am I missing something (obvious or not) ? Other, better ideas?
>
>
> In any event, I thank everyone for "listening". Just venting sometimes is
> helpful. :-)
> George
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
