-
Notifications
You must be signed in to change notification settings - Fork 306
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
FISH-766 Improper session synchronization of session map #4479
FISH-766 Improper session synchronization of session map #4479
Conversation
- cache could be read by another thread and put caused ConcurrentModificationException
- synchronization object should be final, that is what Sonar said
@sgflt We are awaiting the signed CLA (https://github.com/payara/Payara/blob/master/PayaraCLA.pdf) otherwise we need to close this PR. |
We've got the CLA |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of synchronized keyword around HashMap,
why don't you replace it with ConcurrentHashMap instead?
Just for minimal change. But why not. I can try to use ConcurrentHashMap. |
…er-session-synchronization
WIP: Replacing synchronized by ConcurrentHashMap is not so trivial. Some parts of code have different semantics that may break session management. Anyways I am keeping to dig deeper. |
What does |
- as found before isValid has expiration side effect - checkValid flag is meant to be short circuit
I think that's remanents of Sun / Oracle issue tracking before JIRA -type or source control integration |
why not? I don't see any difference with that and synchronize, except synchronize has to be used in all parts of the code (even future parts) but not ConcurrentHashMap |
} | ||
this.cache.forEach((ssoId, sso) -> { | ||
if (sso.isEmpty() && sso.getLastAccessTime() < tooOld) { | ||
removals.add(ssoId); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a little change in behavior.
Old implementation locked SSOs and created a list of expired SSOs. No one could create a new SSO.
New implementation uses what is available and does not block creation of a new SSO (which is not taken for expiration in given round). However probability of a new SSO being expired is so small so I think this change should be OK for a real world usage.
- no null is allowed, only empty collection
@@ -985,16 +982,14 @@ public void processExpires() { | |||
|
|||
long timeNow = System.currentTimeMillis(); | |||
|
|||
Session[] sessions = findSessions(); | |||
if (sessions != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nullcheck for broken contract removed
@@ -882,21 +881,19 @@ public void stop(boolean isShutdown) throws LifecycleException { | |||
} | |||
|
|||
// Expire all active sessions and notify their listeners | |||
Session sessions[] = findSessions(); | |||
if (sessions != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nullcheck for broken contract removed
@@ -111,8 +111,8 @@ public void clearSessions() { | |||
} | |||
|
|||
@Override | |||
public Session[] findSessions() { | |||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
broken contract fixed
S1AS8 means SunOne Application Server 8 which used same system as the Sun JDK, now dead. |
jenkins test please |
…-synchronization FISH-766 Improper session synchronization of session map
Description
This is a bug fix of #4280
Important Info
Dependant PRs
Blockers
Testing
New tests
none
Testing Performed
none
Test suites executed
none
Testing Environment
Documentation
Notes for Reviewers
Reviewer should check the synchronization was incorrect (asymetric) and now each write attempt is locked to prevent readers to receive ConcurrentModificationException.