[jira] [Commented] (PROTON-1025) CLOSE_WAIT leak following reproducer for PROTON-1023 / PROTON-1024
[
https://issues.apache.org/jira/browse/PROTON-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14980661#comment-14980661
]
Pavel Moravec commented on PROTON-1025:
---
Good point. It makes sense the programmer should call "destructor" before
assigning a new instance of the class to the variable.
So I am closing this JIRA - let reopen when feature "BlockingConnection should
close itself on unreference" is required..
> CLOSE_WAIT leak following reproducer for PROTON-1023 / PROTON-1024
> --
>
> Key: PROTON-1025
> URL: https://issues.apache.org/jira/browse/PROTON-1025
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
>Reporter: Pavel Moravec
>Priority: Minor
>
> Following reproducer for PROTON-1023 or PROTON-1024 (attached at the botton),
> client leaves some sockets in CLOSE_WAIT state forever.
> I tested the reproducer before & after those two fixes and it is present in
> both. I.e. this bug is not a regression caused by PROTON-1023 or PROTON-1024.
> Reproducer:
> (assuming localhost runs qdrouterd that is restarted every 5 seconds in a
> loop):
> {code}
> #!/usr/bin/python
> from time import sleep
> from uuid import uuid4
> from proton import ConnectionException
> from proton.utils import BlockingConnection
> import traceback
> import random
> while True:
> sleep(random.uniform(0.3,3))
> try:
> conn = BlockingConnection("proton+amqp://localhost:5672",
> ssl_domain=None, heartbeat=2)
> rec = conn.create_receiver("another_address", name=str(uuid4()),
> dynamic=False, options=None)
> print "sleeping.."
> sleep(random.uniform(0.3,3))
> rec2 = conn.create_receiver("some_address", name=str(uuid4()),
> dynamic=False, options=None)
> except ConnectionException:
> try:
> if conn:
> conn.close()
> except Exception, e:
> print e
> print(traceback.format_exc())
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1025) CLOSE_WAIT leak following reproducer for PROTON-1023 / PROTON-1024
[
https://issues.apache.org/jira/browse/PROTON-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14966806#comment-14966806
]
Gordon Sim commented on PROTON-1025:
The example above 'leaks' BlockingConnection instances. I.e. if rec2 is created
successfully, the while loop will proceed and the BlockingConnection instance
will not have been closed when a new instance is assigned to the conn variable.
Perhaps the BlockingConnection could close itself when it becomes unreferenced,
but at present the expectation is that it should be explicitly closed.
> CLOSE_WAIT leak following reproducer for PROTON-1023 / PROTON-1024
> --
>
> Key: PROTON-1025
> URL: https://issues.apache.org/jira/browse/PROTON-1025
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
>Reporter: Pavel Moravec
>Priority: Minor
>
> Following reproducer for PROTON-1023 or PROTON-1024 (attached at the botton),
> client leaves some sockets in CLOSE_WAIT state forever.
> I tested the reproducer before & after those two fixes and it is present in
> both. I.e. this bug is not a regression caused by PROTON-1023 or PROTON-1024.
> Reproducer:
> (assuming localhost runs qdrouterd that is restarted every 5 seconds in a
> loop):
> {code}
> #!/usr/bin/python
> from time import sleep
> from uuid import uuid4
> from proton import ConnectionException
> from proton.utils import BlockingConnection
> import traceback
> import random
> while True:
> sleep(random.uniform(0.3,3))
> try:
> conn = BlockingConnection("proton+amqp://localhost:5672",
> ssl_domain=None, heartbeat=2)
> rec = conn.create_receiver("another_address", name=str(uuid4()),
> dynamic=False, options=None)
> print "sleeping.."
> sleep(random.uniform(0.3,3))
> rec2 = conn.create_receiver("some_address", name=str(uuid4()),
> dynamic=False, options=None)
> except ConnectionException:
> try:
> if conn:
> conn.close()
> except Exception, e:
> print e
> print(traceback.format_exc())
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
