In this article I would like to give you some information about
a very important timer job in SharePoint 2010 - the
Application Addresses Refresh Job. If you do not
understand what it is used for you might see some strange (to you)
error messages when configuring SharePoint. Even if you're familiar
with it it might be a good idea to continue reading.
Purpose of the Application Addresses Refresh
Job
The Application Addresses Refresh Job has one specific job to do -
keep track of all available and online instances of all service
application end-points. This means that whenever a proxy
requests an endpoint for a service application it will ask the
Topology Service (the Application Discovery and Load Balancer
Service) for an endpoint. The Topology Service keeps a list of the
endpoints that has been discovered by the Application Addresses
Refresh Job and passes on one of these endpoints to the proxy,
using the load balancing algorithm, which uses that endpoint to
talk to the service application. So far so good...
So, what could go wrong here... 
The problem is that this job only runs (by default) every
15 minutes. And unless you follow the first rule of Spence
- "Step away from the keyboard", you will experience some
interesting side effects.
Service Application configuration
One of the first times you'll experience this 15 minute delays is
when creating Service Applications in SharePoint 2010. Let's take
the Secure Store as an example. You create the Secure Store Service
Application and trigger happy as you are you click on it to
configure the Secure Store Key. And most of the times you will see
an error like this:

You hit the reload button a couple of times, starts to fiddle with
permissions but nothing happens. Finally you realize - ahh, I
haven't started the Service Instance of the Secure Store, so you
start that and head back to the Secure Store Service App to
continue to configure it. But, you still receive the same error
message. You do some more fiddling with permissions etc until your
totally lost in your configuration madness. You do some Binging on
the Interwebs and suddenly it just works...
What really happened was that the Application Addresses Refresh
Job run, meanwhile you were furiously blaming the product group for
a crappy product, and found a valid and working endpoint for the
Secure Store Service App. And now the Topology Service are aware of
the endpoint and can pass it on to the proxy.
What you really should have done is; first start the Service
Instance, then create the Service Application. And if you still get
the error message, manually kicking off the timer job will do the
trick.
Farm maintenance
Another common scenario where similar results may be seen is when
you do some farm reconfiguring; such as adding/removing/rebooting
servers, moving Service Application Instances from one server to
another (stop on one server and start on another). You could do
this while your farm is hot and running but make sure to start the
timer job whenever you do a change (start/stop and instance or
add/remove a server). Worst case your end-users will be unable to
use the Service Application for at the most 15 minutes. One
scenario where I've seen it happen is when you take a server out of
the load balancer rotation to do Windows patching and then you need
to reboot that server - the service application will be unavailable
for that time on that machine (duh!). So if you have for instance
three servers running this service instance, every third (Round
Robin) request will fail. Running the timer job immediately after
starting the re-boot sequence will mitigate any errors.
Should I change the Timer Job schedule?
Well, this is totally up to you. From what I've seen it's not a
"heavy" job and you could lower the interval. But under normal
circumstances 15 minutes should do the trick. But when doing
maintenance, as discussed above, lowering the interval might be a
good idea.
Summary
A short, and pretty intuitive, post about a very, very important
Timer Job in SharePoint 2010 - the Application Addresses Refresh
Job. Make sure that this job is running and behaving - otherwise
your end-users (and proxies) will not be able to talk to the
service application instances.
[Update 2012-05-20] If you are interested in more details
on the topology web service and the service application load
balancing I recommend that you read the following post by Josh
Gavant: How I learned to Stop Worrying and Love the
SharePoint Topology Service.
Wictor
Wilén is one of the few in the world who has accomplished the
Microsoft Certified Master - SharePoint 2010 certification. Check
out our new resource centre for more insightful work from
Wictor Wilén.