what's the purpose of caching services using the service cache manager.

[piyushk]

I was cleaning up my services folder, and had a configuration problem with all services. Consequently the service cache got created with no services, and I don't know how to force reload the cache without deleting the cache directory.

For instance, my original service file (/home/piyushk/rocon/src/segbot_rocon/segbot_concert_services/solutions/segbot_gazebo_demo.services):

- resource_name: segbot_concert_services/segbot_gazebo.service
- resource_name: segbot_concert_services/segbot_requester.service

These services were not loaded with an error (service_cache_manager.py L178):

'Cannot load service configuration: [%s]' % resource_name

The cache got created as such:(/home/piyushk/.ros/rocon/solutions/segbotgazebodemoconcert/segbot_gazebo_demo.services):

[]

And now, even if I try and fix my services, the services from my file are not getting loaded. I can remove the cache manually, but what's the purpose of caching the services file in the first place? What happens if a user changes the services in the service file?

[jihoonl]

I will test and get back to the issue asap.

[jihoonl]

Cache manager is introduced to separate default solution package and local solution instance, and to support run-time service configuration updates.

Before introducing cache manager, we had to create a new solution package for slightly different service configurations. For example, we created a food delivery solution to use in Cafe Dorothy and our office. The differences between two environments are only map and locations. It seemed silly to create another package for small parameter changes.

Hence, we redesigned service manager to create local cache instance from default solution configuration. It allows to create multiple instances without corrupting defaults and also remembers previous runtime configurations to restart. These features will become more helpful once we start to release our solution packages as deb.

Cache managers are designed in issue #254

[jihoonl]

Um to help your error. It seems like you should write resource name without .service

- resource_name: segbot_concert_services/segbot_gazebo
- resource_name: segbot_concert_services/segbot_requester

I will test .service postfix to see if it works or not

[jihoonl]

Do you have package link that I can see or test?

[piyushk]

I'll send out a link soon. I was cleaning up the package when this issue came up, and all the code is not completely functional yet. I'll report back soon if it works with or without the params.

Also, If I understand you correctly, to use different maps/locations, you simply change the yaml files in the cache and use that itself?

[jihoonl]

Also, If I understand you correctly, to use different maps/locations, you simply change the yaml files in the cache and use that itself?

Yes. You don't have to touch the solution package itself anymore.

[piyushk]

Can we have it so that the cache is only used if a parameter is enabled (default disabled)? Or maybe if the true services file is newer than the cache, then the cache should not be used.

I ran into the same issue with the parameters file as well. Updated parameters to no effect, as they were already present in the cache.

[jihoonl]

Would you describe again what the problem is? Do you need to disable cache?

[piyushk]

Essentially, yes. I think it should be disabled by default. Right now if I change the parameters for any of my services, the cache does not get updated and I have to manually remove it.

[jihoonl]

@piyushk I will catch up on this soon,

[jihoonl]

How about having disable_cache args to disable caching?

[piyushk]

I think that would work. I would also highly recommend defaulting this param to true.

[stonier]

I would also, new users and most current users wouldn't make use of this. In this regard, simple is better, but this feature is still accessible to the more advanced user.

[jihoonl]

@piyushk now disable_cache is in option. and default is true.

[jihoonl]

Please reopen if necessary.

[piyushk]

@jihoonl I think this issue should be fine. We're still using Hydro for our multi-robot experiments, and I haven't tested these changes since they were not merged into hydro-devel (_Please don't do it right now! We'll have difficulty dealing with code breakages for now_). In 2-3 weeks time, we'll move to Indigo and start using more up-to-date code.