Hi Willy,
I got a compile error on Freebsd while doing up the new port for
1.5.dev3
This machine is running Freebsd-8.1 Release, amd64 arch.
-= start
... much successful compile output clipped...
gcc -Iinclude -Iebtree -Wall -O2 -g -DFREEBSD_PORTS-DTPROXY
-DCONFIG_HAP_CRYPT -DENABLE_POLL
RNJ> Compiled from latest source, by make -f Makefile.bsd REGEX=pcre
RNJ> DEBUG= COPTS.generic="-Os -fomit-frame-pointer" (no mgnu)
Just getting caught up on this thread and the fact it's on Freebsd. :-)
Since you're not using gmake, you have to watch out that the
Makefile.bsd sets additional c
(Ugh, sorry Willy for the direct email.)
And to close out the thread: The new version is now live with version
v1.5-dev2 (port version : v1.5.d2) in the ports tree. Do a portsnap
update to see it and install it.
WT> That's not expected since the version is hard-coded in the "VERSION" file.
WT> Ei
>> With the recent announcement of haproxy v1.5-dev1 with it's new
>> features that I'm sure people will want to test, I'll be bringing the
>> port net/haproxy-devel in line with it's name, ie: development.
WT> That's great news ! However please upgrade to 1.5-dev2 to limit bug
WT> reports.
The
With the recent announcement of haproxy v1.5-dev1 with it's new
features that I'm sure people will want to test, I'll be bringing the
port net/haproxy-devel in line with it's name, ie: development.
This will cause a leapfrog of the main haproxy port as the version
changes from v1.3.x to the new v
JPHC> I've trouble logging my haproxy on freebsd 7.2 HA-Proxy version 1.4.2
JPHC> 2010/03/17
Are you using the net/haproxy port?
Make sure the log files exist and/or use the "-C" option (create
non-existent log files) for syslogd.
Here's an example that works on my test system:
-= /etc/rc.con
HJ> By compiling Haproxy 1.4.2 on Opensolaris b134 I noticed a warning in
HJ> dumpstats.c. I don't know for sure if this is a problem, but I thought I
HJ> let you know.
Got the same on Freebsd - but a touch more descriptive message.
-= start
gcc -Iinclude -Iebtree -Wall -O2 -g -DTPROXY -DCONFIG_
WT> Using the following patch I can build it everywhere here without a
WT> warning. Could you please test on your various FreeBSD versions, I
WT> see no reason why it should change anything, it's just for the sake
WT> of completeness.
Compiles without error on FB 7+8!
Cheers,
Ross.
--
Good morning everyone,
WT> I hope you don't mind that I CC the list and Krzysztof who needed
WT> the line which caused the problem on your side.
No problem, I just hit reply, rather than reply-all out of habit.
>> However, instead of using _XOPEN_SOURCE we may use something less
>> invasive (I h
AH>> However, the way I think it should go in the ideal situation, is that
AH>> the haproxy port should contain the latest and greatest stable release
AH>> (1.4.x), and the haproxy-devel port should go to the latest experimental
AH>> snapshot.. If you think keeping a 1.3.x tree alive is usefull (wh
Opening up a bit of discussion:
For those Freebsd port users out there, I'm looking to submit updates
for the haproxy port to take it from it's current v1.2.18 to the new
v1.4.x tree - Leapfrogging the v1.3.x tree (which is part of the
haproxy-devel port).
Note: I'm _not_ looking to change the h
>> That's more of an issue with the site than a (proxy based) load
>> balancer - the LB would be doing the exact same thing as the client.
WT> Precisely not and that's the problem. The proxy cannot ask the user
WT> if he wants to retry on sensible requests, and the cannot precisely
WT> know what
WT> It's not only a matter of caching the request to replay it, it is that
WT> you're simply not allowed to. I know a guy who ordered a book at a
WT> large well-known site. His order was processed twice. Maybe there is
WT> something on this site which grants itself the right to replay a user's
WT>
I'll enter in this conversation as I've used (successfully) a load
balancer which did server-side keep-alive a while ago.
WT> Hmmm that's different. There are issues with the HTTP protocol
WT> itself making this extremely difficult. When you're keeping a
WT> connection alive in order to send a se
JL> I would like to hear anyone using anycast with TCP. What if two servers are
JL> equal distance. Wouldn't you have a fair chance of equal 50% packets going
JL> each way, killing tcp state connections. The more servers out there
JL> advertising the same IP, the more likely you will have cases
TJG> I'm told that anycast is the natural solution, but I find little on
TJG> the net (or in books) on this. (Though there's more info on geodns,
TJG> which I'm told is like a "poor man's anycast.")
There's very little out there on anycast, as it's not really a
designed function of the routing pr
Did a full compile of the 1.3.15.7 - 20081208 snapshot on Freebsd-7.x
recently, and noted that there needs to be a quick patch done on the
Makefile for bsd machines.
This was due to the stream_interface replacing the send data commands
in the rewrite Willy did a while ago.
Simple fix, and it com
17 matches
Mail list logo
