Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/3111
@arkadius I did a good bit of testing and wasn't able to break anything.
Thanks for the improvements! +1, I have merged to master.
---
Github user arkadius commented on the issue:
https://github.com/apache/nifi/pull/3111
@markap14 No problem, looking forward for conclusions from this testing.
---
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/3111
@arkadius thanks for the update! Code review looks good. All unit tests and
contrib-check pass. This does touch some super heavily used processors, though,
like UpdateAttribute, so I'll want to take
Github user arkadius commented on the issue:
https://github.com/apache/nifi/pull/3111
@markap14 I understand your point, I also don't like poems in comments :-)
I've switched to Caffeine in all places except 4. Can you look at this now? CI
report failure in some jobs - looks like non
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/3111
@arkadius thanks for compiling that list. Sorry it took so long to reply!
Looking through the list, I do think you're right - these all appear to be the
same pattern. I certainly didn't realize that
Github user arkadius commented on the issue:
https://github.com/apache/nifi/pull/3111
Other places of usage:
1. `org.apache.nifi.record.path.util.RecordPathCache` - record path cache,
synchronized access
2. `org.apache.nifi.avro.AvroReader` - avro schema cache (this parts is
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/3111
@arkadius I am not familiar with caffeine but it looks promising. A quick
glance through the LICENSE indicates that it is compatible and has only a
single dependency on Google Guava, which is also
Github user arkadius commented on the issue:
https://github.com/apache/nifi/pull/3111
@markap14 what do you think about using
https://github.com/ben-manes/caffeine instead? They have benchmarks showing
performance difference from current approach (named `LinkedHashMap_Lru`). Take
a
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/3111
@arkadius fair enough. I'd be okay with a soft limit.
---
Github user arkadius commented on the issue:
https://github.com/apache/nifi/pull/3111
Hi @markap14 . Thank you for your reply. We have a quite heavy-loaded
environment. We are processing about 5 GB / min of messages on 32 core host.
Avro serialization was our main bottleneck. We had
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/3111
@arkadius thanks for the contribution. I don't think this is the right
approach, however, As-is, the code ensures that we don't hold any more than a
set number of entries in the cache. The proposed
11 matches
Mail list logo
