[jira] [Updated] (QPID-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung Messaging API based application
[ https://issues.apache.org/jira/browse/QPID-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8100: - Priority: Major (was: Minor) > [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung > Messaging API based application > - > > Key: QPID-8100 > URL: https://issues.apache.org/jira/browse/QPID-8100 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: 0.32, qpid-java-broker-7.0.0, qpid-java-broker-7.0.1 > Environment: * Qpid Broker-J 0.32 derivative > * Qpid Cpp Client using messaging API. >Reporter: Keith Wall >Priority: Major > > If, during session attachment, the Broker detects that the 0-10 session is > already in use by the same principal, the Broker is required to detach the > session by sending a {{session.detach}} on the same channel. Currently owing > to a defect, the Broker sends this detach on channel 0, regardless of the > channel used by the peer. > This defect was a contributory factor in a larger problem. It prevented an > application from recovering automatically.In that case, a Qpid CPP > Messaging API, recovering from a missing heartbeat, entered a hung state > whilst attaching the existing session. The client library discarded the > {{session.detach}} on the unexpected channel, so it continued to await the > {{session.attached}}, which never came. > {noformat} > /// original session attach > 2018-02-15 13:17:50 [Network] trace SENT > [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; > {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] > 2018-02-15 13:17:50 [Network] trace RECV > [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; > {SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] > 2018-02-15 13:17:50 [Network] trace SENT > [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; > {SessionRequestTimeoutBody: timeout=0; }] > /// snip - later heartbeat timeout > 2018-02-15 13:18:20 [Client] debug Traffic timeout > /// snip - reconnecting again > 2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672 > /// snip -reuse the same session id > 2018-02-15 13:18:28 [Client] debug Known-brokers for connection: > 2018-02-15 13:18:28 [Network] trace SENT > [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; > {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] > 2018-02-15 13:18:28 [Network] trace RECV > [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; > {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] > 2018-02-15 13:18:28 [Client] info Connection > [10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid > channel: Frame[BEbe; channel=0; {SessionDetachedBody: > name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung Messaging API based application
[ https://issues.apache.org/jira/browse/QPID-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8100: - Description: If, during session attachment, the Broker detects that the 0-10 session is already in use by the same principal, the Broker is required to detach the session by sending a {{session.detach}} on the same channel. Currently owing to a defect, the Broker sends this detach on channel 0, regardless of the channel used by the peer. This defect was a contributory factor in a larger problem. It prevented an application from recovering automatically.In that case, a Qpid CPP Messaging API, recovering from a missing heartbeat, entered a hung state whilst attaching the existing session. The client library discarded the {{session.detach}} on the unexpected channel, so it continued to await the {{session.attached}}, which never came. {noformat} /// original session attach 2018-02-15 13:17:50 [Network] trace SENT [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:17:50 [Network] trace RECV [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:17:50 [Network] trace SENT [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionRequestTimeoutBody: timeout=0; }] /// snip - later heartbeat timeout 2018-02-15 13:18:20 [Client] debug Traffic timeout /// snip - reconnecting again 2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672 /// snip -reuse the same session id 2018-02-15 13:18:28 [Client] debug Known-brokers for connection: 2018-02-15 13:18:28 [Network] trace SENT [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:18:28 [Network] trace RECV [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] 2018-02-15 13:18:28 [Client] info Connection [10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid channel: Frame[BEbe; channel=0; {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] {noformat} was: If, during session attachment, the Broker detects that the 0-10 session is already in use by the same principal, the Broker is required to detach the session by sending a {{session.detach}} on the same channel. Currently owing to a defect, the Broker sends this detach on channel 0, regardless of the channel used by the peer. This defect was a contributory factor in a larger problem. It prevented an application from recovering automatically.In that case, a Qpid CPP Messaging API, recovering from a missing heartbeat, entered a hung state whilst attaching the existing session. The client library discarded the session.detach on the unexpected channel, so it continued to await the session.attach, which never came. {noformat} /// original session attach 2018-02-15 13:17:50 [Network] trace SENT [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:17:50 [Network] trace RECV [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:17:50 [Network] trace SENT [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionRequestTimeoutBody: timeout=0; }] /// snip - later heartbeat timeout 2018-02-15 13:18:20 [Client] debug Traffic timeout /// snip - reconnecting again 2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672 /// snip -reuse the same session id 2018-02-15 13:18:28 [Client] debug Known-brokers for connection: 2018-02-15 13:18:28 [Network] trace SENT [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:18:28 [Network] trace RECV [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] 2018-02-15 13:18:28 [Client] info Connection [10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid channel: Frame[BEbe; channel=0; {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] {noformat} > [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung > Messaging API based application > - > > Key: QPID-8100 > URL: https://issues.apache.org/jira/browse/QPID-8100 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: 0.32, qpid-java-broke
[jira] [Updated] (QPID-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung Messaging API based application
[ https://issues.apache.org/jira/browse/QPID-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8100: - Summary: [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung Messaging API based application (was: [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel) > [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel leading to hung > Messaging API based application > - > > Key: QPID-8100 > URL: https://issues.apache.org/jira/browse/QPID-8100 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: 0.32, qpid-java-broker-7.0.0, qpid-java-broker-7.0.1 > Environment: * Qpid Broker-J 0.32 derivative > * Qpid Cpp Client using messaging API. >Reporter: Keith Wall >Priority: Minor > > If, during session attachment, the Broker detects that the 0-10 session is > already in use by the same principal, the Broker is required to detach the > session by sending a {{session.detach}} on the same channel. Currently owing > to a defect, the Broker sends this detach on channel 0, regardless of the > channel used by the peer. > This defect was a contributory factor in a larger problem. It prevented an > application from recovering automatically.In that case, a Qpid CPP > Messaging API, recovering from a missing heartbeat, entered a hung state > whilst attaching the existing session. The client library discarded the > session.detach on the unexpected channel, so it continued to await the > session.attach, which never came. > {noformat} > /// original session attach > 2018-02-15 13:17:50 [Network] trace SENT > [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; > {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] > 2018-02-15 13:17:50 [Network] trace RECV > [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; > {SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] > 2018-02-15 13:17:50 [Network] trace SENT > [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; > {SessionRequestTimeoutBody: timeout=0; }] > /// snip - later heartbeat timeout > 2018-02-15 13:18:20 [Client] debug Traffic timeout > /// snip - reconnecting again > 2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672 > /// snip -reuse the same session id > 2018-02-15 13:18:28 [Client] debug Known-brokers for connection: > 2018-02-15 13:18:28 [Network] trace SENT > [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; > {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] > 2018-02-15 13:18:28 [Network] trace RECV > [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; > {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] > 2018-02-15 13:18:28 [Client] info Connection > [10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid > channel: Frame[BEbe; channel=0; {SessionDetachedBody: > name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8100) [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel
[ https://issues.apache.org/jira/browse/QPID-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8100: - Description: If, during session attachment, the Broker detects that the 0-10 session is already in use by the same principal, the Broker is required to detach the session by sending a {{session.detach}} on the same channel. Currently owing to a defect, the Broker sends this detach on channel 0, regardless of the channel used by the peer. This defect was a contributory factor in a larger problem. It prevented an application from recovering automatically.In that case, a Qpid CPP Messaging API, recovering from a missing heartbeat, entered a hung state whilst attaching the existing session. The client library discarded the session.detach on the unexpected channel, so it continued to await the session.attach, which never came. {noformat} /// original session attach 2018-02-15 13:17:50 [Network] trace SENT [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:17:50 [Network] trace RECV [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:17:50 [Network] trace SENT [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionRequestTimeoutBody: timeout=0; }] /// snip - later heartbeat timeout 2018-02-15 13:18:20 [Client] debug Traffic timeout /// snip - reconnecting again 2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672 /// snip -reuse the same session id 2018-02-15 13:18:28 [Client] debug Known-brokers for connection: 2018-02-15 13:18:28 [Network] trace SENT [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:18:28 [Network] trace RECV [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] 2018-02-15 13:18:28 [Client] info Connection [10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid channel: Frame[BEbe; channel=0; {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] {noformat} was: If, during session attachment, the Broker detects that the 0-10 session is already in use by the same principal, the Broker is required to detach the session by sending a {{session.detach}} on the same channel. Currently owing to a defect, the Broker sends this detach on channel 0, regardless of the channel used by the peer. This defect was a contributory factor in a larger problem. It prevented an application from recovering automatically.In that case, a Qpid CPP Messaging API, recovering from a missing heartbeat, entered a hung state whilst attaching the existing session. The client library discarded the session.detach on the unexpected channel, so it continued to await the session.attach, which never came. {noformat} 2018-02-15 13:17:50 [Network] trace SENT [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:17:50 [Network] trace RECV [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:17:50 [Network] trace SENT [[10.211.55.3:60054-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionRequestTimeoutBody: timeout=0; }] /// snip 2018-02-15 13:18:20 [Client] debug Traffic timeout /// snip 2018-02-15 13:18:20 [System] info Connecting: 10.241.132.41:5672 /// snip 2018-02-15 13:18:28 [Client] debug Known-brokers for connection: 2018-02-15 13:18:28 [Network] trace SENT [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=1; {SessionAttachBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; }] 2018-02-15 13:18:28 [Network] trace RECV [[10.211.55.3:60056-10.241.132.41:5672]]: Frame[BEbe; channel=0; {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] 2018-02-15 13:18:28 [Client] info Connection [10.211.55.3:60056-10.241.132.41:5672] dropping frame received on invalid channel: Frame[BEbe; channel=0; {SessionDetachedBody: name=e2baafab-5e5f-4daf-8276-33ccaa9f940a; code=1; }] {noformat} > [Broker-J] [AMQP 0-10] SESSION_BUSY sent on wrong channel > - > > Key: QPID-8100 > URL: https://issues.apache.org/jira/browse/QPID-8100 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: 0.32, qpid-java-broker-7.0.0, qpid-java-broker-7.0.1 > Environment: * Qpid Broker-J 0.32 derivative > * Qpid Cpp Client using messaging API. >Reporter: Keith Wall >Priority: Minor > > If, during sessi