[
https://issues.apache.org/jira/browse/TAP5-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901568#comment-17901568
]
ASF subversion and git services commented on TAP5-2799:
-------------------------------------------------------
Commit 9a08e0afc63c3af59e2cd706cd1864d3689f57c2 in tapestry-5's branch
refs/heads/master from Thiago H. de Paula Figueiredo
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=9a08e0afc ]
TAP5-2799: Thread lockup when calling Session.getAttribute()
> 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([email protected]/Native Method)
> - parking to wait for <0x000000047a350910> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.park([email protected]/LockSupport.java:194)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt([email protected]/AbstractQueuedSynchronizer.java:885)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued([email protected]/AbstractQueuedSynchronizer.java:917)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire([email protected]/AbstractQueuedSynchronizer.java:1240)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock([email protected]/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)
