[
https://issues.apache.org/jira/browse/TAP5-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901572#comment-17901572
]
Thiago Henrique De Paula Figueiredo commented on TAP5-2799:
-----------------------------------------------------------
Hello, [~Nakories] and [~ben-ng] !
I think there's 2 simple things we can do to improve our code in this case:
# Little optimization: change the method so it only locks if the returned
value is not null.
# Add a getAttributeWithoutLocking(String) method to Session so users can
explicitly opt out of locking.
A more involved version of #1 above is something I was thinking as part of a
possible future strict mode for Tapestry: having a service that defines which
classes are considered immutable. SessionImpl could then use it to verify
whether the returned object is immutable and skip the locking if it is.
This service would also be used during component assembling: if a non-claimed
(not annotated or annotated with @Property field is initialized with a
non-null, non-primitive value, Tapestry would throw an error since this can
lead to a very difficult to track bug (this value is initialized once and, if
it has mutable fields, they keep their values for the next request).
Thoughts?
Cheers!
> Thread Lockup when trying to read from a Session Object
> -------------------------------------------------------
>
> Key: TAP5-2799
> URL: https://issues.apache.org/jira/browse/TAP5-2799
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-http
> Affects Versions: 5.8.7
> Reporter: Alex Craddock
> Assignee: Ben Weidig
> Priority: Major
>
> I am not 100% sure how to recreate this but one of our servers froze up on
> the 443 port, when I looked into it and checked a thread dump I noticed 24
> threads all in this stack.
>
>
> {code:java}
> "http-nio-443-exec-25" #95 daemon prio=5 os_prio=0 cpu=6249001.07ms
> elapsed=138173.76s tid=0x00007fd974035800 nid=0x6288f waiting on condition
> [0x00007fd929edb000]
> java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.25/Native Method)
> - parking to wait for <0x000000047a350910> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.25/LockSupport.java:194)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.25/AbstractQueuedSynchronizer.java:885)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.25/AbstractQueuedSynchronizer.java:917)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.25/AbstractQueuedSynchronizer.java:1240)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(java.base@11.0.25/ReentrantReadWriteLock.java:959)
> at
> org.apache.tapestry5.http.internal.services.TapestrySessionFactoryImpl$SessionLockImpl.acquireWriteLock(TapestrySessionFactoryImpl.java:110)
> at
> org.apache.tapestry5.http.internal.services.SessionImpl.getAttribute(SessionImpl.java:50)
> at
> org.apache.tapestry5.http.internal.services.ClusteredSessionImpl.getAttribute(ClusteredSessionImpl.java:56)
> {code}
>
>
> Which seemed a bit odd to me. When I looked into the code for
> "org.apache.tapestry5.http.internal.services.SessionImpl" I noticed this
>
> {code:java}
> public Object getAttribute(String name) {
> this.lock.acquireWriteLock();
> return this.session.getAttribute(name);
> }
> public List<String> getAttributeNames() {
> this.lock.acquireReadLock();
> return InternalUtils.toList(this.session.getAttributeNames());
> }
> public void setAttribute(String name, Object value) {
> this.lock.acquireWriteLock();
> this.session.setAttribute(name, value);
> } {code}
> I am not sure why, but I think it's a bug that when you are calling
> getAttribute, that it should only apply a read lock rather than a write lock.
> Not sure if this will solve my issue but I think this should be looked into.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
