On 15/11/2012 00:48, Tim Bannister wrote:
On 14 Nov 2012, at 22:19, Ask Bjørn Hansen wrote:
I know I am fighting the tide here, but it's really the wrong smarts to put in
the load balancer.
The backend should/can know if it can take more requests. When it can't it
shouldn't and the load bal
On 15 Nov 2012, at 12:48 AM, Tim Bannister wrote:
> This only makes sense for idempotent requests. What about a POST or PUT?
>
>
> For a plausible example that mixes POST and GET: a cluster of N webservers
> providing SPARQL HTTP access to a triplestore. Most queries will use GET but
> some m
On 14 Nov 2012, at 22:19, Ask Bjørn Hansen wrote:
> I know I am fighting the tide here, but it's really the wrong smarts to put
> in the load balancer.
>
> The backend should/can know if it can take more requests. When it can't it
> shouldn't and the load balancer shouldn't pass that back to t
On Nov 14, 2012, at 11:01, Tim Bannister wrote:
>> I really like how Perlbal does it:
>>
>> It opens a connection when it thinks it needs more and issues a (by default,
>> it's configurable) "OPTIONS *" request and only after getting a successful
>> response to the test will it send real requ
On Nov 11, 2012, at 3:57 AM, Fabien wrote:
> I have developed and maintained a small module called "mod_macro" since 1998.
> It is currently available at:
>
> http://people.apache.org/~fabien/mod_macro/
>
> I started it one day as was fed up with copy-pasting configuration directives
>
On 14 Nov 2012, at 18:49, Ask Bjørn Hansen wrote:
> I really like how Perlbal does it:
>
> It opens a connection when it thinks it needs more and issues a (by default,
> it's configurable) "OPTIONS *" request and only after getting a successful
> response to the test will it send real requests
I really like how Perlbal does it:
It opens a connection when it thinks it needs more and issues a (by default,
it's configurable) "OPTIONS *" request and only after getting a successful
response to the test will it send real requests on that connection (and then it
will keep the connection ope
jaillet...@apache.org wrote:
> Author: jailletc36
> Date: Tue Nov 13 21:03:10 2012
> New Revision: 1408958
>
> URL: http://svn.apache.org/viewvc?rev=1408958&view=rev
> Log:
> mod_session_dbd: fix a segmentation fault in the function dbd_remove.
> The segmentation fault is caused by an uninitiali
- Original Message -
> Am 14.11.2012 12:53, schrieb Guenter Knauf:
> > Am 12.11.2012 17:45, schrieb Issac Goldstand:
> >> but we really need something.
> > I know that Gregg has 'something' which is not MSI but an EXE
> > installer,
> > but it works, and I asked already a while back if we
Am 14.11.2012 12:53, schrieb Guenter Knauf:
Am 12.11.2012 17:45, schrieb Issac Goldstand:
but we really need something.
I know that Gregg has 'something' which is not MSI but an EXE installer,
but it works, and I asked already a while back if we should push this
out, but there was no further in
Am 12.11.2012 17:45, schrieb Issac Goldstand:
but we really need something.
I know that Gregg has 'something' which is not MSI but an EXE installer,
but it works, and I asked already a while back if we should push this
out, but there was no further interest / agreement here :-(
Gregg, can you
Am 11.11.2012 09:57, schrieb Fabien:
I have developed and maintained a small module called "mod_macro" since
1998. It is currently available at:
http://people.apache.org/~fabien/mod_macro/
I would like to donate the code so that it could be integrated with
apache as a standard module.
+1
Gün.
12 matches
Mail list logo
