New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to prevent usage of Cache in Restcomm within RVD #1261

Closed
bourgois opened this Issue Jul 6, 2016 · 9 comments

Comments

Projects
None yet
5 participants
@bourgois

bourgois commented Jul 6, 2016

In case I have RVD requesting an external service to get an audio file to play, I don't want to use a cache version if the service is down but I would like to get an error and be able to move to a default local file.
A bypassCache option for Play and Say actions would be great.

@otsakir

This comment has been minimized.

Contributor

otsakir commented Jul 6, 2016

So, what exactly is the issue here? Does Restcomm cache .wav files resulting is illusive behavior when the actual service that produces these files is down ?

If that's the case, a bypassCache options might help. But since RCML is a pretty declarative thing, i think we should define another property to cover what to do in such cases. Maybe a fallback url to the .wav, an action url? not sure... Wondering if this is an overkill for a "simple" Play verb.

@otsakir otsakir removed this from the 7.9.0 milestone Jul 14, 2016

@bourgois

This comment has been minimized.

bourgois commented Jul 14, 2016

So we have two different reasons for the bypass cache from my point of view:

  1. Cache size/management: I might have millions of files for greetings, I am generating and storing them on the business logic part and don't want to have a cache that I can't control storing them and playing them without my knowledge/control
  2. The URL in RVD is correct, the file might not be proper or even the server could be done. Currently all seems well at RVD level and the error is seen only at Media Server level. So from a media server point of view it behaved correctly just we are not passed the error and can't act on it (in fact I still don't really understand why RVD stop has it didn't see an error).

So the bypassCache can prevent caching too much data and would allow a more resilient service...

@gvagenas

This comment has been minimized.

Collaborator

gvagenas commented Jul 15, 2016

From Restcomm side we could have a flag to disable caching of wav files. We could disable caching only for WAV files, while still cache TTS WAV files.
But disabled cache would be effective throughout the runtime.
Would that help?

@deruelle

This comment has been minimized.

Member

deruelle commented Jul 15, 2016

@gvagenas you mean only for Play Verb but not Say Verb right ?

@gvagenas

This comment has been minimized.

Collaborator

gvagenas commented Jul 15, 2016

@deruelle Right, we could have flag to disable cache for PLAY but not for SAY

@bourgois

This comment has been minimized.

bourgois commented Jul 15, 2016

That sounds like a good plan to me!
Thanks

On 15 juil. 2016, at 11:10, George Vagenas notifications@github.com wrote:

@deruelle Right, we could have flag to disable cache for PLAY but not for SAY


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@hamsterksu

This comment has been minimized.

Contributor

hamsterksu commented Aug 8, 2016

our plan to fix this issue:

​1. add new property <cache-no-wav> to - https://github.com/RestComm/Restcomm-Connect/blob/d34fd3d41aaaf7978660ae798e670b5f38a1c7ac/restcomm/restcomm.application/src/main/webapp/WEB-INF/conf/restcomm.xml
2. add new flag to DiskCache.java to avoid wav caching
3. update onReceive to handle this flag
4. add unit tests

@bourgois

This comment has been minimized.

bourgois commented Aug 9, 2016

Sounds like a good plan, also the property should be mapped to a ENV variable so we can easily disable/enable it in docker.

@gvagenas gvagenas added this to the 7.9.0 milestone Sep 14, 2016

@gvagenas gvagenas closed this Sep 14, 2016

@bourgois

This comment has been minimized.

bourgois commented Sep 14, 2016

Thanks @hamsterksu :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment