Re: [PATCH] Lua tasks fail to start.
Willy, Here is the single line patch (sans comment). Thanks for the quick response. - Camilo On Mon, Aug 3, 2015 at 9:51 AM, Willy Tarreau w...@1wt.eu wrote: Hi Camilo, On Sun, Aug 02, 2015 at 07:07:28PM -0400, Camilo Lopez wrote: Dearest HAProxy people, I've been trying out 1.6 dev3 with lua support, and trying to start lua tasks seems to not be working. Using this configuration global lua-load /lua/lol.lua debug maxconn 4096 backend shard_b server db01 mysql_shard_b:3306 backend shard_a server db01 mysql_shard_a:3306 listen mysql-cluster bind 0.0.0.0:8001 mode tcp balance roundrobin use_backend shard_b And this lua function core.register_task(function() while true do core.Alert(LOLOLOLOLOL) end end) I'd always get a timeout error starting the registered function. The problem lies as far as I can tell in the fact that is possible for now_ms to not change (is this maybe a problem on my config/system?) That's expected since you can do many things in a single millisecond. until the expiration check happens, in the resume function that actually kickstarts the lua task, making HAProxy think that expiration time for the task is up, if I understand correctly tasks are meant to never really timeout. If the timeout is not set it's indeed set to zero. I'm attaching a tiny patch that fixes it for me, but seems rather naive. It exploits the fact that hlua_timeout_task is set to TICK_ETERNITY, which might or might not be an okay assumption to make moving forward. Your fix isn't naive, it's correct. Timeouts should be considered only when they're set, as is done at many other places. I just think that you should remove the comment justifying this because what you did is the expected behaviour so the explanation becomes confusing as it makes the reader think there's something special there. Thanks, Willy luapatch.patch Description: Binary data
Re: [PATCH] set response line
Hi, Yes the purpose is only to write the correct reason for a given status code. In some systems there are custom status code that are unknown. That is when setting reasons can be useful. Best, Bowen On 7/29/15 9:35 PM, Willy Tarreau wrote: Hi, On Tue, Jul 28, 2015 at 02:57:46PM -0700, Bowen Ni wrote: Hi, I'm submitting a patch that allows rewriting the HTTP response status code and reason phrase. There are two new keywords in 'http-response' that allows you to rewrite them in the native HAProxy config. There are also two new APIs in Lua that allows you to do the same rewriting in your Lua script. Example: Use it in HAProxy config: *http-response set-code 404* Or use it in Lua script: *txn.http:res_set_reason(Redirect)* What is the real purpose of changing the reason ? I see for the status, but the reason ? The reason was removed from HTTP/2 because it's not used, so this rule will simply be ignored on HTTP/2 traffic. If the purpose is only to write the correct reason for a given status code, then I'd rather have a patch with a switch/case covering all known statuses with their fallbacks and emits the corresponding reason. It would be easier to use as set-status would simply set the status and the reason would automatically be adjusted. Thanks, Willy
Re: tcp options
On Mon, Aug 03, 2015 at 08:16:48AM +, zaafar.ta...@gmail.com wrote: Dear Willy, Thank you for the quick response. I wasn???t interested in some specific TCP option. I was interested in differentiation of HAProxy heartbeat handshakes from client request tcp handshakes while connecting to the backend server. So, allowing any option to be forwarded to backend server would do the trick. Normally you want them to be the same otherwise you can end up with a check that works and prod traffic that doesn't work. Up till now I have thought about using (A) transparent proxy mode, (B) separate IP for heartbeat and separate IP for client request or (C) separate port for heartbeat and separate list of ports for client reuqest. However, in option (A) it isn???t possible to load balance traffic from the same subnet, option (B) is the best option I have so far but it requires an additional IP to be allocated to HAProxy and option (C) would limit the number of concurrent connections per backend server. You can also use the addr parameter to force to send health checks to a different IP address. That may fit your needs. Other people simply use a different method in the health check that is not logged. That's why the default method is OPTIONS. Regards, Willy
Re: tcp options
Dear Willy, Thank you for the quick response. I wasn’t interested in some specific TCP option. I was interested in differentiation of HAProxy heartbeat handshakes from client request tcp handshakes while connecting to the backend server. So, allowing any option to be forwarded to backend server would do the trick. Up till now I have thought about using (A) transparent proxy mode, (B) separate IP for heartbeat and separate IP for client request or (C) separate port for heartbeat and separate list of ports for client reuqest. However, in option (A) it isn’t possible to load balance traffic from the same subnet, option (B) is the best option I have so far but it requires an additional IP to be allocated to HAProxy and option (C) would limit the number of concurrent connections per backend server. Regards, zaafar From: Willy Tarreau Sent: Sunday, August 02, 2015 4:14 PM To: zaafar.ta...@gmail.com Cc: haproxy@formilux.org Hello, On Sat, Aug 01, 2015 at 09:23:27AM +, zaafar.ta...@gmail.com wrote: Hello, If client send few additional TCP options (during TCP handshake) to haproxy would HAPROXY respect those options and forward them to the backend server? Is it possible to enable this feature from the configuration file? No it is not possible. HAProxy is a TCP proxy meaning that it uses two separate and independant TCP connections. The options you have on one side may not even be relevant to the other side (eg: MSS values, etc). What do you have in mind, is there a specific option you're interested in ? Regards, Willy
[SPAM] from: Russ Daigle
Hi haproxy http://ismailimpresadecoro.it/wood.php?sit=89nszdnx7kmsbat9aw Russ Daigle rdaigle...@yahoo.com Sent from my iPhone
Digital Media Users
Hi, We maintain the newly updated List Of Digital Media Users with complete contact information. We wanted to check if you would be interested in it as Digital Media Users are one of your major targets and this list could help you in your sales and marketing activities. Please let me know and I shall get back to you with counts, list details and a sample file for your review. Note: We also maintain other industry lists If you are not interested in the Digital Media List, send us your target requirements details like target industry: target geography:___ target job titles: so that we can send you the counts and few samples at no cost. Await your response. Lorretta Getz Business Development Phone : (302)752-4265 If you do not wish to receive any further emails from us, please reply Unsubscribe in the subject line.
Votre �cran 9 fois plus r�sistant
Bonjour, Je vous propose nos tarifs rvendeurs sur nos protections d'écran en verre trempé.
Question about HAProxy with OpenFire
If I setup HAProxy as a load balancer for 3 OpenFire servers which are in a cluster: How does HAProxy know which OpenFire server has more users on it so that it can start sending login requests to the other servers? Does it simply look at CPU usage values (How busy the CPU is) instead of how many users each server is actually handling at any given moment? Thank you Joe Cosmides | Information Technology Director | j...@avatel.usmailto:j...@avatel.us Phone: 813-314-2123 | Fax: 813-699-1964 | www.avatel.ushttp://www.avatel.us/ [cid:image008.png@01D05D6A.16938EB0] [https://de890d560f9c16061c70a7250d678e3746fc316b.googledrive.com/host/0B--N5ngFnhfhdDJkZlNuSnRuTHM/linkedin.png] https://www.linkedin.com/company/avatel-technologies [https://de890d560f9c16061c70a7250d678e3746fc316b.googledrive.com/host/0B--N5ngFnhfhdDJkZlNuSnRuTHM/twitter.png] https://twitter.com/AvatelTweets [https://de890d560f9c16061c70a7250d678e3746fc316b.googledrive.com/host/0B--N5ngFnhfhdDJkZlNuSnRuTHM/facebook.png] https://www.facebook.com/pages/Avatel-Technologies/156191064419?ref=hl [https://de890d560f9c16061c70a7250d678e3746fc316b.googledrive.com/host/0B--N5ngFnhfhdDJkZlNuSnRuTHM/wordpress.png] https://avatel.wordpress.com/
Re: [PATCH] Add log-format variable %HQ, to log HTTP query strings
Hi Aleks,
On Sun, Aug 02, 2015 at 06:55:26PM +0200, Aleksandar Lazic wrote:
Hi Andrew.
Am 31-07-2015 18:21, schrieb Andrew Hayworth:
Since this came up in another thread, it seems reasonable to add a
patch that implements %HQ as a log-format variable to record the HTTP
query string. Leaving the initial '?' is intentional, but I don't feel
strongly one way or another.
How about to use the same function as haproxy?
http://git.haproxy.org/?p=haproxy-1.5.git;a=blob;f=src/proto_http.c;h=5db64b5bf6b0c02dc8d501087bbb94ec320c2c43;hb=HEAD#l11004
find_param_list()
Except that his function performs the lookup into the captured URI, which
is available even at the end of the transaction processing.
(...)
I would also suggest to check
if (!txn-uri) {
before you go further due to the fact that a seach on BADREQ could
never match ;-)
I agree, I found this a bit awkward as well :-)
Regards,
Willy
Re: [PATCH] Lua tasks fail to start.
Hi Camilo, On Sun, Aug 02, 2015 at 07:07:28PM -0400, Camilo Lopez wrote: Dearest HAProxy people, I've been trying out 1.6 dev3 with lua support, and trying to start lua tasks seems to not be working. Using this configuration global lua-load /lua/lol.lua debug maxconn 4096 backend shard_b server db01 mysql_shard_b:3306 backend shard_a server db01 mysql_shard_a:3306 listen mysql-cluster bind 0.0.0.0:8001 mode tcp balance roundrobin use_backend shard_b And this lua function core.register_task(function() while true do core.Alert(LOLOLOLOLOL) end end) I'd always get a timeout error starting the registered function. The problem lies as far as I can tell in the fact that is possible for now_ms to not change (is this maybe a problem on my config/system?) That's expected since you can do many things in a single millisecond. until the expiration check happens, in the resume function that actually kickstarts the lua task, making HAProxy think that expiration time for the task is up, if I understand correctly tasks are meant to never really timeout. If the timeout is not set it's indeed set to zero. I'm attaching a tiny patch that fixes it for me, but seems rather naive. It exploits the fact that hlua_timeout_task is set to TICK_ETERNITY, which might or might not be an okay assumption to make moving forward. Your fix isn't naive, it's correct. Timeouts should be considered only when they're set, as is done at many other places. I just think that you should remove the comment justifying this because what you did is the expected behaviour so the explanation becomes confusing as it makes the reader think there's something special there. Thanks, Willy
