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. For more options, visit https://groups.google.com/d/optout.
