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.
