boss_router_controller and ETS tables

[rambocoder]

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

[Jesse Gumm]

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

--
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 chicagoboss...@googlegroups.com.
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.

[rambocoder]

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

[Jesse Gumm]

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?

> https://groups.google.com/d/msgid/chicagoboss/10a68392-54a4-40ad-b7f7-0835f3accc4d%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

[chan sisowath]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAPTXyXernM9JOVSJKjTJU63gwmJ9Oo7QwRaDbVB3tRfL_sBkxg%40mail.gmail.com.

[Jesse Gumm]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAB-OfhkBzKuSEyoorShUGCYXiDKtnLx5FYGZsp%3D7YN6zoKgeNQ%40mail.gmail.com.

[chan sisowath]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAPTXyXcrHop94kaw6RPPwGM8U7BRNaDWNt1%3D7WcUnEFCV5uEgg%40mail.gmail.com.

[Jesse Gumm]

Thanks, I'll have a look. That would certainly save me a fair amount of work!

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.