Martin wrote:

>Subject: Re: [sipX-dev] XX-6547 - sipXsupervisor core dump 
>duringreplication of10, 000 user database
>
>>
>>
>>>>From what I've seen, sipXconfig does not do an immediate retry on a
>>> failure scenario.  It will eventually try when the next 
>send profiles 
>>> occurs due to some change in configuration.
>>> 
>>
>>I think that current sipXconfig behavior is better than the 
>brute force 
>>retrying. Making sipXconfig retry XML/RPC call automatically in many
>cases
>>(certainly in this one) would make things worse. Underlying protocol 
>>insures basic connectivity: if there are problems they are 
>not the kind 
>>that would clear themselves in a matter of seconds.
>>D.
>
>I think that in the current UI it is very hard for the admin 
>to find out what to do once a replication error occured (also 
>see my recent post on Job Status page). We got to have an 
>automatic recovery process. There are many reasons why 
>connectivity to another host in the cluster is temporarily 
>lost. If this happens during some replication event to that 
>host, then all the admin gets is a failure status on the Job 
>Status page. Most admins will just clear that page so that the 
>annoying error that displays on every page goes away. The host 
>in question remains with failed replication. It might recover 
>sort of 'by accident' next time the admin makes a config 
>change, but even that is hard to tell. The system might still 
>be running, but e.g. a distributed proxy might use the wrong 
>dialplan. Did I get this right?

I agree with your assessment Martin.  I know that there are enhancements
planned for this area but I'm not sure if it includes some sort of
automatic retry mechanism in the case of a failure.  Maybe Damian can
shed some light on this further.

In the meantime, I'd like to address the situation of the very large
replication and let the Config experts handle what they know best.

Raymond 
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to