[
https://issues.apache.org/jira/browse/ARTEMIS-2002?focusedWorklogId=262901&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-262901
]
ASF GitHub Bot logged work on ARTEMIS-2002:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 19/Jun/19 09:04
Start Date: 19/Jun/19 09:04
Worklog Time Spent: 10m
Work Description: franz1981 commented on pull request #2707: ARTEMIS-2002
Proton transport objects leaked
URL: https://github.com/apache/activemq-artemis/pull/2707#discussion_r295193608
##########
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPConnectionContext.java
##########
@@ -183,6 +191,17 @@ public void flush() {
}
public void close(ErrorCondition errorCondition) {
+ synchronized (schedulingLock) {
+ isSchedulingCancelled = true;
+
+ if (scheduledPool != null && scheduledPool instanceof
ThreadPoolExecutor &&
+ scheduledFuture != null && scheduledFuture instanceof Runnable) {
+ if (!((ThreadPoolExecutor) scheduledPool).remove((Runnable)
scheduledFuture)) {
Review comment:
I won't guess which effects a remove would have globally: I just think is
not a good idea to do it if not necessary, given that the scheduled pool usage
span outside the context of this PR change.
> Finally WeakReference require deeper source change for ScheduleRunnable
and TickerRunnable to avoid unpredictable behavior when GC delete
AMQPConnectionContext before their execution.
Totally agree, but it would allow a more robust behaviour if a cancel won't
get rid of the task instance. Anyway this last one (a missing cancel) is an
additional issue and I agree it doesn't need to be addressed here.
My whole point is that having such casting cascade just to use the remove
API makes me believe that worth investigating if this same PR could be
addressed in a cleaner way (ie less hacky, not with less code changes) and
evaluate if it is more portable/effective too.
Feel free to try addressing in another way and provide your branch to
@k-wall to try it before merging it too :+1:
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 262901)
Time Spent: 3h 20m (was: 3h 10m)
> Proton transport objects leaked if client disconnects abruptly leading to
> OutOfMemoryError: Java heap space
> -----------------------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-2002
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2002
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
> Affects Versions: 2.6.2
> Reporter: Keith Wall
> Priority: Major
> Attachments: ARTEMIS-2002-OOMEHeap-ProtonObjectsLeaked.png
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> If an AMQP client with an attached receiving link disconnects abruptly (i.e.
> closes socket without sending the AMQP close performative), {{TransportImpl}}
> and other Proton class instances remain referenced within the heap. If many
> such clients do this, an OutOfMemoryError: Java heap space occurs. This
> occurs even though the underlying socket connection has been closed.
> I have reproduced this issue against both 2.6.2 and master
> (f0c13622ac7e821a81a354b0242ef5235b6e82df).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
