cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

If your Cloud Collaboration question is not answered quickly, please email devsupport@webex.com for additional help

244
Views
0
Helpful
1
Replies
Beginner

WebEx Global Site Backup (gsb) Status impact on API changes

I'm testing some XML API (User) calls, and whilst they return successful Responses, they are all returning with a gsbStatus of BACKUP (not PRIMARY). And I'm noticing (what I believe to be) significant delays in the requested change to the user taking place. For example, making a change to a user via the API is taking some time to reflect on the Site, both for the User themselves and via the Site Admin view.

<?xml version="1.0" encoding="ISO-8859-1"?>

<serv:message xmlns:serv="http://www.webex.com/schemas/2002/06/service" xmlns:com="http://www.webex.com/schemas/2002/06/common" xmlns:use="http://www.webex.com/schemas/2002/06/service/user">

  <serv:header>

       <serv:response>

            <serv:result>SUCCESS</serv:result>

            <serv:gsbStatus>BACKUP</serv:gsbStatus>

       </serv:response>

  </serv:header>

  <serv:body>

       <serv:bodyContent xsi:type="use:setUserResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>

  </serv:body>

</serv:message>

The GSB FAQ seems to suggest that everything should be being updated between Primary and Backup in real time.

Is there anything that can be done to avoid this delay?

Thanks,

-Martin

Everyone's tags (1)
1 REPLY 1
Highlighted
Cisco Employee

Re: WebEx Global Site Backup (gsb) Status impact on API changes

Hello,

     Changes made via API should be reflected immediately. One possible cause would be if your application is caching DNS lookup, causing you to still be posting your requests to backup even though your service is on primary (or the other way around). This is a common issue with JAVA based applications, as JAVA caches DNS lookup indefinitely by default. JAVA can be configured to skip caching DNS lookups, or at least to flush DNS cache periodically. Not caching is preferable, but if it is necessary, I would recommend limiting the TTL to 5 minutes or less.

CreatePlease to create content
This widget could not be displayed.