[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=14510759#comment-14510759 ] Robbie Gemmell commented on PROTON-853: --- The changes in this JIRA allow for rcv = session.reciever(foo) - rcv.open() - rcv.close() - rcv = session.reciever(foo) - rcv.open to work without having called free() on the link after it is closed. Upon inspection I dont believe it allows the same to occur for 'detach' rather than 'close', and the behaviour of that will return to what it was in 0.8 and prior, where free() must be called after the detach to ensure subsequent use of the link name works. As the behaviour in 0.9 was broken anyway (hence this JIRA) we think that is acceptable. This change will be incorporated into a '0.9.1' release with other critical bug fixes, with any more work around detach generally being better suited to a future larger release. [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 Assignee: Robbie Gemmell Fix For: 0.10 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)
[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=14507618#comment-14507618 ] ASF subversion and git services commented on PROTON-853: Commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=252f5f0 ] PROTON-853: add a test that catches the issue from PROTON-154 (and 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)
[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=14507622#comment-14507622 ] ASF subversion and git services commented on PROTON-853: Commit f2d7d669155a2ca57606c9381f4f1720739be79b in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f2d7d66 ] 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. This closes #21 [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)
[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=14507617#comment-14507617 ] ASF GitHub Bot commented on PROTON-853: --- Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/21 [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)
[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=14507615#comment-14507615 ] ASF subversion and git services commented on PROTON-853: Commit d2262bb7e2ead5b12ed2d4baf94cca6f06e0146c in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d2262bb ] PROTON-853: revert the change from PROTON-154, including the test since it doesnt actually fail without the change. This reverts commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5. [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)
[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=14506921#comment-14506921 ] ASF GitHub Bot commented on PROTON-853: --- Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/21#issuecomment-95147399 +1 from me, not seen any issues in our FV after applying these commits + 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)
[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=14504665#comment-14504665 ] ASF GitHub Bot commented on PROTON-853: --- Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/21#issuecomment-94719493 @gemmellr sure, just pulling in this PR now and will run some scenarios through it [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)
[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=14504801#comment-14504801 ] ASF GitHub Bot commented on PROTON-853: --- Github user rhs commented on the pull request: https://github.com/apache/qpid-proton/pull/21#issuecomment-94755563 +1 from me Initially I thought this wouldn't account for detach properly, but looking at the code I managed to convince myself that it will. If you have time, however, it would be nice to augment/add a test of the detach scenario. [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)
[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=14504726#comment-14504726 ] ASF GitHub Bot commented on PROTON-853: --- Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/21#issuecomment-94736378 Just a note to say, the new test will currently fail against proton-c just now, but Gordons fix from PROTON-850 resolves that. I mentioned this to him and he will push it in at some point. [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)
[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)
[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)
