How complex is the configuration and how much data? Usually you would use an external data store in this sort of situation which processes would query for configuration.
> On 18 May 2021, at 6:33 pm, Howie Lung <[email protected]> wrote: > > 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] >> <applewebdata://1ABF2ECD-6F73-4770-A963-E698961F51FD>> 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] >> <applewebdata://1ABF2ECD-6F73-4770-A963-E698961F51FD>. >> 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/60aa339f-82f2-491b-b78f-5435b1d88e35n%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/60aa339f-82f2-491b-b78f-5435b1d88e35n%40googlegroups.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/6BA1BC8D-BF5E-4115-9F8D-C423F6CD0A93%40gmail.com.
