[
https://issues.apache.org/jira/browse/TAP5-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901427#comment-17901427
]
Alex Craddock commented on TAP5-2799:
-------------------------------------
Okay (sorry this is how my head works with lots of comments). In the
HttpSession class there is removeAttribute,
[https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.html#removeAttribute-java.lang.String-]
There is currently no way using a TapestySession handling to remove an
attribute from the session, so even if I did the above code, once it's on the
session if the object is no longer needed we wouldn't be able to remove it and
therefore getting the attribute from the session would always return true, so
we would then have to fetch the value, causing the write lock, even if the
Session Object Value is null,
Alex
> 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)
