Apology for the problem ambiguous, the problem that I want to solve is about data consistency.
As mentioned, my environment has five processes (each process contains one thread). My application has a property that is stored in memory and the data is by reading a configuration file. According to the behavior of multiple processes, every process maintains a different property. Hence, the property is changed on process A, but the property on process B will not. I have two requirements, revising the configuration fine and reloading the property on all processes. According to the two requirements, I have a draft of implementation as below: At first, send an HTTP request to an arbitrary process that can revise the configuration file and reload the property. After that, the process sends HTTP requests to another process for asking them to reload. However, the process scheduler seems is not the round-robin which causes the property is not consistent. In my opinion, the solution is not the best method because it is suffered from data inconsistency. Thank you for your prompt reply, Howie Graham Dumpleton 在 2021年5月18日 星期二上午11:28:35 [UTC+8] 的信中寫道： > Is there a specific problem you are trying to solve by wanting to override > how it works? > > There is no scheduler to speak of that you can override. > > What happens is that each of the daemon process when using daemon mode > uses a cross process mutex lock on being able to accept the next > connection. A process will only attempt to acquire the cross process mutex > lock if they have a spare thread available ready to handle a request. > > This mechanism ensures you don't end up with the greedy acceptor problem > where a process accepts connections it isn't in a position to handle > immediately, but also avoids the thundering heard problem. > > Since the cross process mutex lock only comes into play for the accept > phase of a handling the connection and is then released, even though that > same process may still have idle threads in its thread pool, it is more > likely that a different process which is more ready gets the lock the next > time. The result of this is that acceptance of requests should be > relatively balanced across the processes. > > That you are even asking suggests you think you have a problem where you > need more control. If your overall application handles various workloads > (via request handlers), there are perhaps better ways of dealing with it by > partitioning the URL namespace and directing requests to different daemon > process groups, each configured differently for that subset of requests > directed to it. > > So as already asked, if you can explain what the problem is that you think > you have, I can perhaps suggest more appropriate ways of dealing with it. > > Graham > > On 17 May 2021, at 10:02 pm, 龍世豪 <[email protected]> wrote: > > Dear Dumpleton, > > I have some questions about mod_wsgi. Could you help me to understand the > concept of the module, thanks! > > I enable the multiple process (five processes) to run the WSGI > application. When it receives an HTTP request then a process will execute > the application. Which process scheduler (e.g. round-robin, FIFO, ...) is > used, and how the mod_wsgi choose the next process? And can I change the > process scheduler by configuration? > > Best wishes, > Howie > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/CADWas%3DgSFgfsnnSq7fCUeg-wjb%3D1RiWD0Nknyapm1Wb2AquFHw%40mail.gmail.com > > <https://groups.google.com/d/msgid/modwsgi/CADWas%3DgSFgfsnnSq7fCUeg-wjb%3D1RiWD0Nknyapm1Wb2AquFHw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/60aa339f-82f2-491b-b78f-5435b1d88e35n%40googlegroups.com.
