I tried to use this mediator to cache OAuth token, but faced the problem with it because this supports local caching only. We have two EI servers and the traffic gets distributed by a load balancer. If the token service is called from the node1 server and a token is cached, the node2 server doesn’t know about it. Therefore, if the token service is called from the node2 server a few min later, the token’s time-to-live is shorter. This causes a problem since I set the cache timeout value to be same as token’s validity period, so the token in the node2 server will expire before the cache timeout. Is there a way to get around this issue while still using the cache mediator?
Hi @Integration Corner. This was helpful. But I am facing a strange intermittent issue. I am using cache mediator and getting this "o.w.c.m.c.CacheMediator : MBean implementation is not compliant with JMX specification standard MBean. javax.management.InstanceAlreadyExistsException: org.wso2.carbon.mediator.cache:type=Cache,tenant=carbon.super" intermittently. We are using Inbound endpoint which listens to the kafka messages and is configured to run in non-sequential mode. Please help.
Hi @integration corner. Thanks for the simple wonderful useful information. Would you please add more no of videos in Wso2 platform? I am damn sure that every startup learner can easily understand and do the implementation 🙏
That sounds strange .. Irrespective of the application you are using to invoke the api, as long as the cache key remains the same and subsequent requests were fired with in the cache expiry time, the api must return cached results .. I can look into it if you can share your api..
@@integrationcorner268 I believe Postman sends a random token in every request. Postman-Token: . Cache mediator works by checking the headers and payload of the request. When a random header value is sent every time, cache mediator will diagnose it as a different request. Hence the response won't be served from the Cache. To overcome the issue add the "Postman-Token" header in the cache mediator configuration under *
Hi, thanks for your useful course. I believe you have a little bug on the $1 json variable, where it is meant to be $.headers and not .$header. I don't know how it worked for you or if you changed in off camera but i needed to change it in order for it to work, cause the json file you showed invoking the back end service showed that the json element is called headers not header. Thank you and good work
Also one little question, if the cache finder is not empty the api will only run until the respond mediator of the cache? otherwise it will run the full api?
@@telesalvaro15 Once cache hits, in a normal scenario the flow will return. But, there are ways to get around it. You can configure a sequence to be triggered once cache hit and the remainder of of the logic that you want to implement can be in it.
I tried to use this mediator to cache OAuth token, but faced the problem with it because this supports local caching only. We have two EI servers and the traffic gets distributed by a load balancer. If the token service is called from the node1 server and a token is cached, the node2 server doesn’t know about it. Therefore, if the token service is called from the node2 server a few min later, the token’s time-to-live is shorter. This causes a problem since I set the cache timeout value to be same as token’s validity period, so the token in the node2 server will expire before the cache timeout. Is there a way to get around this issue while still using the cache mediator?
Hi @Integration Corner. This was helpful. But I am facing a strange intermittent issue. I am using cache mediator and getting this "o.w.c.m.c.CacheMediator : MBean implementation is not compliant with JMX specification standard MBean.
javax.management.InstanceAlreadyExistsException: org.wso2.carbon.mediator.cache:type=Cache,tenant=carbon.super" intermittently.
We are using Inbound endpoint which listens to the kafka messages and is configured to run in non-sequential mode. Please help.
Hi @integration corner.
Thanks for the simple wonderful useful information. Would you please add more no of videos in Wso2 platform? I am damn sure that every startup learner can easily understand and do the implementation 🙏
Thank you Justin. I am glad that you found the videos helpful. I would definitely add more videos in the near future as I am working on them.
Hello @Integration Corner
when I use chrome it caches and doesn't with the postman, what could be the problem
That sounds strange .. Irrespective of the application you are using to invoke the api, as long as the cache key remains the same and subsequent requests were fired with in the cache expiry time, the api must return cached results .. I can look into it if you can share your api..
@@integrationcorner268 I believe Postman sends a random token in every request. Postman-Token: . Cache mediator works by checking the headers and payload of the request. When a random header value is sent every time, cache mediator will diagnose it as a different request. Hence the response won't be served from the Cache.
To overcome the issue add the "Postman-Token" header in the cache mediator configuration under
*
Hi, thanks for your useful course. I believe you have a little bug on the $1 json variable, where it is meant to be $.headers and not .$header. I don't know how it worked for you or if you changed in off camera but i needed to change it in order for it to work, cause the json file you showed invoking the back end service showed that the json element is called headers not header.
Thank you and good work
Also one little question, if the cache finder is not empty the api will only run until the respond mediator of the cache? otherwise it will run the full api?
That is a good observation. It is headers indeed . Thank you
@@telesalvaro15 Once cache hits, in a normal scenario the flow will return. But, there are ways to get around it. You can configure a sequence to be triggered once cache hit and the remainder of of the logic that you want to implement can be in it.