Re: Creating a thread safe module and the problem of calling of 'CRYPTO_set_locking_callback' twice!
On Thu, 2006-12-07 at 18:41 +, Darryl Miles wrote: Maybe there is some (small) re-design of the Apache code needed? Agreed, something needs to be added. I'm saying there is no need to make it specific to OpenSSL. Serializing the initialization can be made generic such that these objectives are met: why not move this issue to libapr/libarp-util Through abstraction of OpenSSL (or whatever ssl implementation) all threading issues/race conditions etc. could be addressed and handled without any changes of mod_core (sure mod_ssl must be changed) After that mod_foo could use this abstraction instead of using OpenSSL. I know that this is a big peace of work and it doesn't solve the general lib_thread_save_intialisation_issue but it could be also of great use for any dev (beside httpd). regards klaus
Re: load balancer cluster set
Load balancing really belongs at the network layer. depends on your needs IBM released free load-balancing software for linux and windows about 1997. My former employer's integration group (about 3 people) got a fully redundant implementation running (on 4 pcs) in about 4 months. ack The company abandoned the free s/w version for hardware implementations on Cisco gear (and others) within about 6 months. I'm sure the price for proprietary hardware has dropped substantially since then. disagree the price is still at the same level (just the releases went up) I also disagree when it comes to the point of Cisco has the perfect LB solution. In fact they have not. The problem is not the distribution, which is not able to provide a Load distribution in means of spreading EQUAL load on some servers because a) most applications need application stickyness b) neither round robin nor other implementations manage to keep equal load on servers because they can't measure the SERVERS load But again problems are elsewhere. There are quite some methods to provide stickyness. All fail in some kinds of uses. They can't watch cookies 100% correctly and if they are told to introduce their own, they mess up the protocol. IP stickyness has issues when upstream proxies are used in a balanced way. Finally ssl stickyness is not working correctly too (which is generally a bad idea anyway). But there is a solution: lose your capeablity of handling ssl and source that out to cisco appliances completely. Finally to clean up with myths: The loadbalancing in ciscos LBs is NOT done in hardware. In fact they use multi purpose CPUs to do LB decisions. Only when it comes to plain routing, that happens in hardware. On the other hand ... to be nice to cisco ... they have done a great job to keep this thing stable. Servers crash far more often than these appliances. And they have done a great job in means of failover from one lb to another because they use routing protocols to announce the active lb way faster that taking up an ip address on a server and starting a software lb. so ... there are reasons to use appliances and there are reasons not to use them (flexible balancing, application layer stickyness, and so on) regards klaus
Re: SSL + name based virtual hosting
On Wed, Dec 22, 2004 at 03:41:08PM +0100, Enrico Weigelt wrote: * Sander Temme [EMAIL PROTECTED] wrote: On Dec 18, 2004, at 12:19 AM, Enrico Weigelt wrote: What fools are sitting there in the IETF ?! Fools that are highly aware of the hundreds of millions of web browser installations out there that know nothing but the standard versions of SSL/TLS and whose users cannot be forced to upgrade. Why wasn't it in already the first version ? remember the Y2K problem? mistakes in design phases happen get over it, or fix the problem why weren't you clever enough ... questions don't help anyone We dont live in a time where evryone has IP addresses of each coffee pot ... ack, but ipv6 is around for several years and very few have adopted that cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: People still using v1.3 - finding out why
Hi, another reason may be mod_perl, althought mod_perl 2.0 is available for quite some time, and there is a good documentation how to migrate applications, many applications based on mod_perl haven't done so. The problem is not the same as for mod_php. mod_php 4.* has been available for apache 1.3 and apache 2 but mod_perl 1 only for apache 1 and mod_perl 2 only for apache 2. Mason(a mod_perl app) for eg. has mod_perl 2 support since 2004-10-18: -snip- As of Mason 1.27 (released 10/28/2004), there is support for Apache/mod_perl 2.0 in the core Mason code -snap- I have been using 2.0 since 2.0.35 but have damned our decision when serious breakage occured in mod_ssl in combination with various browsers and 3rd party ssl clients between version 2.0.46 and 2.0.49. 1.3, since I use it, never had those problems. Don't take me wrong, I like 2.0 and love it's features and the stability now is far better than when it was introduced, but I can understand people that call it too risky to migrate to 2.0. regards klaus
