The configuration size is approximately equal to 1KB and it has approached 500 pairs (key, value).
I use the property to store configuration because I concern the io action(reading) will cause some unknown leaks. In fact, my first draft of implementation is requiring each process to reload the configuration at first when they accept a connection. Follow your suggestion, this method seems is the best method for my achievement. Thanks for your help, Howie Graham Dumpleton 在 2021年5月18日 星期二下午4:47:52 [UTC+8] 的信中寫道： > 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]> 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 > > <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/6dbb7298-d16f-49f9-95f9-a41b3274f7b0n%40googlegroups.com.
