How to force per-location configuration directive presence?
Hello, I'm implementing module which intended to translate particular HTTP-requests into TCP-messages to 3rd party server, and I want to force per-location server address and port presence at post_config stage. For example, having config: LoadModule myproxy_module libmyproxymodule.so MyProxyPort 8080 Location /master SetHandler myproxy MyProxyServer master.example.com /Location Location /slave SetHandler myproxy MyProxyServer slave.example.com /Location I wan't to ensure that all locations handled by myproxy_module have both MyProxyServer and MyProxyPort. And I wan't this check to be done at post_config, because this way I'll can check that httpd.conf is sane, without server restart. For now, I have only one hack-around to do this: 1. implement create_server_config and allocate array inside it 2. at the end of each create_dir_config and merge_dir_config, store result inside aforementioned array (and remove `base' and `add' configs from it) 3. in the post_config I will retrieve server config, iterate over all dir_configs and check their validity Unfortunately this seem to be very ugly solution. So, my question is: how to force each location handled by particular handler to have complete dir_config? -- Thanks in advance, Dmitry
lbmethod and TCP header
Hello everybody, I'm part of a project that involves creating a new loadbalancer method for the proxy module's balancer. Following the round robin example provided with the httpd source code I have registered a proxy_balancer_method that will select which worker is the best. In this method, just like the other ones, I receive the following args: a proxy_balancer *balancer and a request_rec *r. For my method to work I need to access the information in the TCP header. Is it possible, in any way, to do that? If so, how can I access that information (for example, sequence and acknowledgement numbers)? Thank you for your time, Best regards, Ruben Campos.
Re: lbmethod and TCP header
Hi, It's possible have an example of code for pass environment value to mod_rewrite through httpd.conf? Inviato da iPhone
Re: Balancer persist and inherit stuff in trunk
On 06.01.2013 17:48, Jim Jagielski wrote: I had thought that I has responded to that orig email that both below issues where by design but could be adjusted if need be or desired. I have no opinions either way, but to be Used seems more session based and Elected is more long-term statistical. Hmmm, but the Used field should give information about shm slots occupied by configured balancers. Isn't the info (=0) wrong after a restart? Concerning the long term statistical values I'm undecided like you, but I think we should handle them in a consistent way, so traffic and elected should either be both persisted or both reset. Regards, Rainer On Jan 5, 2013, at 1:41 PM, Rainer Jung rainer.j...@kippdata.de wrote: On 04.01.2013 19:48, Jim Jagielski wrote: Have people had a chance to test, review and try the balancer persist and inheritance stuff in trunk? I want to make sure that we have some level of verification and agreement there before I work on the backports for 2.4 ;) I didn't see any changes with respect to two of my original comments: The Used counters (number of shared mem slots) in balancer manager drops to 0 after restart/reboot´with persist on. This seems strange. Not that Used does *not* have anything to do with request counting. Second the Elected counter is persisted but e.g. the traffic counter's not. This seems somewhat inconsistent. I have no strong opinion whether to persist statistics or not, but we might want to behave consistently. I did not observe any functional changes after my Mail from Dec. 14, right? Regards, Rainer
Re: Apache Web Socket Support
On Sun, Jan 6, 2013 at 10:20 PM, Welly Madya Putra Tambunan welly.tambu...@petrolink.com wrote: Hi Guys, I'm a new member of this mailing list and interested knowing is there any plan supporting Websocket for Apache ? There has not been a lot of interest on this list. Do you want to proxy websockets or terminate websockets in Apache? Based on my search, i found a module to do this, but it isn't updated yet. https://github.com/disconnect/apache-websocket Any chance that the module will be included in Apache ? There has been no discussion of this particular module. Also i found in StackOverflow conversation that Apache httpd wasn't design to maintain persistent connection, is that true ? http://stackoverflow.com/questions/11334320/using-websocket-on-apache-server This doesn't really make much sense as HTTP uses persistent connections.
Re: event mpm and mod_status
I see that event mpm uses a worker queue that uses a condition variable, and it does a condition variable signal when something is pushed onto it. If all of the cpu cores are doing useful work, the signal is not going to force a context switch out of a thread doing useful work, the thread will continue working until it's used up it's timeslice, as long as it doesn't end early because it becomes blocked on i/o or something like that. So, in that case, the first thread to finish serving it's request and gets to ap_queue_pop_something(worker_queue...) will get the item on the queue, and it will have hot caches. On the other hand, if only some of the cpu cores are active, but the threads that are active are busy in the middle of a request, the condition variable signal will wake up one of the idle threads, the thread will be scheduled onto an idle core, and that thread can start doing useful work. That thread may have colder caches, but the other cores were busy doing useful work any way, so it's worth activating this thread on an idle core. Also, if a worker thread is idle on waiting on ap_queue_pop_something(worker_queue...), and the thread was unscheduled by the OS process scheduler, when you wake it up again, the OS process scheduler won't necessarily schedule it on the same cpu core it was on before. So, it won't necessarily have a warm cache after you wake it up again. You're only guaranteed a warm cache if the thread remains scheduled by the OS. The current queue/condvar implementation favors sending new requests to threads that remain scheduled by the OS. On Sat, Jan 5, 2013 at 9:37 AM, Jim Jagielski j...@jagunet.com wrote: +1... a lot of little improvements can result in a BIG improvement. On Jan 5, 2013, at 8:34 AM, Graham Leggett minf...@sharp.fm wrote: On 05 Jan 2013, at 2:05 AM, Stefan Fritsch s...@sfritsch.de wrote: For 1., a better thread selection would definitely be a win. For 2. and 3., it is less obvious. +1. Just because in some cases a cache might not help, doesn't mean we shouldn't take advantage of the cache when it will help. Regards, Graham --
Re: event mpm and mod_status
On Monday 07 January 2013, Daniel Lescohier wrote: I see that event mpm uses a worker queue that uses a condition variable, and it does a condition variable signal when something is pushed onto it. If all of the cpu cores are doing useful work, the signal is not going to force a context switch out of a thread doing useful work, the thread will continue working until it's used up it's timeslice, as long as it doesn't end early because it becomes blocked on i/o or something like that. So, in that case, the first thread to finish serving it's request and gets to ap_queue_pop_something(worker_queue...) will get the item on the queue, and it will have hot caches. On the other hand, if only some of the cpu cores are active, but the threads that are active are busy in the middle of a request, the condition variable signal will wake up one of the idle threads, the thread will be scheduled onto an idle core, and that thread can start doing useful work. That thread may have colder caches, but the other cores were busy doing useful work any way, so it's worth activating this thread on an idle core. But on the idle core, it may make a difference which thread is used. A common pattern with event mpm is that a work thread does only a very small piece of work when writing some additional data to the network during write completion. It will then block again until ap_queue_pop_something(worker_queue...) returns with some more work to do. The likelyhood of warm caches is much higher if the same thread (or the same set of a small number of threads) always does these small bits of work, compared to the case that all (e.g. 30) idle threads each doing a small piece of work in a round robin fashion. Of course, one needs to do real benchmarks when trying to optimize this. Also, if a worker thread is idle on waiting on ap_queue_pop_something(worker_queue...), and the thread was unscheduled by the OS process scheduler, when you wake it up again, the OS process scheduler won't necessarily schedule it on the same cpu core it was on before. So, it won't necessarily have a warm cache after you wake it up again. You're only guaranteed a warm cache if the thread remains scheduled by the OS. The current queue/condvar implementation favors sending new requests to threads that remain scheduled by the OS.
Re: Balancer persist and inherit stuff in trunk
On Sunday 06 January 2013, Jim Jagielski wrote: We could, but it's not my personal pref as RM... After all, ApacheCon will be here before we know it :/ That's probably true ;) FWIW, I see the this dynamic nature of 2.4 as much as a killer feature as the increased performance as related to comparisons between httpd and other web-servers out there, including the fanboys latest flavor. Hence my desire to try to have this in asap, so I can re-dive into the optimized event/simple- MPM hybrid I was working on, which itself I hope to have done by ACNA2013. BTW, I don't believe the increased performance in 2.4 should be overrated. It gives some nice improvements with some workloads, but there are still plenty of cases where scalability remains bad (e.g. ssl or long-lasting proxy-requests).
Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c
On Sunday 06 January 2013, Daniel Lescohier wrote: I'm not sure we should include memory barriers inside the apr_atomic_read32 and apr_atomic_set32 functions, because you don't necessarily need a full memory barrier on each read or set. Instead, perhaps we should add three functions to APR: 1. apr_atomic_rmb(): read memory barrier. 2. apr_atomic_wmb(): write memory barrier. 3. apr_atomic_mb(): full memory barrier. Introducing new functions into APR may not be the perfect solution for this problems because there will be some reluctance to bump the minimum apr version required for httpd, especially for 2.2.x. Also, writing such functions for all supported architectures and compilers is quite some effort. In any case, if we introduce new atomic and/or barrier functions, I would be in favor of something that aligns with a subset of the C11 atomic API. An alternative that would work without changes to apr would be per- thread caches for cached_explode(). This would at least not be less efficient than the current code is with mpm-prefork. Or one could do that only if compiled with an apr that does not have the new barrier functions...
Re: Apache Web Socket Support
Thanks Eric for the response, Do you want to proxy websockets or terminate websockets in Apache? What's the preferable approach ? Should we integrate the module to the Apache Server or proxy the connection to a dedicated websocket server ? This doesn't really make much sense as HTTP uses persistent connections. I quote this from stackoverflow http://stackoverflow.com/questions/11334320/using-websocket-on-apache-server However, the fundamental problem is that Apache wasn't built with maintaining many persistent connections in mind. It, along with PHP, is built on the idea that requests are made and responses are quickly sent back. This means that resources can very quickly be used up if you are holding requests open and you're going to need to look into horizontal scaling pretty quickly. So it is possible for Apache Architecture to add another module for handling Websocket ? Without sacrificing the performance and scalabilty ? Sorry for the question, i'm still new to Apache and very interested knowing how it can accomodate websocket. Cheers On Sun, Jan 6, 2013 at 10:20 PM, Welly Madya Putra Tambunan welly.tambu...@petrolink.com wrote: Hi Guys, I'm a new member of this mailing list and interested knowing is there any plan supporting Websocket for Apache ? There has not been a lot of interest on this list. Do you want to proxy websockets or terminate websockets in Apache? Based on my search, i found a module to do this, but it isn't updated yet. https://github.com/disconnect/apache-websocket Any chance that the module will be included in Apache ? There has been no discussion of this particular module. Also i found in StackOverflow conversation that Apache httpd wasn't design to maintain persistent connection, is that true ? http://stackoverflow.com/questions/11334320/using-websocket-on-apache-server This doesn't really make much sense as HTTP uses persistent connections. Welly Tambunan .NET Software Developer Petrolink Services Indonesia Office Phone : +62 21 252 2203 Indonesia Cell : +62 812 8421 0208 Fax : +62 21 252 2205 This email is the property of Petrolink International. This transmission may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please contact the sender and delete the material from any computer immediately. Thank you
