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
Move to JCache (JSR 107) for quote caching #9
Comments
Note I investigated this for several days back a year or so ago, and ended up holding off on pulling the trigger on this. I liked the simplicity of the API, but I was hitting issues at runtime with the JCache environment not being stable. When run under load, there would be intermittent exceptions, and sometimes the server would just start spewing periodic exceptions even if there wasn't any load. I'd looked at both Redisson's JCache support, and looked a bit at the Red Hat Data Grid. I think the latter (a productization of the open source Infinispan project - https://infinispan.org) looks more production-ready and supported, so if I pick this back up, that is likely the way I'd go. But for now, there are higher priority issues, so this remains a "good idea to work on some day" issue. |
I've proceeded on this further. I have a version of StockQuote.java coded to JCache now, using Redisson as the caching provider. It is stable and runs well in our stress tests. However, I hit a couple of issues for which I need to figure out some solution, which is why I haven't checked it in yet:
Both of these issues defeat my usual approach of letting people specify such stuff in their CR yaml and me passing such values in as env vars via my operator. So it will take some more investigation to figure out a solution that doesn't involve me hardcoding stuff/burning it in to my Docker image |
Right now, I'm using the Jedis (Java for Redis) library to cache quotes, so that I don't make extra-cluster calls every time someone asks for the price of a given stock. If I've gotten a quote for a given stock symbol in the past hour (that's configurable, via an env var), I just use that from the cache, rather than calling out to API Connect again. This way, when I run a stress test, like via my Looper microservice, I'm not racking up thousands of calls to APIC or IEX (my free plan only allows 50,000 calls per month, then cuts me off for the rest of the month, unless I upgrade to a paid plan).
I'd like to switch from hardcoding the caching provider to Redis, to instead use the portable JCache library added to Java EE 8 under JSR 107. This defines the industry-standard
javax.cache
package, rather than me directly coding to theredis.clients.jedis
package. Then I could presumably plug in any JCache provider (much like how I use JMS, rather than coding directly to the MQ client package, in my portfolio microservice).I'm considering moving the caching logic out of the main JAX-RS class and into a QuoteCache class. That would simplify the main JAX-RS class, which is currently way too concerned about talking to Redis. So if I move to JCache, I'll likely split up this microservice into at least two Java classes, rather than the all-in-one-class approach used today.
The text was updated successfully, but these errors were encountered: