For me, this is a continuation of problem experienced when using hazelcast-wm with deferredWrite=true.
After #5242 was resolved with #5537 in release 3.5.1, I downloaded it and tested, and found another bug introduced in #5471 (bilalyasar@98850a5#diff-d770d63698a9e0e449d0d8ad43f24943), and still break my use case.
In the latest version of HazelcastHttpSession.getAttribute(), when I call this method on an attribute for the first time (it doesn't exist yet in localCache), the code does not put a new entry into localCache. The result is: If I don't call setAttribute explicitly to put an attribute into localCache, calling getAttribute will never establish localCache and will always get the value from cluster. This logic is fine when deferredWrite=false, but causes unexpected behavior when deferredWrite=true.
In comparison, 3.4.2 release code have logic to put a new CacheEntry into localCache when deferredWrite=true in method getAttribute().
Please kindly look into this issue.
@haixiliu, i checked the code again, in this getAttributemethod: if local cache is null, we look distributed map then hazelcast puts data to local cache. One exception is that if data is null we don't put into local cache just return null. There is an issue about this situation #5668 .. And also in getAttributemethod there is no deferred-write distinction. Why do you think that when deferred-write=true causes unexpected behaviour?
@haixiliu, i guess i found your issue, i will try in my local and will inform you. thanks for reporting.
The code change in #5804 doesn't seem to fix the issue. I will need to put your change in and verify it, but based on my analysis, it doesn't fix my issue.
The reason I say that is the new LocalCacheEntry created in getAttribute() - when I am calling it on a non-existent attribute - is not put into localCache. Therefore, the next time I call getAttribute(), localCache.get(name) will still return null and will end up grabbing it from cluster again, which doesn't exist. So I will end up in the loop that will never store an attribute locally when calling getAttribute() alone - for deferredWrite=true.
In comparison, 3.4.2 code has a branching condition for deferredWrite=true, to put newly created LocalCacheEntry into localCache.
@haixiliu , yes you are right, #5804 solves the issue for existing attributes if attribute exist in distributed map then hazelcast-wm will put attribute to local cache but for the null attributes we have another issue which is #5668.. And #5668 will be solved with different PR.
caching problem is solved by #5804
we will fix caching null attributes issue which is #5668
so i am closing this issue.
I am using 3.5.4. this issue remains. updateReloadFlag() is invoked multiple times during one request when it passes multiple filters chain, such that session.getAttribute() always returns NULL.
Hi @asantoso ,
Can you please create a seperate issue and reproduce the problem with a unittest? Your problem can be lost within a closed issue...