I think the Smart Proxy is sufficiently different that it’s wishful thinking that they really align. We could make it that way, but it’s a larger investment.
Is this still true? Remember that (without a significant investment) we can’t use multi process. There are singleton parts without a proper inter-process communication method.
I can honestly say I’ve never hit that. Then again, I don’t think I ever really enabled HTTP.
I did open a PR to do this:
It’s not complete yet and I think we should refactor the authentication into proper Rack middleware. Probably even before we move to Puma.
It also turns out that Smart Proxy Dynflow Core uses these methods which I thought were internal. That means it needs to happen in tandem.
In summary: I think it’s a good goal, but a significant investment and I’m not sure it’s worth it at this point.
Would you mind expanding for the wider audience, who probably are not tuned into the intricacies of the Smart Proxy, what makes it sufficiently different to negate this?
I would love it if, and I know it’s been explained in different comments but not a succinct centralized explanation, someone could lay out the exactness of what prevents a multi-process style deployment. For example, what is an example of a Singleton part that prevents this. Is it core design or how a plugin got implemented?
This was mentioned in the PR but I am not aware of these. I’d be curious even if we choose not to go down the Puma path.
At first, I thought that ISC observer would be a problem but then I realized that multiple processes actually need multiple observers to watch file changes so actually no work needed here.
It was more appealing two years ago than today, agreed.
Comparing performance of one of the bottlenecks (Candlepin proxy endpoint for example) between the two. For small scale Webrick can do just fine, but I’d expect multiproces design to scale better under load.
