[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new attach frame for a link in the process of being closed

2015-04-25 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14512671#comment-14512671
 ] 

ASF subversion and git services commented on PROTON-853:


Commit 77c1ee076ae4a4bcbec850572deb276ebd0b8c7b in qpid-proton's branch 
refs/heads/0.9.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=77c1ee0 ]

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

(cherry picked from commit f2d7d669155a2ca57606c9381f4f1720739be79b)


> [proton-j] the transport emitted a new attach frame for a link in the process 
> of being closed
> -
>
> 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 attach frame for a link in the process of being closed

2015-04-25 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14512666#comment-14512666
 ] 

ASF subversion and git services commented on PROTON-853:


Commit 095512470f91462979fad302fb7a071ab52deccc in qpid-proton's branch 
refs/heads/0.9.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0955124 ]

PROTON-853: revert the change from PROTON-154, including the test since it 
doesnt actually fail without the change.

This reverts commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5.

(cherry picked from commit d2262bb7e2ead5b12ed2d4baf94cca6f06e0146c)


> [proton-j] the transport emitted a new attach frame for a link in the process 
> of being closed
> -
>
> 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 attach frame for a link in the process of being closed

2015-04-25 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14512668#comment-14512668
 ] 

ASF subversion and git services commented on PROTON-853:


Commit 1b1c07d1c23d2471b6b85476d29e777cd25fddab in qpid-proton's branch 
refs/heads/0.9.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1b1c07d ]

PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850)

(cherry picked from commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab)


> [proton-j] the transport emitted a new attach frame for a link in the process 
> of being closed
> -
>
> 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 attach frame for a link in the process of being closed

2015-04-24 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511214#comment-14511214
 ] 

ASF subversion and git services commented on PROTON-853:


Commit 7fa680794b7d78906129216471170dc7d720b156 in qpid-proton's branch 
refs/heads/0.9.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7fa6807 ]

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

(cherry picked from commit f2d7d669155a2ca57606c9381f4f1720739be79b)


> [proton-j] the transport emitted a new attach frame for a link in the process 
> of being closed
> -
>
> 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 attach frame for a link in the process of being closed

2015-04-24 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511208#comment-14511208
 ] 

ASF subversion and git services commented on PROTON-853:


Commit 371e2adf33d17c9a55bbccdedd4c9ae42ecc6fc2 in qpid-proton's branch 
refs/heads/0.9.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=371e2ad ]

PROTON-853: revert the change from PROTON-154, including the test since it 
doesnt actually fail without the change.

This reverts commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5.

(cherry picked from commit d2262bb7e2ead5b12ed2d4baf94cca6f06e0146c)


> [proton-j] the transport emitted a new attach frame for a link in the process 
> of being closed
> -
>
> 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 attach frame for a link in the process of being closed

2015-04-24 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511210#comment-14511210
 ] 

ASF subversion and git services commented on PROTON-853:


Commit acd1e1c9a582aaf190bb32ebc5bd9e590bd71930 in qpid-proton's branch 
refs/heads/0.9.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=acd1e1c ]

PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850)

(cherry picked from commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab)


> [proton-j] the transport emitted a new attach frame for a link in the process 
> of being closed
> -
>
> 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)