hi, this patch should do the trick https://github.com/ChicagoBoss/ChicagoBoss/pull/472
a month ago i made this patch for a custom router, it work for me and it s still compatible with the actual system. you can experiment your own route system: compiled module routes from route file, from ets .... chan. 2014-06-10 10:55 GMT+08:00 Jesse Gumm <[email protected]>: > The CB approach for gen_server is the standard default way of > implementing a server. It's one of those things that's good enough > all the way until it isn't. If the requests are numerous enough, or > the work done within each request is slow enough, a naked gen_server > becomes a bottleneck. > > By "routing handler", I mean something like a module with the exported > function route(Path), which would be expected to return roughly the > same format as the current routes.config file. > > Basically, instead of doing an ets lookup for each request, it would > call boss_route_handler:route(Path), which would "do something", and > return a route. > > Then, if your app needed custom routes, you could create your own > modue osmething like this: > > -module(my_boss_router). > -export([route/1]). > -behaviour(boss_router_handler). > > route("/") -> [{controller, whatever}, {action, whatever}]; > > route("/some/other/" ++ Action) -> [{controller, some_other}, {action, > Action}]; > > route(Path) -> > case re:run(".jpg$", Path) of > match -> [{controller, special_image_controller}, {action, > process}, {file, Path}]; > nomatch -> do_something_else > end. > > It gives you a lot more flexibility than screwing around with regular > expressions and at the same time takes out one more gen_server to > serve as a bottleneck. And for backwards compatibility, the current > method of parsing the config file will remain as the default handler. > > Thoughts? > > > On Mon, Jun 9, 2014 at 9:09 AM, rambocoder <[email protected]> wrote: > > Can you elaborate on "routing handler" some more? > > > > I've been digging into Cowboy code and the way its routing works, is that > > during an initial request, there is 1 ETS lookup of the routing table > which > > is a List, and then that List is handed off to the request, and the > request > > then decides which handler to call. There is a gen_server inside of ranch > > which controll's access to the ETS table but the actual logic and > > calculation like this > > > > > https://github.com/ChicagoBoss/ChicagoBoss/blob/master/src/boss/boss_router_controller.erl#L151 > > > > is being done inside of the each individual request process. > > > > While in CB, this routing logic is being done inside of the single > > boss_router_controller process for all requests > > > > > https://github.com/ChicagoBoss/ChicagoBoss/blob/master/src/boss/boss_web_controller_handle_request.erl#L237 > > > > I guess these are just different architectures, very interesting stuff. > > > > -rambocoder > > > > > > > > On Monday, June 9, 2014 9:52:48 AM UTC-4, Jesse Gumm wrote: > >> > >> I've been tinkering in the boss router a bit lately, and you're right > >> about how the use of a gen_server guarantees atomicity. > >> > >> But at the same time, a gen_server does present a potential bottleneck. > >> > >> Frankly, I've been thinking the router controller might benefit from > >> having the router configuration either compiled into an actual module > (like > >> how erlyDTL compiles html to a module), or using a routing handler, > either > >> of which effectively removes that potential for a bottleneck, and > reloading > >> the module with Erlang ensures atomic changes to the routing system. > >> > >> Personally, I like the routing handler idea myself, as it requires less > >> screwing around with compiler magic and also would make the router more > >> flexible (more powerful than just regular expression matching). But it > also > >> makes the configuration a little longer. I still think it's a worthwhile > >> tradeoff. > >> > >> -Jesse > >> > >> -- > >> Jesse Gumm > >> Owner, Sigma Star Systems > >> 414.940.4866 || sigma-star.com || @jessegumm > >> > >> On Jun 9, 2014 8:16 AM, "rambocoder" <[email protected]> wrote: > >>> > >>> An OTP question... > >>> > >>> In boss_controller.erl which is a gen_server instance, let's say > multiple > >>> processes send "reload" atom to the gen_server > >>> > >>> > >>> > https://github.com/ChicagoBoss/ChicagoBoss/blob/master/src/boss/boss_router_controller.erl#L52 > >>> > >>> which does a sequence of steps: > >>> > >>> > >>> ets:delete_all_objects(State#state.routes_table_id), > >>> ets:delete_all_objects(State#state.reverse_routes_table_id), > >>> ets:delete_all_objects(State#state.handlers_table_id), > >>> load(State), > >>> > >>> > >>> do the "reload" messages just que up and handle_call acts like a mutex > >>> around these sequential steps? > >>> > >>> I was thinking on how to speed up routing in boss_controller, does it > >>> need to be a gen_server with all the contention around 1 process > because all > >>> the routing data is stored in ETS, but then I notice that the > >>> boss_router_controller gen_server acts as a mutex to provide atomic > >>> manipulation of the routing tables in ETS. > >>> > >>> Is boss_router_controller the best way to store and access routing > info? > >>> > >>> Cheers, > >>> > >>> -rambocoder > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "ChicagoBoss" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > an > >>> email to [email protected]. > >>> > >>> Visit this group at http://groups.google.com/group/chicagoboss. > >>> To view this discussion on the web visit > >>> > https://groups.google.com/d/msgid/chicagoboss/99d3f555-d07f-4ae2-9582-da818856216e%40googlegroups.com > . > >>> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "ChicagoBoss" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > Visit this group at http://groups.google.com/group/chicagoboss. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/chicagoboss/10a68392-54a4-40ad-b7f7-0835f3accc4d%40googlegroups.com > . > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Jesse Gumm > Owner, Sigma Star Systems > 414.940.4866 || sigma-star.com || @jessegumm > > -- > You received this message because you are subscribed to the Google Groups > "ChicagoBoss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at http://groups.google.com/group/chicagoboss. > To view this discussion on the web visit > https://groups.google.com/d/msgid/chicagoboss/CAPTXyXernM9JOVSJKjTJU63gwmJ9Oo7QwRaDbVB3tRfL_sBkxg%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ChicagoBoss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at http://groups.google.com/group/chicagoboss. To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAB-OfhkBzKuSEyoorShUGCYXiDKtnLx5FYGZsp%3D7YN6zoKgeNQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
