Hi,

My data are not located in a configuration file, all data can be updated in real-time without reloading. A single POST request triggers update of the information by the worker that handles the request and all workers can then use updated information simultaneously.

There may be possibilities to bypass the issue but so far, I’d like to understand why only this specific piece of data is lost, where everything else is kept.

Regards,
Thierry

De : Sergey Brester [mailto:serg.brester@sebres.de]
Envoyé : mercredi 22 juin 2016 11:48
À : nginx-devel@nginx.org
Cc : MAGNIEN, Thierry
Objet : Re: [module dev] PCRE compiled code lost at reload


A little bit off-topic, but which benefits you think, you will get using cross process compiled regexp?

The compiling of regex is normally fast operation, that will be done only once (even jit), and can be done in each worker.
What I cannot imagine, is the sharing of the result of regexp execution. But not the regexp self.
Regards, sebres.

22.06.2016 11:31, MAGNIEN, Thierry wrote:

Hi,



I'm experiencing a strange behavior and I wonder if I'm missing something obvious...



I've developed a module and I use shared memory and slab allocations to keep data unique across workers and have data survive a reload.



Everything works fine except one single thing: PCRE compiled codes (ngx_regex_compile_t->regex->code).



To be more precise, at reload, in my module init function, I recompile some of the PCRE if they have changed, still using shared memory. What I notice is that, just after init module function has returned, all dying workers lose PCRE compiled code (regex->code = 0), where all new created workers correctly get new compiled code.



I tried to use my own pcre_malloc function in order to be sure memory is allocated in shared memory (and this *is* the case), but without success.



So any help is welcome: does anyone have a clue about why only those data are "lost" by dying workers ?



Thanks a lot for your help,

Thierry Magnien



P.S.: I can't exhibit code for confidentiality reasons but if no one has a clue, I'll try to write a very simple module, only to exhibit this behavior.



_______________________________________________

nginx-devel mailing list

nginx-devel@nginx.org<mailto:nginx-devel@nginx.org>

http://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel