Thanks, I'll have a look. That would certainly save me a fair amount of work!
On Tue, Jun 10, 2014 at 10:07 PM, chan sisowath <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/chicagoboss/CAB-Ofhk_TenzO%2BdwbLaPNKu2ihB9mCvLNrVroxsXSs5H%2BZSyqQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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/CAPTXyXcG_Fs8RvWLMpwWPb5t05QSDNFQhjO9jRTMZYa4fF8%2B6g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
