Re: Messenger race condition on Android?
Hi Rafael, My answers to your questions are below... On Fri, Apr 17, 2015 at 8:33 AM Rafael Schloming-3 [via Qpid] ml-node+s2158936n7623117...@n2.nabble.com wrote: On Fri, Apr 17, 2015 at 8:09 AM, Adam Wynne [hidden email] http:///user/SendEmail.jtp?type=nodenode=7623117i=0 wrote: Sorry for the cross-post but I didn't get any hits on the user list and I now think this could be a bug. I think I am seeing a race condition with Messenger on Android only: When I do the typical put/send sequence in a Thread started from an Android Activity, the message is not received by a subscribed peer. If I kill the Activity, the peer will complain that the connection is broken. So it seems that the connection is being made but the data is not sent. Here is an example code snippet: Messenger messenger = Messenger.Factory.create(); // do other things like create a message messenger.put(msg) // Thread.sleep(200) messenger.send() However when I uncomment the sleep statement above, the message is received without any problem. The message is also received if I attempt to debug to see what is happening in put(). I noticed that put() does not simply add the message to a queue, it also uses nio methods to do some encoding of the message. I'm wondering if since it is not blocking, is there some encoding method happening while the send() is being processed, causing the message to be lost. We also noticed that there is a big CPU usage (up to 40%) spike during the put/send process, which seems extreme for just a tcp send. Hi Adam, Apologies in advance for the barrage of questions, but some additional information would be helpful. What version of the code are you working with? I first tried with 0.9, then I built the latest from source and had the same results each time Is your thread a long running thread or does it terminate shortly after the code you have posted? The thread is long running What exactly is receiving the message at the other end of the connection? I have tried 2 subscribers with the same results: one in android and one on a macbook. I get the same results on mac. Does a similar thread arrangement reproduce the issue outside of Android, and if so would it be possible to post a reproducer? No, I couldn't reproduce in a standard JVM. Do you want me to post the android app? Thanks, --Rafael -- If you reply to this email, your message will be added to the discussion below: http://qpid.2158936.n2.nabble.com/Messenger-race-condition-on-Android-tp7623116p7623117.html To unsubscribe from Messenger race condition on Android?, click here http://qpid.2158936.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7623116code=YXd5bm5lQGdtYWlsLmNvbXw3NjIzMTE2fDkyMjA4OTk2MQ== . NAML http://qpid.2158936.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://qpid.2158936.n2.nabble.com/Messenger-race-condition-on-Android-tp7623116p7623203.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
[GitHub] qpid-proton pull request: Mbed minor changes and sasl mech
Github user dcristoloveanu commented on the pull request: https://github.com/apache/qpid-proton/pull/19#issuecomment-94641331 Iâve removed the SASL client mechanism setter as I think PROTON-334 should do when it comes online. And if it does not we can always bring this back in another pull request. One small thing at a time. Thanks for the feedback. /Dan From: Rafael Schloming [mailto:notificati...@github.com] Sent: Monday, April 20, 2015 5:27 AM To: apache/qpid-proton Cc: Dan Cristoloveanu Subject: Re: [qpid-proton] Mbed minor changes and sasl mech (#19) @astitcherhttps://github.com/astitcher: do you want to wait until PROTON-334 lands to pull this in given the conflict you mention? â Reply to this email directly or view it on GitHubhttps://github.com/apache/qpid-proton/pull/19#issuecomment-94438477. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-334) SASL Implementation for Proton C
[ https://issues.apache.org/jira/browse/PROTON-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14502710#comment-14502710 ] ASF GitHub Bot commented on PROTON-334: --- Github user rhs commented on the pull request: https://github.com/apache/qpid-proton/pull/17#issuecomment-94437344 Looks good to me, assuming all the tests pass and what not, I'm +1. SASL Implementation for Proton C Key: PROTON-334 URL: https://issues.apache.org/jira/browse/PROTON-334 Project: Qpid Proton Issue Type: Wish Components: proton-c Reporter: Ted Ross Assignee: Andrew Stitcher It would be desirable to have the ability to use a plug-in module for SASL in Proton. The following implementations could then be developed: 1) A portable stand-alone plugin that does ANONYMOUS, PLAIN, and EXTERNAL 2) A Cyrus-Sasl based plugin for Linux 3) A Windows plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-334: SASL Implementation for Prot...
Github user rhs commented on the pull request: https://github.com/apache/qpid-proton/pull/17#issuecomment-94437344 Looks good to me, assuming all the tests pass and what not, I'm +1. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-334) SASL Implementation for Proton C
[ https://issues.apache.org/jira/browse/PROTON-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14502714#comment-14502714 ] ASF GitHub Bot commented on PROTON-334: --- Github user rhs commented on the pull request: https://github.com/apache/qpid-proton/pull/19#issuecomment-94438477 @astitcher: do you want to wait until PROTON-334 lands to pull this in given the conflict you mention? SASL Implementation for Proton C Key: PROTON-334 URL: https://issues.apache.org/jira/browse/PROTON-334 Project: Qpid Proton Issue Type: Wish Components: proton-c Reporter: Ted Ross Assignee: Andrew Stitcher It would be desirable to have the ability to use a plug-in module for SASL in Proton. The following implementations could then be developed: 1) A portable stand-alone plugin that does ANONYMOUS, PLAIN, and EXTERNAL 2) A Cyrus-Sasl based plugin for Linux 3) A Windows plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-854) [proton-j] ConnectionImpl retains all created Sessions until the Connection is freed
[ https://issues.apache.org/jira/browse/PROTON-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503316#comment-14503316 ] ASF subversion and git services commented on PROTON-854: Commit 1e4b121d6fdbcfa5585416dfdca4430e042f52bf in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1e4b121 ] PROTON-854: remove sessions from the list when they are freed [proton-j] ConnectionImpl retains all created Sessions until the Connection is freed Key: PROTON-854 URL: https://issues.apache.org/jira/browse/PROTON-854 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell ConnectionImpl maintains a _sessions list, containing Sessions created for the connection. Entries are only ever added to this list and never removed, being retained until the list itself is released when the connection has free() called on it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503152#comment-14503152 ] ASF subversion and git services commented on PROTON-490: Commit 81085e348ce15c088a82a117e4892c760a57b9fe in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=81085e3 ] PROTON-490: futurize proton-c/bindings [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503431#comment-14503431 ] ASF GitHub Bot commented on PROTON-853: --- GitHub user gemmellr opened a pull request: https://github.com/apache/qpid-proton/pull/21 PROTON-853: stop erroneous attach being sent The changes for PROTON 154 commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5 in 0.9 lead to situations where the transport will decide to send a new Attach frame out for a link that has been closed/detached. The original change aimed to ensure that a link with the same name as one which had just been closed could be attached on the same session, by clearing the 'attach sent' and 'detach received' flags of the TransportLink. The reason that seemed necessary is that the old link object (and in turn TransportLink object) would be returned due to some caching within SessionImpl, unless you ensure to first call free() on the old link. Gordon noticed the same effect from the server side in proton-c via PROTON 850. These changes stop the erroneous attach being sent by first reverting the change from PROTON 154, and looking to stop the earlier situation arising by returning a new Link object rather than a cached one if the states are closed (i.e similar to Gordons from PROTON 850), meaning a new TransportLink gets created rather than the old one being reused and there then being no need to play with the boolean states. It keeps a list of any 'old links' that would have been forogtten to ensure they get free'd when the session is. The earlier test was ineffective and passed with or without the earlier changes. This was because it actually created new connections and sessions when it was aiming to be reuse the same session. I updated the test to do that, and it now catches both PROTON 154 and PROTON 850 (in proton-c too). You can merge this pull request into a Git repository by running: $ git pull https://github.com/gemmellr/qpid-proton PROTON-853 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/21.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #21 commit 022ea2dbb7f5d7182fefb6e53adc8486777e69e0 Author: Robert Gemmell rob...@apache.org Date: 2015-04-20T15:47:55Z PROTON-853: revert the change from PROTON-154, including the test since it doesnt actually fail without the change. This reverts commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5. commit 4b15a9b9befe727d2edde062e02da268aca40a83 Author: Robert Gemmell rob...@apache.org Date: 2015-04-20T16:39:25Z PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850) commit 00e69d3ad599beacba858f6ad1d4d75fb8c30fce Author: Robert Gemmell rob...@apache.org Date: 2015-04-20T16:41:10Z PROTON-853: dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850. [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-848-and-849: stop leaking the tra...
GitHub user gemmellr opened a pull request: https://github.com/apache/qpid-proton/pull/20 PROTON-848-and-849: stop leaking the transport state Stops leaking the transport state by removing the maps storing the TransportSession or TransportLink objects, instead using the references set on the associated Session and Link objects at the time they would have been entered into the maps. Not much to that bit. The bulk of the annoyance came from some tests failing after those changes due to alteration of the events being emitted when calling free+unbind on the connection+transport. Much debugging suggested this was possibly as result of existing differences in behaviour (mainly that things were not showing FINAL events until the unbind step in proton-j, unlike proton-c) which just happened to become more visible following my modifications. After looking at some of the differences between proton-c and proton-j's session+link reference handling I made some alterations to have it act more like proton-c, which fixed the earlier test failures, however I'd like a second opinion from someone who actually understands what this stuff is meant to do :) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gemmellr/qpid-proton PROTON-848-and-849 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/20.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #20 commit 4c5fdd045c6278c344ad5e2b044eabcd357fcf50 Author: Robert Gemmell rob...@apache.org Date: 2015-04-20T09:21:11Z PROTON-848, PROTON-849: dont store the TransportSession or TransportLink state in maps, use the references set on the associated Session and Link objects. Update channel+link reference handling to behave more like proton-c in order to resolve the resulting test failures. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-848) [proton-j] TransportSession state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503375#comment-14503375 ] ASF GitHub Bot commented on PROTON-848: --- GitHub user gemmellr opened a pull request: https://github.com/apache/qpid-proton/pull/20 PROTON-848-and-849: stop leaking the transport state Stops leaking the transport state by removing the maps storing the TransportSession or TransportLink objects, instead using the references set on the associated Session and Link objects at the time they would have been entered into the maps. Not much to that bit. The bulk of the annoyance came from some tests failing after those changes due to alteration of the events being emitted when calling free+unbind on the connection+transport. Much debugging suggested this was possibly as result of existing differences in behaviour (mainly that things were not showing FINAL events until the unbind step in proton-j, unlike proton-c) which just happened to become more visible following my modifications. After looking at some of the differences between proton-c and proton-j's session+link reference handling I made some alterations to have it act more like proton-c, which fixed the earlier test failures, however I'd like a second opinion from someone who actually understands what this stuff is meant to do :) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gemmellr/qpid-proton PROTON-848-and-849 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/20.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #20 commit 4c5fdd045c6278c344ad5e2b044eabcd357fcf50 Author: Robert Gemmell rob...@apache.org Date: 2015-04-20T09:21:11Z PROTON-848, PROTON-849: dont store the TransportSession or TransportLink state in maps, use the references set on the associated Session and Link objects. Update channel+link reference handling to behave more like proton-c in order to resolve the resulting test failures. [proton-j] TransportSession state is never discarded Key: PROTON-848 URL: https://issues.apache.org/jira/browse/PROTON-848 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Priority: Critical TransportImpl keeps a _transportSessionState map of SessionImpl - TransportSession objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503442#comment-14503442 ] ASF GitHub Bot commented on PROTON-853: --- Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/21#issuecomment-94542644 @rhs can you take a look? @dnwe can you also take a look to confirm if the changes work for you, e.g. handles any tests you have elsewhere based on needing the earlier changes? [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-848-and-849: stop leaking the tra...
Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/20#issuecomment-94533325 @rhs can you take a look please? Mainly at the channel/handle process updates, the actual leak prevention wasnt that interesting in the end. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-848) [proton-j] TransportSession state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503380#comment-14503380 ] ASF GitHub Bot commented on PROTON-848: --- Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/20#issuecomment-94533325 @rhs can you take a look please? Mainly at the channel/handle process updates, the actual leak prevention wasnt that interesting in the end. [proton-j] TransportSession state is never discarded Key: PROTON-848 URL: https://issues.apache.org/jira/browse/PROTON-848 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Priority: Critical TransportImpl keeps a _transportSessionState map of SessionImpl - TransportSession objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-853: stop erroneous attach being ...
GitHub user gemmellr opened a pull request: https://github.com/apache/qpid-proton/pull/21 PROTON-853: stop erroneous attach being sent The changes for PROTON 154 commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5 in 0.9 lead to situations where the transport will decide to send a new Attach frame out for a link that has been closed/detached. The original change aimed to ensure that a link with the same name as one which had just been closed could be attached on the same session, by clearing the 'attach sent' and 'detach received' flags of the TransportLink. The reason that seemed necessary is that the old link object (and in turn TransportLink object) would be returned due to some caching within SessionImpl, unless you ensure to first call free() on the old link. Gordon noticed the same effect from the server side in proton-c via PROTON 850. These changes stop the erroneous attach being sent by first reverting the change from PROTON 154, and looking to stop the earlier situation arising by returning a new Link object rather than a cached one if the states are closed (i.e similar to Gordons from PROTON 850), meaning a new TransportLink gets created rather than the old one being reused and there then being no need to play with the boolean states. It keeps a list of any 'old links' that would have been forogtten to ensure they get free'd when the session is. The earlier test was ineffective and passed with or without the earlier changes. This was because it actually created new connections and sessions when it was aiming to be reuse the same session. I updated the test to do that, and it now catches both PROTON 154 and PROTON 850 (in proton-c too). You can merge this pull request into a Git repository by running: $ git pull https://github.com/gemmellr/qpid-proton PROTON-853 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/21.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #21 commit 022ea2dbb7f5d7182fefb6e53adc8486777e69e0 Author: Robert Gemmell rob...@apache.org Date: 2015-04-20T15:47:55Z PROTON-853: revert the change from PROTON-154, including the test since it doesnt actually fail without the change. This reverts commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5. commit 4b15a9b9befe727d2edde062e02da268aca40a83 Author: Robert Gemmell rob...@apache.org Date: 2015-04-20T16:39:25Z PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850) commit 00e69d3ad599beacba858f6ad1d4d75fb8c30fce Author: Robert Gemmell rob...@apache.org Date: 2015-04-20T16:41:10Z PROTON-853: dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-849) [proton-j] TransportLink state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503472#comment-14503472 ] Robbie Gemmell commented on PROTON-849: --- Proposed some changes in a shared pull request with PROTON-849: https://github.com/apache/qpid-proton/pull/20 [proton-j] TransportLink state is never discarded - Key: PROTON-849 URL: https://issues.apache.org/jira/browse/PROTON-849 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Priority: Critical TransportImpl keeps a _transportLinkStatemap of LinkImpl - TransportLink objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
