On 24/08/2012 19:55, Howard Chu wrote:
Ideally it'd work in all cases. Pierangelo says the failover works when
connect() times out, but I'd have thought that would include scenarios 1
and 2 but not 3.
Sounds like you should file an ITS.
ITS#7372 submitted.
--
Liam Gretton
Liam Gretton wrote:
> On 23/08/2012 11:18, Howard Chu wrote:
> > Your description of your procedure is so vague and imprecise it's
> > difficult for anybody to decipher what you're talking about.
> >
> > Reading back thru the several posts in this thread, what I see you
> > saying is that you have
Liam Gretton wrote:
> On 23/08/2012 11:18, Howard Chu wrote:
>
>> Your description of your procedure is so vague and imprecise it's difficult
>> for anybody to decipher what you're talking about.
> >
>> Reading back thru the several posts in this thread, what I see you saying is
>> that you have
Hi Liam,
IMHO you'd be better off using a hardware/software failover device. There are
several free linux based ones that will run on commodity or dedicated hardware.
Then you have complete control of the failover policy. Using a single app
server to provide failover for some other app server(s
On 24/08/2012 12:48, harry.j...@arcor.de wrote:
I am really not astonished about your results.
Run your tests again, but use "reject" as iptables target.
"drop" means, that you never ever get an answer.
Ok, tried that.
For scenario 1, search against slapd times out after about 3s, doesn't
at
On 23/08/2012 11:18, Howard Chu wrote:
Your description of your procedure is so vague and imprecise it's difficult
for anybody to decipher what you're talking about.
>
Reading back thru the several posts in this thread, what I see you saying is
that you have tested a few different configuratio
Liam Gretton wrote:
> On 23/08/2012 10:22, Pierangelo Masarati wrote:
Current failover only deals with failures/timeouts of connect(2). I
don't think handling your case using failover is appropriate. Your
case should be handled by removing the non-responding URI from the
list.
>
On 23/08/2012 10:22, Pierangelo Masarati wrote:
Current failover only deals with failures/timeouts of connect(2). I
don't think handling your case using failover is appropriate. Your
case should be handled by removing the non-responding URI from the
list.
I don't understand the difference. If a
On 08/23/2012 11:00 AM, Liam Gretton wrote:
On 22/08/2012 22:14, Pierangelo Masarati wrote:
But what's the point of specifying multiple targets in the uri
option if it doesn't fall through to subsequent ones when the first
is not contactable?
Have I completely missed the point of the documenta
On 22/08/2012 22:14, Pierangelo Masarati wrote:
But what's the point of specifying multiple targets in the uri
option if it doesn't fall through to subsequent ones when the first
is not contactable?
Have I completely missed the point of the documentation?
The point is that your condition is *
On 22/08/2012 09:44, Pierangelo Masarati wrote:
My fault: "timeout" is operation-wide; when it's hit, the
operation ends as you reported. "network-timeout" is related to
connect(2) only. As far as I understand, by looking at the code,
there is no practical means, so far, to perform what you're a
I'm trying to get my head round the source code now to see if this is a bug.
One thing that looks odd to me in the debug output:
ldap_url_parse_ext(ldap://host1:3268)
ldap_url_parse_ext(ldap://host2:3268)
ldap_url_parse_ext(ldap://host3:3268)
502e5f7e conn=1000 op=1: meta_back_getconn[0]
502e5f7e
Can anyone explain the interaction between 'network-timeout' and
'timeout'? I'm tearing my hair out with this problem and the timeout
options are the only straws I have to clutch at.
On 15/08/2012 04:30, Liam Gretton wrote:
On 14/08/2012 21:57, masar...@aero.polimi.it wrote:
bind-timeout and
On 14/08/2012 21:57, masar...@aero.polimi.it wrote:
bind-timeout and network-timeout have specific, connection-level meaning.
Just "timeout " (you can make it search-specific if you don't
want it to affect other operations, using "timeout search=".
Setting timeout doesn't solve the problem, bu
> On 14/08/2012 17:18, masar...@aero.polimi.it wrote:
>
>>> If I remove host1 after the LDAP server has started, the debug
>>> output is at least different. It's attempting to contact host1,
>>> failing, doubling the timeout and trying again continuously, never
>>> attempting to try host2 or host3.
On 14/08/2012 17:18, masar...@aero.polimi.it wrote:
If I remove host1 after the LDAP server has started, the debug
output is at least different. It's attempting to contact host1,
failing, doubling the timeout and trying again continuously, never
attempting to try host2 or host3.
The timeout yo
> On 14/08/2012 16:06, masar...@aero.polimi.it wrote:
>
>>> If I wasn't clear, I changed the config as you suggested. The debug
>>> output I posted was from that configuration. The server never attempts
>>> to contact anything other than host1.
>>
>> Did you try stopping host1 in between client ope
On 14/08/2012 16:06, masar...@aero.polimi.it wrote:
If I wasn't clear, I changed the config as you suggested. The debug
output I posted was from that configuration. The server never attempts
to contact anything other than host1.
Did you try stopping host1 in between client operations? I did a
> On 14/08/2012 15:28, masar...@aero.polimi.it wrote:
>>> On 14/08/2012 14:52, masar...@aero.polimi.it wrote:
>>>
You are. The above is creating three targets, one pointing to host1,
one
pointing to host2 and one pointing to host3. The rest of the
configuration is associated t
On 14/08/2012 15:28, masar...@aero.polimi.it wrote:
On 14/08/2012 14:52, masar...@aero.polimi.it wrote:
You are. The above is creating three targets, one pointing to host1,
one
pointing to host2 and one pointing to host3. The rest of the
configuration is associated to the last target, the oth
> On 14/08/2012 14:52, masar...@aero.polimi.it wrote:
>
>> You are. The above is creating three targets, one pointing to host1,
>> one
>> pointing to host2 and one pointing to host3. The rest of the
>> configuration is associated to the last target, the others are sort of
>> dangling. A correct
On 14/08/2012 14:52, masar...@aero.polimi.it wrote:
You are. The above is creating three targets, one pointing to host1, one
pointing to host2 and one pointing to host3. The rest of the
configuration is associated to the last target, the others are sort of
dangling. A correct configuration fo
> I've been trying to get slapd-meta to failover using multiple URIs but
> can't get it to work.
>
> Initially I was using 2.4.26, but having seen the report in ITS#7050
> I've now built 2.4.32 but the problem is still there as far as I can
> tell. This bug was quashed in 2.4.29 according to the ch
-Ursprüngliche Nachricht-
An: openldap-technical@openldap.org;
Von:Liam Gretton
Gesendet: Di 14.08.2012 15:18
Betreff:slapd-meta doesn't continue with multiple uri's
> I've been trying to get slapd-meta to failover using multiple URIs but
>
I've been trying to get slapd-meta to failover using multiple URIs but
can't get it to work.
Initially I was using 2.4.26, but having seen the report in ITS#7050
I've now built 2.4.32 but the problem is still there as far as I can
tell. This bug was quashed in 2.4.29 according to the change lo
25 matches
Mail list logo
