Skip to content
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

HazelcastHttpSession.getAttribute() for WebFilter not working when deferredWrite=true #5798

Closed
haixiliu opened this issue Jul 28, 2015 · 7 comments

Comments

Projects
None yet
4 participants
@haixiliu
Copy link

commented Jul 28, 2015

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.

@bilalyasar

This comment has been minimized.

Copy link
Collaborator

commented Jul 28, 2015

@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?

@bilalyasar

This comment has been minimized.

Copy link
Collaborator

commented Jul 28, 2015

@haixiliu, i guess i found your issue, i will try in my local and will inform you. thanks for reporting.

@haixiliu

This comment has been minimized.

Copy link
Author

commented Jul 28, 2015

Hi @bilalyasar,

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.

Thanks.
-Haixi

@bilalyasar

This comment has been minimized.

Copy link
Collaborator

commented Jul 28, 2015

@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.

mesutcelik added a commit that referenced this issue Aug 6, 2015

Merge pull request #5804 from bilalyasar/351-wm-fix
cache entry marked as false fix for #5798
@bilalyasar

This comment has been minimized.

Copy link
Collaborator

commented Aug 12, 2015

caching problem is solved by #5804
we will fix caching null attributes issue which is #5668
so i am closing this issue.

@bilalyasar bilalyasar closed this Aug 12, 2015

@asantoso

This comment has been minimized.

Copy link

commented Dec 8, 2015

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.

@mesutcelik

This comment has been minimized.

Copy link
Contributor

commented Dec 9, 2015

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.