if i recall , the last commit was the missing part, it come after i closed the pull, and i forgot to reopen it until i saw your thread about chicagoboss router. cb folk can start to hack for a better routing system, i guess the best should be to compile route file to an erlang module.
chan. 2014-06-10 20:43 GMT+08:00 Jesse Gumm <[email protected]>: > Thanks Chan, > > You had closed the request saying it needs more work. But I see you've > reopened it without any changes. > > What should I be wary of? > > -- > Jesse Gumm > Owner, Sigma Star Systems > 414.940.4866 || sigma-star.com || @jessegumm > On Jun 10, 2014 1:09 AM, "chan sisowath" <[email protected]> wrote: > >> 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 >> <https://groups.google.com/d/msgid/chicagoboss/CAB-OfhkBzKuSEyoorShUGCYXiDKtnLx5FYGZsp%3D7YN6zoKgeNQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> 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/CAPTXyXcrHop94kaw6RPPwGM8U7BRNaDWNt1%3D7WcUnEFCV5uEgg%40mail.gmail.com > <https://groups.google.com/d/msgid/chicagoboss/CAPTXyXcrHop94kaw6RPPwGM8U7BRNaDWNt1%3D7WcUnEFCV5uEgg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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-Ofhk_TenzO%2BdwbLaPNKu2ihB9mCvLNrVroxsXSs5H%2BZSyqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
