Does Chronicle Map have any concept (or pluggable ability) to provide automatic entry expiration?
No, and I’m sorry we don’t have any plans to add this functionality in the near future.
Related
Please let me know if cache eviction can be done at particular time of the day instead of TTL. I am using spring framework so if any API provides this feature then I can use this API by plugging into Spring.
I did run through search mechanism if similar question has been asked but failed to find any prior question.
If similar question has been asked please let me know the link.
Thanks, Amitabh
According to GemFire docs:
You configure for eviction based on entry count, percentage of
available heap, and absolute memory usage. You also configure what to
do when you need to evict: destroy entries or overflow them to disk.
See Persistence and Overflow.
http://gemfire.docs.pivotal.io/latest/userguide/index.html#developing/eviction/configuring_data_eviction.html
But you may be able to get something closer to what you need through Custom expiration. Please check the following link:
http://gemfire.docs.pivotal.io/latest/userguide/index.html#developing/expiration/configuring_data_expiration.html
Ehcache expiration does not offer such a feature out of the box.
You still have some options:
Configure the TTL when creating the Element with a computed value.
Use refresh-ahead or even better scheduled refresh ahead
Have a look at the following question. Note that this may not work with all configurations as sometimes the Element gets re-created internally.
I'm looking the best more efficient way to implement (or use an already setup) rate limiter that would protect all my rest api url. the protection I'm looking at is a "call per second per user limiter"
I had a look on the net and what comes out was the use of either "Redis" or Guava RateLimiter.
To be honest I have never used Redis and I'am really not familiar with it. But by looking on its docs it seems that it has a quite robust rate limiter system.
I have also had a look at Guava's RateLimiter. And it looks a bit easier to use (don't need a redis installation etc...)
So I would like some suggestion of what would be "in my case" the best solution? Is using Redis "too much"?
Have any of you already tried RateLimter? Is this a good solution? Is it scaleable?
PS: I am also open to other solutions than the 2 I aforementioned if you think there are better choices.
Thank you!
If you are trying to limit access to your Spring-based REST api you should use token-bucket algorithm.
There is bucket4j-spring-boot-starter project which uses bucket4j library to rate-limit access to the REST api. You can configure it via application properties file. There is an option to limit the access based on IP address or username.
If you are using Netflix Zuul you could use Spring Cloud Zuul RateLimit which uses different storage options: Consul, Redis, Spring Data and Bucket4j.
Guava’s RateLimiter blocks the current thread so if there’s a burst of asynchronous calls against the throttled service lots of threads will be blocked and might result exhaust of free threads.
Perhaps Spring-based library Kite meets your needs. Kite's "rate-limiting throttle" rejects requests after the principal reaches a configurable limit on the number of requests in some time period. The rate limiter uses Spring Security to determine the principal involved.
But Kite is still a single-JVM approach. If you do need a cluster-aware approach Redis is a way to go.
there is no hard rule, it totally depends on your specific situation. provided that "I have never used Redis", I would recommend guava RateLimiter. compare to redis, a completely new nosql system for you, guava RateLimiter is much easier to get started with. by adding a few lines of code, you are enable to distribute permits at a configurable rate. what left to do is to adapt it to fit your need, like providing rate limit on a per user basis.
For security reasons we are planning to disable all write access to classes. Client applications (android and IOS sdks) will only have read-only access to the Parse data(classes)
Data stored in parse servers will be only modified by cloud functions. The cloud functions will call
Parse.Cloud.useMasterKey();
We have come up with this solution because it is nearly impossible to hide parse application ids and parse client key from attackers/hackers.
So is this a good solution? Are there any drawbacks? Does "Parse.Cloud.useMasterKey()" method have performance implications?
Thank you...
This is pretty standard practice, you implement your own security in your Cloud Functions and use the master key.
In theory it might be more efficient using the master key as the Parse servers don't have to process the Roles/Users/ACLs at all when the master key is used. Of course you need to balance that with any extra check your security logic does.
How do I implement Infinispan JPA cache loader?is there any pattern or way to implement it in infinispan API?
Most existing CacheLoader implementations in Infinispan are assuming the data just needs storage and consider it blindly as an array of bytes. The integration API in Infinispan doesn't expose much of a context other than "store(Key,Value)" or "load(Key)". I'm oversimplifying a bit, but that's the core.
There is one exception which is the LuceneCacheLoader. This was designed to work exclusively in combination with the Lucene Directory for Infinispan, as it takes advantage of the fact
It knows which types to expect
Takes advantage of the known needs of the Directory (such as access pattern)
Have a look at the sources to get inspired; note I only implemented loading (it's a CacheLoader).
If you control both the application using Infinispan and the CacheLoader, you could take advantage of these details as well.
Tricky aspects:
While writing multiple keys even in the same transaction, you'll have access to one entry at a time in the scope of the CacheLoader logic -> hard to map relations: have to deal with one entity at a time and "restore connections"
With write behind you might receive entries out of order -> not sure how to deal with referential integrity
With write behind you're not going to have the same Transactional context -> might be acceptable?
Taking these into account, I'm sure you could write one. How easy? That depends on your app.
I'm not sure if a general purpose solution could work. If you find out it can, please contribute it as it would be a great addition to the project.
We're in the process of creating a new API for our product, which will be exposed via web services. We have an internal debate whether the API should be as easy as possible to use (in the price of making more calls) or make it as efficient as possible (rendering it harder to use). For example, here are two issues that came up:
Should we manage session info on the server, or should we pass that info back to the user, and expect him to send it back to us when needed? (Please ignore the security implications of a session)
Should we combine calls that are likely to be consequent, in order to save the time spent on the round trip in between, even if they don't really share the same logical functionality?
Basically, the desktop people are in favor of a clear, easy to use API, while the internet people would like to make it as efficient as possible. This is the first public API we're providing, and we need a strategy.
Personally, I'm in favor of making the API as usable as possible. Other components on the system are probably going to have a much larger affect on the performance, and hard to use APIs are much more error prone. But I'm a desktop programmer…
So, what should be our strategy? What are the common practices when creating such an API?
What are typical usage scenarios? Will the latency of your API determine the UI responsiveness? How big the performance trade-off will be? It's hard to suggest anything without knowing your circumstances.
But
My guess is that passing session info to the client will scale better. In-proc session management won't allow you to share the state between service instances. Managing sessions in DB will make your services more complex. Anyway this all depends on your bandwidth/memory/computational power capabilities.
I would start from the most granular operations and only provide composite methods when performance problem becomes obvious.
IMO, the best is to have the simplest API for people who will have to use your API, but letting these people have deep customizing possibilities, to make it efficient, even if harder to use.
But simplicity for users > all.
I would recommend you create your web service following the RESTful model and that means stateless. Efficiency is more critical than ease of use. You can always create a framework on top of the API later that eases implementation headaches.
You're debating a circular agrument. This is all usability (ease of use).
You're likely going to factor in a bit of both aspects - as they both influence user performance.
Its a case of (i) extent of customsiable features versus (ii) efficiency in manipulating those features. There will be an intersect between the two.
I'd say give a simple API that puts control into the users hands - this is the primary purpose of CMS. The more detailed aspects you could combine initially, introducing them as added control later on.
This way you will manage users learning curve of the system so as (i) not to bombard them with excessive options initially and (ii) allow them to adopt your system quickly at first. Then extend your users control (system functionality from a user perspective) later on by making more of the API features available.
Another good tip would be to ask you users upfront & as you go.
My 2 cents:
First start with a very granular low level API that gives high performance.
Then create a easy-to-use high level API that is "composed" of the above low level API.
This way clients can customize their behavior as they want. The clients can start with using the high-level API but if high performance is expected for certain user actions, they can use the faster-but-difficult low level API on a case-by-case basis.
One more important point to consider in service design. Try to keep them as stateless as possible. The advantage of stateless web services is that they can be easily distributed using Network Load Balancing.